Re: options: was Red Hat is moving from / to /usr/

[Roger Leigh]

On Mon, Dec 12, 2011 at 06:55:18PM -0700, Gordon Haverland wrote:
> I'm a UN*X dinosaur.  I started using UN*X in 1984.
> 
> I don't like this idea of folding /bin, /sbin, /usr/sbin into 
> /usr/bin.
> 
> I think the reasons to segregate /bin, /sbin, /usr/bin, /usr/sbin 
> and anything in /usr/local/* still exist today.

What are those reasons?

I agree with /usr/local being separate, but /bin and /usr/bin?
What is the advantage to having them separate on a running
system?  Other than historical practice?

(http://lists.debian.org/debian-devel/2011/01/msg00152.html
 gives a bunch of historical uses which are no longer useful.)

I don't agree with the Fedora strategy of migrating /bin to
/usr/bin etc.  I think if anything we should do what would make
most sense in the long run, which would be to eliminate /usr
entirely and most the content of /usr to /.  Migrating to /usr
is a bit simpler for partitioning, but not particularly logical.

> I want more segregation, not less.  Actually, I've wanted all the 
> config for /usr to be in /etc/usr (which is a symlink to /usr/etc) 
> for a long time.

On a system managed with a package manager, this makes no sense--
the content of /usr is intimately tied to the content of /etc.
In other contexts it might be useful, but for Debian it is not.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213094451.ge17...@codelibre.net

Re: Getting dh_install to do what we need

[Gergely Nagy]

Joey Hess  writes:

> Gergely Nagy wrote:
>> At the moment, I have something that works like this:
>> 
>> ,
>> | #! /usr/bin/dh-exec-install
>> | # The next one will simply echo it back to dh_install
>> | source-file /dest-dir/
>> |
>> | # This one will copy the file itself, following similar heuristics as
>> | # dh_install: it will first try the source file directly, and if it's
>> | # not found, try the same path under debian/tmp/. The destination is
>> | # relative to debian/${PACKAGE} (as per dh compat level 7+)
>> | #
>> | # Since dh-exec-install does the copying itself, this line is NOT
>> | # echoed back to dh_install.
>> | source-file /dest-dir/new-name
>> `
>
> Of course the reason I didn't add this to dh_install 10 years ago is
> that this syntax sucks. It's really horrible; either the trailing slashes
> are much more significant than makes sense, or what it does depends on
> the state of the filesystem(ie, checking whether /dest-dir/new-name is
> a directory).

Mhm, fair enough. I'll scratch that for now then, and try to figure out
something else.

>> My implementation copies the file to the desired destination, which may
>> or may not be a good idea - I'll do some more tests to see which one's
>> less painful and more safe.
>
> That breaks -X, --fail-missing, --list-missing, --sourcedir, and --tmpdir

Ow. That's not good. Thanks for pointing these out!

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4604x3l.fsf@algernon.balabit

Bug#651928: ITP: python-commando -- simple wrapper for argparse that allows commands and arguments to be defined declaratively

[Julien Danjou]

Package: wnpp
Severity: wishlist
Owner: Julien Danjou 

* Package name: python-commando
  Version : 0.1.1a
  Upstream Author : Lakshmi Vyasarajan
* URL : http://github.com/lakshmivyas/commando
* License : MIT
  Programming Lang: Python
  Description : simple wrapper for argparse that allows commands and 
arguments to be defined declaratively

A simple wrapper for `argparse` that allows commands and arguments to be
defined declaratively using decorators. Note that this does not support all
the features of `argparse` yet.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111213100923.7954.83766.report...@zelenka.enovance.com

Re: Bug#651858: ITP: etm -- event and task manager using simple text files

[Thomas Koch]

Eike Nicklas:
> * Package name: etm
>   Version : 883
>   Upstream Author : Daniel Graham 
> * URL : http://www.duke.edu/~dgraham/ETM/
Hi,

I couldn't find any version control system for this software and the 
versioning scheme seems weird. Could you be so kind to work this out with 
upstream before packaging this?
It may be good software, but the correlation between software quality and how 
the software is managed is often high.

On the other hand I'm still searching for a good calendar app!

Regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112131121.57466.tho...@koch.ro

Re: Bug#651858: ITP: etm -- event and task manager using simple text files

[martin f krafft]

also sprach Thomas Koch  [2011.12.13.1121 +0100]:
> I couldn't find any version control system for this software and the 
> versioning scheme seems weird.

What's weird? Are you missing a dot? All that matters is that it's
increasing. ;)

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"we americans, we're a simple people...
 but piss us off, and we'll bomb your cities."
 -- robin williams, good morning vietnam


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Work-needing packages report for Dec 9, 2011

[Tollef Fog Heen]

]]  (Marco d'Itri)

> On Dec 09, Tollef Fog Heen  wrote:
> 
> > Maybe we should consider closing those bugs after a while?  While I'm
> 
> Maybe we should ask the maintainers?
> e.g. ppp still needs a lot of help.

I don't doubt that the packages might still need help, but I don't think
an RFH is going to get you help when it's been open for ages.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwgowxqm@qurzaw.varnish-software.com

Bug#651935: ITP: audioread -- Backend-agnostic audio decoding Python package

[Simon Chopin]

Package: wnpp
Severity: wishlist
Owner: Simon Chopin 

* Package name: audioread
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : MIT
  Programming Lang: Python
  Description : Backend-agnostic audio decoding Python package

Decode audio files using whichever backend is available. The library
currently supports:

* Gstreamer via gst-python.
* MAD via the pymad bindings.
* FFmpeg via its command-line interface.
* The standard library wave and aifc modules (for WAV and AIFF files).



signature.asc
Description: Digital signature

Binary blobs in source packages

[Thomas Koch]

Hi,

I just made a fool of myself on the simple-build-tool list by claiming that
Debian would build scala without scala. I only checked debian/rules and 
debian/control and since scala is in main, I assumed that I must be right.

However scala comes with a bytecode-compiled scala compiler in lib/ which is 
required only during build but not installed in the binary packages.

I already opened reportbug to fill a serious Debian Policy violation, but 
actually I couldn't find anything in the policy about it.

So is it ok to ship binaries in the source package that are only required 
during build? Can I do the same with simple-build-tool, which requires itself 
to build?

Regards,

Thomas Koch, http://www.koch.ro


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201112131323.26313.tho...@koch.ro

Re: Binary blobs in source packages

[Reinhard Tartler]

On Di, Dez 13, 2011 at 13:23:25 (CET), Thomas Koch wrote:

> Hi,
>
> I just made a fool of myself on the simple-build-tool list by claiming that
> Debian would build scala without scala. I only checked debian/rules and 
> debian/control and since scala is in main, I assumed that I must be right.
>
> However scala comes with a bytecode-compiled scala compiler in lib/ which is 
> required only during build but not installed in the binary packages.
>
> I already opened reportbug to fill a serious Debian Policy violation, but 
> actually I couldn't find anything in the policy about it.
>
> So is it ok to ship binaries in the source package that are only required 
> during build? Can I do the same with simple-build-tool, which requires itself 
> to build?

I had a similar situation in the aspectc++ package, which is a
source-to-source compiler (from AspectC++ to C++).

Background: AspectC++ requires a library called Puma for parsing C/C++
Code. While Puma itself is written in C++, the Visual C++ and Gnu
Extensions to the C++ language are written with aspects. This means that
you need the 'ac++' compiler to "weave" Puma.

Solution: Upstream provides so-called "woven" sources, which includes a
"pre-woven" Puma library. In the Debian package I use these sources to
compile a "boostrap" ac++ binary, then start over from start, weave Puma
with the "bootstrap" ac++ binary, recompile Puma, throw away the
boostrap ac++ binary, and finally compile ac++.

Additional benefit: I have now tested that the ac++ compiler actually
works on all architectures!

Implementation:
http://bazaar.launchpad.net/~siretart/aspectc++/debian/view/head:/debian/rules
(line 41-56)

I'm pretty sure that this approach can be appleid to both the
'simple-build-tool' and 'scala' packages.

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87iplkzm3l@faui43f.informatik.uni-erlangen.de

Bug#651943: ITP: qastools -- collection of desktop tools for ALSA

[Sebastian]

Package: wnpp
Severity: wishlist
Owner: Sebastian H. 

* Package name: qastools
  Version : 0.16.0
  Upstream Author : Sebastian Holtermann 
* URL : http://xwmw.org/qastools
* License : GPL-3
  Programming Lang: C++
  Description : collection of desktop tools for ALSA

 QasTool is a collection of desktop tools for the 
 Linux sound system ALSA.
 .
 The tools included are:
  - QasConfig - browser for the ALSA configuration tree
  - QasHctl - mixer for ALSA's High level Control Interface
  - QasMixer - simple mixer with features similar to alsamixer

 QasTools replaces the separate QasMixer and QasConfig packages
 for easier maintenance.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213134827.3288.87940.reportbug@blauwal

debian/copyright, DEP5 and SPDX

[Simon Josefsson]

I just stumbled upon this initiative:

http://www.spdx.org/

It is a way to specify the licensing and copyright information (and
more) for software packages.  There is some overlap between
debian/copyright file and especially the DEP5 format.  Alas, the SPDX
format is XML based, an example for GNU CoreUtils is available here (but
it seems to be buggy, it should use 'GPL-3.0+' instead of 'GPL-3.0'):

http://www.spdx.org/system/files/coreutils.rdf_.xml

Adopting something like this for an entire distribution might be useful
but will require a lot of work.  Maybe the debian/copyright files could
be permitted to reference another file shipped with the package that
contains the complete information?

Possibly DEP5-compliant files could be generated from SPDX files.

I don't have any question or suggestion what to do with this, but I
thought some people here might find it interesting.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h207b7m@latte.josefsson.org

Re: debian/copyright, DEP5 and SPDX

[Michael Shuler]

On 12/13/2011 09:17 AM, Simon Josefsson wrote:
> Possibly DEP5-compliant files could be generated from SPDX files.

This has come up in several DEP5 discussions over the past ~year, as
well as several recent mentions:

https://www.google.com/search?q=spdx+site%3Alists.debian.org

-- 
Kind regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee77f75.9090...@pbandjelly.org

Re: Work-needing packages report for Dec 9, 2011

[David Prévot]

Le 13/12/2011 06:51, Tollef Fog Heen a écrit :
> ]]  (Marco d'Itri)
> 
>> On Dec 09, Tollef Fog Heen  wrote:
>>
>>> Maybe we should consider closing those bugs after a while?  While I'm
>>
>> Maybe we should ask the maintainers?
>> e.g. ppp still needs a lot of help.
> 
> I don't doubt that the packages might still need help, but I don't think
> an RFH is going to get you help when it's been open for ages.

Please note that the NM process, in Tasks and Skills, asks to “find a
bug to fix. For example you can look into […] wnpp-alert”. Because of
that, I happened to actually address part of a four years old RFH when I
went through the process.

Regards

David



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-scala-maint] Binary blobs in source packages

[Mehdi Dogguy]

On 12/13/2011 01:23 PM, Thomas Koch wrote:
> 
> So is it ok to ship binaries in the source package that are only 
> required during build? Can I do the same with simple-build-tool, 
> which requires itself to build?
> 

Depends on the need. It is quite common for compilers to have some
binaries to do the bootstrapping. Scala uses that since some parts of
the compiler are written in scala. And, of course, I make sure that I
ship new binaries only in the Debian package. Another example is OCaml
which needs an ocamlc to bootstrap itself.

I'm not sure yet if it is really justified for simple-build-tool. I was
planning to have a look at it, but didn't find time to actually do that.
IIRC, another issue is that simple-build-tool requires network access
during the build… I guess it can be fooled somehow but didn't check yet.

Regards,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee7938b.2000...@dogguy.org

Re: [Pkg-scala-maint] Binary blobs in source packages

[Steve Langasek]

On Tue, Dec 13, 2011 at 07:03:55PM +0100, Mehdi Dogguy wrote:
> On 12/13/2011 01:23 PM, Thomas Koch wrote:

> > So is it ok to ship binaries in the source package that are only 
> > required during build? Can I do the same with simple-build-tool, 
> > which requires itself to build?

> Depends on the need. It is quite common for compilers to have some
> binaries to do the bootstrapping. Scala uses that since some parts of
> the compiler are written in scala. And, of course, I make sure that I
> ship new binaries only in the Debian package. Another example is OCaml
> which needs an ocamlc to bootstrap itself.

I think the traditional expectation here is that compilers will do their
initial bootstrap using an out-of-archive binary, and that once in the
archive, they'll be maintained using a self-build-depends instead.

Shipping no-longer-needed bootstrap binaries in the source package is a
borderline case.  It's probably ok if we have the source needed to build
that binary.  But we ought not need to use it for the actual package build.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [Pkg-scala-maint] Binary blobs in source packages

[Mehdi Dogguy]

On 12/13/2011 07:26 PM, Steve Langasek wrote:
> On Tue, Dec 13, 2011 at 07:03:55PM +0100, Mehdi Dogguy wrote:
>> On 12/13/2011 01:23 PM, Thomas Koch wrote:
> 
>>> So is it ok to ship binaries in the source package that are only
>>>  required during build? Can I do the same with simple-build-tool,
>>>  which requires itself to build?
> 
>> Depends on the need. It is quite common for compilers to have some 
>> binaries to do the bootstrapping. Scala uses that since some parts
>> of the compiler are written in scala. And, of course, I make sure
>> that I ship new binaries only in the Debian package. Another
>> example is OCaml which needs an ocamlc to bootstrap itself.
> 
> I think the traditional expectation here is that compilers will do
> their initial bootstrap using an out-of-archive binary, and that once
> in the archive, they'll be maintained using a self-build-depends
> instead.
> 

You mean having a circular build-dependency? That isn't great :/
I've seen some packages doing that (don't recall which right now) but
didn't like it, tbh.

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee79983.2040...@dogguy.org

Re: [Pkg-scala-maint] Binary blobs in source packages

[Steve Langasek]

On Tue, Dec 13, 2011 at 07:29:23PM +0100, Mehdi Dogguy wrote:
> > I think the traditional expectation here is that compilers will do
> > their initial bootstrap using an out-of-archive binary, and that once
> > in the archive, they'll be maintained using a self-build-depends
> > instead.

> You mean having a circular build-dependency?

Yes.

> That isn't great :/

 It's how self-hosting compilers work.  That's how the gcc package
works, too. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [Pkg-scala-maint] Binary blobs in source packages

[Joachim Breitner]

Hi,

Am Dienstag, den 13.12.2011, 19:29 +0100 schrieb Mehdi Dogguy:
> You mean having a circular build-dependency? That isn't great :/
> I've seen some packages doing that (don't recall which right now) but
> didn't like it, tbh. 

ghc does, for instance.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: This is a digitally signed message part

Re: [Pkg-scala-maint] Binary blobs in source packages

[Adam Borowski]

On Tue, Dec 13, 2011 at 10:45:21AM -0800, Steve Langasek wrote:
> On Tue, Dec 13, 2011 at 07:29:23PM +0100, Mehdi Dogguy wrote:
> > > I think the traditional expectation here is that compilers will do
> > > their initial bootstrap using an out-of-archive binary, and that once
> > > in the archive, they'll be maintained using a self-build-depends
> > > instead.
> 
> > You mean having a circular build-dependency?
> 
>  It's how self-hosting compilers work.  That's how the gcc package
> works, too. :)

GCC can be built using any other C compiler, though, so there's no freeness
or security issue (Ken Thompson can explain why this is important).

In some cases (like Smalltalk) this degenerates into a binary quine rather
than providing real source.


Do you remember my joke package "goodbye" a while ago?  One of ideas in the
resulting discussion was to put a quoted ELF object into debian/rules, that
compiles itself from a provided source (so the letter of the Policy and DFSG
is fulfilled), doing some Ken Thompsonese modifications on the way -- hey,
these are allowed in the archive as required by compilers you're talking
about.  Somehow, this idea met the most revulsion, I wonder why.

-- 
1KB // Yo momma uses IPv4!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213193017.ga25...@angband.pl

Re: [Pkg-scala-maint] Binary blobs in source packages

[Mehdi Dogguy]

On 12/13/2011 07:26 PM, Steve Langasek wrote:
> On Tue, Dec 13, 2011 at 07:03:55PM +0100, Mehdi Dogguy wrote:
>> On 12/13/2011 01:23 PM, Thomas Koch wrote:
> 
>>> So is it ok to ship binaries in the source package that are only 
>>> required during build? Can I do the same with simple-build-tool, 
>>> which requires itself to build?
> 
>> Depends on the need. It is quite common for compilers to have some
>>  binaries to do the bootstrapping. Scala uses that since some
>> parts of the compiler are written in scala. And, of course, I make
>> sure that I ship new binaries only in the Debian package. Another 
>> example is OCaml which needs an ocamlc to bootstrap itself.
> 
> I think the traditional expectation here is that compilers will do 
> their initial bootstrap using an out-of-archive binary, and that
> once in the archive, they'll be maintained using a
> self-build-depends instead.
> 

oh, and actually, this is not guaranteed to always work… this is at
least the case with OCaml which performs rather strict checks during
compilation. (This happened already in the past where some core type
changed).

Regards,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee7abdb.5020...@dogguy.org

Re: [Pkg-scala-maint] Binary blobs in source packages

[Philipp Kern]

On 2011-12-13, Joachim Breitner  wrote:
> Am Dienstag, den 13.12.2011, 19:29 +0100 schrieb Mehdi Dogguy:
>> You mean having a circular build-dependency? That isn't great :/
>> I've seen some packages doing that (don't recall which right now) but
>> didn't like it, tbh.=20
> ghc does, for instance.

And we had some fun where it was about to disappear from the archive due
to a bad upload.  It would've required manual pseudo-binNMUs on all
architectures to get it back.

But then I don't see how you could avoid circular build-dependencies
with compilers written in their own language.  fpc/fp-compiler does the
same.

Kind regards
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjefdeu.6s1.tr...@kelgar.0x539.de

Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Roger Leigh]

Hi folks,

The above have been mentioned a few times during the course of the
year, but we're now at the point where all the prerequisites have
been satisfied, and there are no blockers present to proceed.

I've put a proposed set of packages at
  http://people.debian.org/~rleigh/sysvinit/
which I plan to upload to experimental soon, and then to unstable
following some testing.

If you have a few minutes to spare, some testing of the packages
would be appreciated, so make sure there are no corner cases we've
missed.  Upgrading initscripts should result in /etc/mtab being
switched to a symlink at the next reboot.  /lib/init/rw will also
no longer mount a tmpfs on reboot, though the directory itself will
need to remain until wheezy+1, due to the upgrade ordering--packages
migrate after initscripts has run its postinst, requiring its
continued presence.

I'd be grateful for any feedback.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213205414.gk17...@codelibre.net

Re: [Pkg-scala-maint] Binary blobs in source packages

[Lars Wirzenius]

On Tue, Dec 13, 2011 at 08:30:22PM +, Philipp Kern wrote:
> But then I don't see how you could avoid circular build-dependencies
> with compilers written in their own language.  fpc/fp-compiler does the
> same.

You can avoid it by having a bootstrap compiler written in another
suitable language, which is capable (even if just) of building the
real compiler. So you write two compilers, A and B. A is written
in, say, AWK or Perl, and compiles the source code for B into
executable code. The executable B is then used to actually compile
software written in the language in question. Indeed, during the
package build, you would build the compiler first with A, and then
again with B, and the binary package would contain just the binary
built with B.

The benefit of the simple bootstrapping compiler A is that it can
often be written quite simply (and, indeed, might not be a real
compiler at all, just an interpreter), and does not need, for example,
to have any optimization phase at all. The only program it ever
needs to compile is B.

Even so, writing A is a fair bit of effort, and many language
implementers don't do that. Which makes things harder for distros,
but nobody cares about the poor distro developer.

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


signature.asc
Description: Digital signature

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[brian m. carlson]

On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:
> If you have a few minutes to spare, some testing of the packages
> would be appreciated, so make sure there are no corner cases we've
> missed.  Upgrading initscripts should result in /etc/mtab being
> switched to a symlink at the next reboot.  /lib/init/rw will also
> no longer mount a tmpfs on reboot, though the directory itself will
> need to remain until wheezy+1, due to the upgrade ordering--packages
> migrate after initscripts has run its postinst, requiring its
> continued presence.
> 
> I'd be grateful for any feedback.

You probably want to handle the case where /etc/mtab is a symlink to
/proc/self/mounts as well, since it's equivalent, and I know some people
(read: at least me) have already made that change.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [Pkg-scala-maint] Binary blobs in source packages

[Stéphane Glondu]

Le 13/12/2011 21:30, Philipp Kern a écrit :
> But then I don't see how you could avoid circular build-dependencies
> with compilers written in their own language.  fpc/fp-compiler does the
> same.

OCaml, F# (and Scala, it seems) do that by targetting a bytecode for
which there exists an independent interpreter (resp. OCaml's own
bytecode, .NET, Java). A (cross-platform) binary is then bundled with
the sources and is used for initial bootstrap.

In the OCaml case, a bytecode compiler (ocamlc) is bundled in the
upstream tarball, and the build system recompiles it until it reaches a
fixpoint. There are also native code backends for selected architectures
that can be compiled easily once everything has been compiled in bytecode.

-- 
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee7c1ef.8060...@debian.org

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Roger Leigh]

On Tue, Dec 13, 2011 at 09:08:10PM +, brian m. carlson wrote:
> On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:
> > If you have a few minutes to spare, some testing of the packages
> > would be appreciated, so make sure there are no corner cases we've
> > missed.  Upgrading initscripts should result in /etc/mtab being
> > switched to a symlink at the next reboot.  /lib/init/rw will also
> > no longer mount a tmpfs on reboot, though the directory itself will
> > need to remain until wheezy+1, due to the upgrade ordering--packages
> > migrate after initscripts has run its postinst, requiring its
> > continued presence.
> > 
> > I'd be grateful for any feedback.
> 
> You probably want to handle the case where /etc/mtab is a symlink to
> /proc/self/mounts as well, since it's equivalent, and I know some people
> (read: at least me) have already made that change.

It does--it will switch to /proc/mounts unless /etc/mtab is already
a symlink to /proc/mounts.  It will therefore correct any symlinks
which point to other places as well as the usual case of it being a
file.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213213240.go17...@codelibre.net

Re: Switching /etc/mtab to /proc/mounts and removing /lib/init/rw

[Roger Leigh]

On Tue, Dec 13, 2011 at 09:32:40PM +, Roger Leigh wrote:
> On Tue, Dec 13, 2011 at 09:08:10PM +, brian m. carlson wrote:
> > On Tue, Dec 13, 2011 at 08:54:14PM +, Roger Leigh wrote:
> > > If you have a few minutes to spare, some testing of the packages
> > > would be appreciated, so make sure there are no corner cases we've
> > > missed.  Upgrading initscripts should result in /etc/mtab being
> > > switched to a symlink at the next reboot.  /lib/init/rw will also
> > > no longer mount a tmpfs on reboot, though the directory itself will
> > > need to remain until wheezy+1, due to the upgrade ordering--packages
> > > migrate after initscripts has run its postinst, requiring its
> > > continued presence.
> > > 
> > > I'd be grateful for any feedback.
> > 
> > You probably want to handle the case where /etc/mtab is a symlink to
> > /proc/self/mounts as well, since it's equivalent, and I know some people
> > (read: at least me) have already made that change.
> 
> It does--it will switch to /proc/mounts unless /etc/mtab is already
> a symlink to /proc/mounts.  It will therefore correct any symlinks
> which point to other places as well as the usual case of it being a
> file.

Actually, /proc/self/mounts would be preserved; any symlink into
/proc is considered acceptable.  Anything else would be changed.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213213430.gp17...@codelibre.net

Managing left-over control files

[Malte Forkel]

Hi,

I'm writing a transitional package to handle a software name change.
The transitional package 'depends' on the new package, which itself
'replaces' the old package and takes over some of its control files.
All other control files still belong to the transitional package after
an upgrade.

I have to remove some of those old control files, because they are in
conflict with files from the new package.  But then I think I should
also make the transitional package forget about them.

How do I properly handle the old control files?  How do I tell a package
that a specific file does not belong to this package anymore?  I guess
the same questions might arise when the set of control files changes
with a new package version.

Thanks,
Malte


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jc8lfe$7d5$1...@dough.gmane.org

Bug#651998: ITP: v3c-2.4.0-01 -- v3c utility toolkit

[Philip A. Ashmore]

Package: wnpp
Severity: wishlist
Owner: "Philip A. Ashmore" 

* Package name: v3c-2.4.0-01
  Version : 2.4.0
  Upstream Author : Philip Ashmore 
* URL : http://sourceforge.net/projects/v3c/
* dsc file  :
http://mentors.debian.net/debian/pool/main/v/v3c/v3c_2.4.0-01-1.dsc
* License : LGPLv3
  Programming Lang: C, C++,Make,sh,m4
  Description : v3c utility toolkit



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111213230053.3903.53680.reportbug@potemkin.local

Re: Bug#651998: ITP: v3c-2.4.0-01 -- v3c utility toolkit

[Cyril Brulebois]

Philip A. Ashmore  (13/12/2011):
> Package: wnpp
> Severity: wishlist
> Owner: "Philip A. Ashmore" 
> 
> * Package name: v3c-2.4.0-01

Certainly that's not the package name?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Hardening release goal blocker

[Kees Cook]

Hi,

So, recently it came to my attention that CDBS is not behaving very nicely
with dpkg-buildflags, which is causing problems for us to meet the release
goal of getting more packages built with compiler hardening enabled:
https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags

Notably, I'm curious about this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651964

I think this is broken behavior on CDBS's part, and that the "some
packages" mentioned should be fixed so that all the other packages aren't
hampered by the problem.

This is especially true in the face of:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651966

Which means there's no way sort of calling dpkg-buildflags directly to get
a fully hardening build using only CDBS. :(

What's the right way forward to have CDBS and dpkg-buildflags play nice
together? :)

Thanks,

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111213231042.gp5...@outflux.net

Re: Hardening release goal blocker

[Jonas Smedegaard]

Hi,

On 11-12-13 at 03:10pm, Kees Cook wrote:
> Hi,
> 
> So, recently it came to my attention that CDBS is not behaving very 
> nicely with dpkg-buildflags, which is causing problems for us to meet 
> the release goal of getting more packages built with compiler 
> hardening enabled: 
> https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
> 
> Notably, I'm curious about this: 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651964
> 
> I think this is broken behavior on CDBS's part, and that the "some 
> packages" mentioned should be fixed so that all the other packages 
> aren't hampered by the problem.
> 
> This is especially true in the face of:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651966
> 
> Which means there's no way sort of calling dpkg-buildflags directly to 
> get a fully hardening build using only CDBS. :(
> 
> What's the right way forward to have CDBS and dpkg-buildflags play 
> nice together? :)

I would be happy to change CDBS to always behave sanely (i.e. make 
CDBS_FIX_COMPILE_FLAGS=1 the default behaviour).

This wouldm however, require someone to do the work of investigating and 
correcting any and all packages in the Debian archive that depends on 
the older arguably broken behaviour.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Zachary Harris]

Package: general
Severity: serious
Justification: Policy 10.1.1

My understanding of the FHS would be that if a library is a dependency of a
binary in /bin or /sbin, then such library belongs in /lib, not
/usr/lib. (If
for some reason the library is also desired in /usr/lib then a sym link from
/lib to /usr/lib, but not the other way around, is acceptable.) A review of
past bug reports (e.g. #633019 and #639939 from this summer) shows that this
policy gets repeatedly violated in Debian until someone catches it.

Here is a test to reveal the current culprits on my own Squeeze
installation:
> ldd /{s,}bin/* | /bin/grep usr | cut -f1 -d"(" | sort -u
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2
libdiscover.so.2 => /usr/lib/libdiscover.so.2
libexpat.so.1 => /usr/lib/libexpat.so.1
libfuse.so.2 => /usr/lib/libfuse.so.2
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0
libhal.so.1 => /usr/lib/libhal.so.1
libhal-storage.so.1 => /usr/lib/libhal-storage.so.1
libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0
libnl.so.1 => /usr/lib/libnl.so.1
libntfs-3g.so.75 => /usr/lib/libntfs-3g.so.75
libntfs.so.10 => /usr/lib/libntfs.so.10
libpcsclite.so.1 => /usr/lib/libpcsclite.so.1
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
libz.so.1 => /usr/lib/libz.so.1

Here is one objective test of conformity to this aspect of the FHS
requirements. The command "ldd /{s,}bin/* | /bin/grep usr" (or something
equivalent) should return nothing. (Well, OK, there could be weird
exceptions
where the string "usr" appeared in the name of an essential binary or
library,
but you get my point.)

-Zach



-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/blu0-smtp70e86e886a077f968d6396a6...@phx.gbl

Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Russ Allbery]

Zachary Harris  writes:

> My understanding of the FHS would be that if a library is a dependency
> of a binary in /bin or /sbin, then such library belongs in /lib, not
> /usr/lib. (If for some reason the library is also desired in /usr/lib
> then a sym link from /lib to /usr/lib, but not the other way around, is
> acceptable.) A review of past bug reports (e.g. #633019 and #639939 from
> this summer) shows that this policy gets repeatedly violated in Debian
> until someone catches it.

I'm increasingly convinced by the recent discussion on debian-devel that
doing all the (rather substantial) work required to keep this separation
working is a waste of our collective time.  We're not doing a very good
job at it anyway, chasing all the library dependencies is a fair amount of
work, and things have to keep moving around as dependencies change.  And
this is all to support use cases that, while real, are fairly marginal in
my estimation.  This does not seem like the most effective place for us to
be spending our time.

I don't know if it's worth the effort to unify /bin and /usr/bin or the
other similar things that have been discussed from time to time, but I do
think it may be time for Debian to just officially say that we don't
support /usr on a (meaningfully) separate partition from /bin and /lib,
and that binaries in /bin may have dependencies on /usr/lib.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcpjbve3@windlord.stanford.edu