Re: About repackaging of the ‘orig’ tarball.

[Jonathan Nieder]

Hi Charles,

Charles Plessy wrote:
> Le Tue, Dec 08, 2009 at 05:36:54PM +0100, Damien Raude-Morvan a écrit :

>> As a general guideline, generated files should be stripped from "original"
>> source tarballs.
[...]
> I personnally tend to prefer to keep the Debian ‘orig’ tarball identical to 
> the
> upstream tarball as much as it is possible, so that by its MD5 sum it is
> obvious that it is pristine.

Thank you for bringing this up.  I am not an ftpmaster, but maybe it
would be helpful to mention some other reasons to keep the
.orig.tar.gz pristine.

By distributing the pristine source, we provide a service to the free
software community outside of Debian.  When upstreams silently
disappear, distros take over as the main distribution point for their
software.  Similarly, sometimes the only place to find an older
version of a package is in the various distros’ archives.

Having to repack makes trouble for people trying to help package a new
upstream version.  A nice repacking script can help, but not by much.
Any potential contributer still has to figure out how it works and
make sure everything goes to plan.  Ignoring the files or deleting
them in the 'clean' target is much simpler.

Often, files the buildds do not use can be helpful for other users.
Configure scripts, source files generated by bison or web, and
processed documentation often fall into this category.  Patent-
encumbered code can sometimes, too.

On the other hand, some files in the upstream tarball really may be
useless for everybody.  This should be fixed upstream!  Having to
maintain a repacking script over several releases to work around
such a simple problem is really not a good sign for a packager
maintainer’s relationship with upstream.

The second reason above is most important to me: it is really
unpleasant to fight against repacking scripts.  If the terms of
redistribution make this trouble necessary, I grumble and bear it.
The rest of the time, I would like to avoid it.

Just my 2 cents.

Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git-core maintenance

[Jonathan Nieder]

Hi,

Ramkumar Ramachandra wrote:

> I found that the package git-core has several outstanding bugs filed
> against it. Many of them are poorly tagged, and their status has not
> been updated in quite some time.

It might be helpful to read this: [1]

> After that, I tried asking
> the maintainer to make a new release incorporating bugfixes.
> Unfortunately, the maintainer's email address listed on the Debian
> bugs page seems to be broken.

FWIW, while he does not always respond immediately, I’ve found Gerrit
to be generally responsive and thoughtful.  Sometimes a new release is
packaged the day it is tagged upstream; rarely does it take more than
a couple of weeks.

> Therefore, I would like to politely urge
> someone with some additional time on their hands to contact the
> maintainer/ adopt the package.

I do not think a new maintainer is warranted, but I do think someone
is needed to help deal with bugs.  Thanks for your efforts in this
regard so far.

Thanks for bringing this up,
Jonathan

[1] http://kitenet.net/~joey/blog/entry/a_clean_BTS_is_a_sign_of_a_sick_mind/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git-core maintenance

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> Just to clarify, the issue is not his seeming non-responsiveness, but
> emails bouncing.

Oh!  Thanks for the clarification.

Sorry for the confusion,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Jonathan Nieder]

John Goerzen wrote:
> On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
>> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
>> package.
>
> I am doing the same, for the very simple reason that every other
> approach I've seen violates the KISS (Keep It Simple, Stupid)
> principle.

> I am not a fan of git-rebase due in part to the difficulty of working
> with others, but also in part due to the difficulty of tracking how
> your differences from upstream change over time.  All the
> debian/patches systems I have seen suffer from both of these flaws.

I don’t strongly disagree, but consider for a moment a method that
tries to work around these flaws.  It uses dpkg source format
3.0 (quilt).

There are three branches: master, upstream, and upstream+patches.

 - master:  patched source (including debian/ dir)
 - upstream:upstream source
 - upstream+patches:patched source (w/o debian/ dir)

upstream+patches is rebuilt for each new upstream version by
cherry-picking the relevant commits.  I haven’t scripted this, but
it would not be hard to.

This method has a few advantages:

 - upstream can pull directly from you if they like all your patches
 - you can work on and test the patched source by building off of the
   upstream+patches branch
 - it is easy for others to find your patches, in a form that does not
   require any forward porting.
 - if you generate your debian/patches directory with git format-patch,
   dpkg will check that master and upstream+patches tell the same story.

If you don’t mind the occasional duplicate commit, for new fixes you
can work against upstream+patches and then merge it into master, though
I don’t do this.

FWIW I have been using this method and it’s not so bad.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

dpkg source format 3.0 (git)

[Jonathan Nieder]

Henrique de Moraes Holschuh wrote:

> Given the size of the .git dir when you're not using something like stgit
> and have all objects properly packed, one could even consider shipping .git
> inside the package if it is small enough.
> 
> Is that a proper way to do this?  Or would we need a new 3.0 format variant
> to do it right (assuming we want to do that) ?

There has been talk [1] of a format variant that uses git bundles to do
that efficiently, but nothing concrete.  To me, it seems like a good idea.

A few points [2] to keep in mind:

 - People can easily download source packages to access the original
   source and Debian changes without too much technical
   sophistication.  Even a quilt series is just a series of patches so
   it doesn’t require specialized tools.  So there is precedent for
   making it easy to access a source package from Debian.

   Will ‘git’ ever be as ubiquitous as ‘patch’?  If the source package
   is something you can ‘git clone’ to get a repository with
   appropriate ‘master’ and ‘origin/upstream’ branches, is that good
   enough?  Probably. ;-)

 - The bundle needs to be clonable without use of any external object
   repository.  The bundle ought to have branches ‘master’ and
   ‘upstream’, relevant tags, maybe a ‘pristine-tar’ branch, and not
   much extra junk.

 - To be included in Debian main, everything in the bundle should meet
   the free software guidelines (right?); practically speaking, this
   means the history would very often be cauterized when the project
   is first packaged for Debian.

   Maybe some of the damage from this could be mitigated by including
   a suitable grafts file or refs for use by ‘git replace’.

 - Including the whole history with each upload and forcing users and
   buildds to reclone with each download would be unpleasant.  (This
   can be turned around: with work, a git-based format might be able
   to decrease bandwidth use for sites like snapshots.debian.org.)

 - Bundles are hard to recreate.  If they were to be created on the
   fly some way as in the previous item, the md5sums are not stable.
   Just something to think about.

Thoughts?  Especially, if anyone would like to talk implementation,
let me know.  It sounds difficult to do right, but there’s no harm in
experimenting.

The easiest way to try this out now is to include a bundle in the
source tarball (ugh) and clone it at build time.  If you’re doing
that, please let me know how it goes.

Jonathan

[1] http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/11234
[2] Thanks to Goswin for many of these:
http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/11234/focus=11264


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dpkg source format 3.0 (git)

[Jonathan Nieder]

Goswin von Brederlow wrote:

> 1) Think about doing this for linux-2.6, XOrg or OOo and what it would
> mean for the source size or usability.

Indeed, the history is pretty large.  A rough estimate (for something
less rough, one should use a well packed bundle with only the objects
of interest):

 $ pwd
 /home/jrn/src/linux-2.6
 $ git status -u
 # On branch next
 nothing to commit (working directory clean)
 $ du -sk .git
 440664  .git
 $ du -sk --exclude=.git .
 450920  .
 $ du -sk ../linux-2.6.33-rc7.tar.bz2 
 64648   ../linux-2.6.33-rc7.tar.bz2

The source package would become about 7 times as large.

For usability: I imagine what is typically needed is the set of Vcs-Git
fields somewhere conveniently machine-readable, so one could just go

apt-get source --git whatever

and get a checkout of its packaging repository.

That would be the 90% solution.  What it doesn’t do is help people with
poor connectivity to hack on a package like linux-2.6.  Given the high
quality of commit messages and the sparsity of comments on the
implementation, it is really much easier to work with the history in
hand.

So it would be nice (though hard) to find some method that allows the
git history to be widely mirrored, included on distributed DVDs, and
so on.  I’m sure the admins of kernel.org would appreciate it as well.

> Uploading a new source could then be sending a signed ref to the
> maintainers git or sending a signed bundle or even just pushing and
> setting a tag.

I imagine that would be very nice for people with large packages.
Maybe something similar could be accomplished for existing
tarball+changes packages by providing a "proxy" git server that runs
dpkg-source -b server side.

Selfishly, I guess if someone implements the 90% solution above, I
would stop caring so much about what source format the buildds use.
Others might be more principled, though. ;-)

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: dpkg source format 3.0 (git)

[Jonathan Nieder]

Jonathan Nieder wrote:

> For usability: I imagine what is typically needed is the set of Vcs-Git
> fields somewhere conveniently machine-readable, so one could just go
> 
>   apt-get source --git whatever
> 
> and get a checkout of its packaging repository.

... which is what debcheckout provides, though I didn’t know it.  Thanks
to Stefano Zacchiroli for writing it!

> Selfishly, I guess if someone implements the 90% solution above, I
> would stop caring so much about what source format the buildds use.
> Others might be more principled, though. ;-)

So indeed, I do not think git-based distributed source packages are
worth worrying about yet.  In those places where git.debian.org and co
are not good enough, I suspect it would be a better use of time to try
to improve connectivity.

Jonathan


-- 
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/20100216215855.ga3...@progeny.tock

Re: Changes in dpkg Pre-Depends

[Jonathan Nieder]

Guillem Jover wrote:

> Regarding xz-utils' size, I was just checking and it seems not all
> programs are linking against liblzma, by passing --enable-dynamic to
> both configure lines the package gets reduced to 396 KiB. Also by
> not shipping xzdec and lzmadec the package gets down to 324 KiB.
> 
> Jonathan, any reason why those are not dynamically linked?

The usual i386-centric reason: the PIC version is (~5%) slower than
the non-PIC version.  See PACKAGERS in the source, section 4.1.
I considered doing this only on i386, but since I only have an i386 to
test on, I would worry about missing packaging bugs.

I could very easily be convinced to switch to dynamic linking.  Please
file a bug (with what you just said about size and any other reasons).


-- 
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/20100223050612.ga8...@progeny.tock

Bug#571060: xz-utils: give xzdec and lzmadec their own package

[Jonathan Nieder]

Package: xz-utils
Version: 4.999.9beta+20100212-1
Severity: wishlist

Guillem Jover wrote:

> Also what's
> the point of shipping the xzdec and lzmadec tools in the main package?
> It seems they would make sense as part of another package as tiny
> decompressors-only, but no in addition to the main tools as those
> already provide the whole functionality?

Indeed.

xzdec and lzmadec are meant mostly for copying to small media with
lots of xz- or lzma-compressed files (for distribution).  They don’t
belong in the xz-utils package, so let’s move them.

Thanks,
Jonathan



-- 
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/20100223051026.gb8...@progeny.tock

Optimization for slow platforms (Re: Changes in dpkg Pre-Depends)

[Jonathan Nieder]

Thomas Weber wrote:
>>> Le mardi 23 février 2010 à 14:43 +0100, Marco d'Itri a écrit : 
 Using non-PIC code for a 5% speed up looks like an acceptable trade off
 to me, but it really must be restricted only to architectures which
 need it.
[...]
> You have x86 hardware that is so old that it doesn't run amd64, but at
> the same moment you care about speed?

Yes, it is when you are stuck on a computer like this one that slow
programs really start to feel painful.

IMHO the choice of what to optimize should be based on what code is
used most often (or whose running time is particularly harmful for
other reasons), not what happens to be running on the most expensive
hardware.

In this case the speed difference from using non-PIC code is
noticeable.  But the memory pressure from not sharing code between
processes might mean it is not worth it --- I am really torn.

Jonathan


-- 
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/20100223183137.ga7...@progeny.tock

Re: Optimization for slow platforms

[Jonathan Nieder]

Marco d'Itri wrote:

> If the programs are linked statically then they will have the same
> memory footprint of programs linked with non-PIC libraries, so the
> situation will not be worse in this sense.

On non-i386 architectures, I will turn on --enable-dynamic to link to
the current PIC library.  There’s no good reason not to.

Neglecting xzdec and lzmadec, [*] the only binaries in the xz-utils
package are xz and lzmainfo.

For i386, there are three obvious options:

1. Use the default settings (as I do now).  That means xz links to
   static liblzma and lzmainfo is dynamically linked to the PIC liblzma.

2. Build a non-PIC liblzma and link everything to it.

3. Build a PIC liblzma and link everything to it.

The cost of doing 1 over 3: we waste around 128 KiB of disk space for
the xz binary and about 128 KiB of nonsharable text for each xz
instance.

The cost of 2 is potentially higher.  There has to be another copy of
the approx 128 KiB of nonsharable text for every process that uses
liblzma.  Plus it adds to the startup time and can hurt the security
of every process linking to it.

Jonathan

[*] Why?  Because they should not be in the xz-utils package anyway.
Put together, they are much smaller than liblzma, and that is the only
reason for them to exist.


-- 
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/20100223215219.ga8...@progeny.tock

Re: Changes in dpkg Pre-Depends

[Jonathan Nieder]

Josselin Mouette wrote:
> Le mardi 23 février 2010 à 20:32 +0100, Marco d'Itri a écrit : 

>> Anyway, there are often good reasons to use x86 on modern hardware
>> (think about laptops and smaller VPSes).
>
> You mean, like saving memory?
> 
> Wait… wouldn’t you save more memory by using shared libraries and PIC
> code?

I fear you are wasting your wit.  Please, convince me that using PIC
is the right thing.  I know non-PIC code wastes memory.  It makes
administering an selinux system harder.  It adds to per-process
startup time. [1]  Unfortunately, a realistic scenario where this
makes xz much more painful to use hasn’t occured to me and I am not
sure how to quantify these effects and weigh them against a running
time difference that is noticeable.

Relevant context:

 - the text size of liblzma on i386 is only 128 KiB;

 - unless I hear some overwhelming reason to, I am not interested in
   turning liblzma.so on the i386 into a non-PIC library.  I am just
   trying to decide whether to link xz to the .a or the .so on i386;

 - there is another binary in the same package that links to
   liblzma.so already.

If linking to the .so would help with security support or something,
just let me know and I’ll do it.

Thanks,
Jonathan

[1] These effects are briefly explained in
, for example.


-- 
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/20100223223110.ga8...@progeny.tock

Re: Changes in dpkg Pre-Depends

[Jonathan Nieder]

Hi Russ,

Russ Allbery wrote:

> That being said, a 5% performance gain from using statically linked
> non-PIC code doesn't strike me as very compelling even for older systems.

Thank you for your candor; even a hunch like this one is the sort of thing
I was interested to hear.

I got the 6-7% difference (I rounded down) using dynamically linked
non-PIC code.  I measured it that way because it seemed more like an
apples-to-apples comparison. [1]

I am a bit disappointed: I was hoping to learn some more concrete
reasons to avoid this sort of use of static linking, but most of the
responses were snarks.  Thanks at least for setting me straight.

Kind regards,
Jonathan

[1] Details:

Default preset, using the command xz --stdout zlib-1.2.3.7.tar >/dev/null
xz is run in place in the build tree, which means there is also some
overhead (though I doubt it is noticeable) from the libtool wrapper
script.

The “xz in cache” numbers involve running “xz --version” twice before
each run to get xz and the libraries it needs into the cache.

All numbers are best-of-3, so not precise at all.

PIC (s) no PIC (s)  difference as % of PIC
hot cache:  9.034   8.386   7
cold cache: 9.480   8.931   6
xz in cache:9.110   8.440   7

/proc/cpuinfo tells me the CPU is Intel family 6, model 8, 601.363 MHz,
cache size 128 KB.  (model 8 seems to mean it has 256 KB on-die L2.)


-- 
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/20100223225221.ga8...@progeny.tock

Tradeoffs of static linking (Re: Changes in dpkg Pre-Depends)

[Jonathan Nieder]

Russ Allbery wrote:

[... explanation of the tradeoffs snipped ...]
> Note, btw, that for some algorithms, you might gain significant speed,
> more than the PIC difference, by being able to compile for more capable
> processors (enabling SSE2 can make a huge difference, for instance).
> Shared libraries let you do that, by building multiple copies of the
> shared library and installing them into the capability-based library
> paths.  OpenSSL does this.

Very nice writeup.  I like the thought that it might be possible later
to get some of the speed back from this change.  Focusing on speeding
up liblzma is a better strategy overall, since it would benefit other
programs, too.

Thanks again,
Jonathan


-- 
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/20100224011744.ga16...@progeny.tock

Re: [New pre-depends] SElinux support for findutils.

[Jonathan Nieder]

Santiago Vila wrote:
> On Sat, 3 Apr 2010, Andreas Metzler wrote:

[...]
>> This requires linkage against libselinux1. There is no problem with
>> priorities, both packages are Priority: required.
>> 
>> Since findutils is essential, the respective dependency ends up in
>> Pre-Depends. Which is why I am starting discussion on d-d. Personally
>> I do not care a lot. I am not using SElinux but the feature has been
>> explicitely requested by a user in #572809.
>
> This is not a "new pre-depends" strictly speaking,

I thought the point of discussing pre-depends in advance was to

(1) discourage using pre-depends, since they can make upgrades slower
or in the worst case impossible; and

(2) make it very difficult to produce a Pre-Depends loop by accident.

So I am not sure where the question of novelty comes in.

> so I'd say: go ahead.

Still, I agree with the conclusion.  This sounds to me like useful
functionality for systems with SELinux enabled, implemented in a good
way.

IANADD, HTH, HAND,
Jonathan


-- 
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/20100403233033.ga...@progeny.tock

The 'git' Debian package in squeeze and possible mass bug filing

[Jonathan Nieder]

Hello,

Gerrit Pape wrote:

> I'm about to provide a new git binary package from the git-core (the
> distributed revision control system) source, so that 'apt-get install
> git' installs the git content tracker in squeeze.

A new version 1.7.0.4-2~exp0 of git has been uploaded to experimental,
with the source and main binary package renamed to git.  There is a
note in the NEWS.Debian.gz to help with the transition.  Please try it
out and let us know if you find any problems.

If the git-core package is removed, it is no longer available to
satisfy dependencies.  For most packages, this is no problem, since
git Provides: git-core.  However, a Provides: does not satisfy a
versioned dependency.

The affected packages are listed below.  For futureproofing and easy
backporting, I believe they should use

  Depends: git (>= 1:1.7) | git-core (>= whatever)

gnuit never had an epoch, so such a dependency would be safe.

Now that there is a package available to test with, I would like to
file bugs for the affected packages suggesting this change.  I suggest
an RC severity since it would be nice to have the name change in
squeeze.  I am therefore Cc-ing the release team for their input.

A list of affected packages follows.  Thoughts welcome.

 - Jonathan

Andrea Corradi 
   giggle --- Depends, Build-Depends: git-core (>= 1.5.6.3)

Debian Python Modules Team 
   python-git (U) --- Depends: git-core (>= 1.5.3.7)

Yann Dirson 
   stgit --- Depends: git-core (>= 1:1.5.3)

Vincent Fourmond 
   gitstats --- Depends: git-core (>= 1:1.5.2.4)

Guido Günther 
   git-buildpackage --- Depends: git-core (>= 1:1.5.0.1-1)

Wartan Hachaturow 
   qgit --- Depends: git-core (>= 1.3.0)

Sebastian Harl 
   tig --- Depends: git-core (>= 1.5.4)

Joey Hess 
   etckeeper --- Depends: git-core (>= 1:1.5.4)
   ikiwiki --- Recommends: git-core (>= 1:1.5.0)

Julien Lavergne 
   moap --- Suggests: git-core (>= 1:1.6.0)

Marc-Andre Lureau 
   moap (U) --- Suggests: git-core (>= 1:1.6.0)

Python Applications Packaging Team 
   moap (U) --- Suggests: git-core (>= 1:1.6.0)

Josh Triplett 
   ikiwiki (U) --- Recommends: git-core (>= 1:1.5.0)

Iulian Udrea 
   guilt --- Depends: git-core (>= 1.4)

Daniel Watkins 
   python-git --- Depends: git-core (>= 1.5.3.7)


-- 
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/20100408040536.ga27...@progeny.tock

Re: The 'git' Debian package in squeeze and possible mass bug filing

[Jonathan Nieder]

Julien Cristau wrote:
> On Wed, Apr  7, 2010 at 23:10:31 -0500, Jonathan Nieder wrote:
>
>> Now that there is a package available to test with, I would like to
>> file bugs for the affected packages suggesting this change.  I suggest
>> an RC severity since it would be nice to have the name change in
>> squeeze.  I am therefore Cc-ing the release team for their input.
>
> This is certainly not RC.  Please keep the transitional package for
> squeeze, and you can drop it (and make the bugs RC) post-release.

Good catch.  Apparently, the disappearing package trick (see
http://wiki.debian.org/Renaming_a_Package) would not be usable with
lenny package managers anyway, so the only advantage to fixing these
bugs before the release would be to allow users to remove the
transitional package.

Thanks for the hint.

Cheers,
Jonathan


-- 
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/20100408110402.ga26...@progeny.tock

Re: The 'git' Debian package in squeeze and possible mass bug filing

[Jonathan Nieder]

Hi Michael,

Michael Biebl wrote:

> Hm, making git-core a dummy/transitional package, which pulls the "git" 
> package
> on upgrades sounds like a better idea to me.
> Otherwise git won't be updated when going from lenny to squeeze.

Gerrit Pape implemented what I think is a nicer method: git-core is a
disappearing transitional package.  On upgrades, it pulls in git and
then disappears (since git takes over all its files).  It is a super
neat trick, due to Daniel Kobras, I think [1].

Just one problem: APT does not support that at the moment.  Oops.

> You can also change the rdeps more gradually, i.e. they won't break if you
> upload the new package to unstable now.

This could still happen by not having git take over the files from
git-core until the rdeps are taken care of.  Actually, here is what I
think is the best thing to do:

For squeeze, let git-core be a transitional package.  Its content will
consist of a compatibility symlink for the documentation directory, so
that a future version of git can replace it.  Meanwhile, teach APT and
aptitude (I haven’t checked aptitude yet) to handle disappearing
transitional packages, hopefully in time for squeeze.

For squeeze+1, once all the rdeps have been updated, add the
/usr/share/doc/git-core symlink to the git package.

We can drop the transitional package at the same time, but that
doesn’t matter; it might even be nice to keep it around to let
"apt-get install git-core" work for another release.

Cheers,
Jonathan

[1] http://lists.debian.org/debian-devel/2006/06/msg00014.html
http://wiki.debian.org/Renaming_a_Package


-- 
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/20100408123332.ga27...@progeny.tock

Re: The 'git' Debian package in squeeze and possible mass bug filing

[Jonathan Nieder]

Joey Hess wrote:

> You forgot to include packages that Suggest git-core in the list.

The only package with a versioned Suggest of git-core I found was
moap, which I did include.  Still, I wouldn’t be surprised if I missed
something for some other reason.

For what it’s worth, the list of affected packages was generated with
the script below.  Corrections welcome.

Jonathan

-- 8< --
#!/bin/sh
set -e
check() {
local rel=$1
shift

grep-dctrl -F$rel git-core -n -sPackage,$rel "$@" |
while :
do
read pkg || break
read deps
read newline
ver=$(
printf "%s\n" "$deps" |
sed -ne 's/^.*git-core (\([^)]*\)).*/\1/p'
)
if test "$ver"
then
printf "%s --- $rel: git-core (%s)\n" "$pkg" "$ver"
fi
done
}

for rel in Depends Recommends Conflicts Breaks Suggests Enhances
do
check "$rel" /var/lib/apt/lists/*_Packages
done
for rel in Build-Depends Build-Depends-Indep Build-Conflicts
do
check "$rel" /var/lib/apt/lists/*_Sources
done


-- 
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/20100408203655.ga31...@progeny.tock

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

[Jonathan Nieder]

Hi,

Simon Richter wrote:

> The problem at hand is the proposed (and implemented) solution for
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 .
[lxterm having higher priority than konsole on KDE systems]
>
> I'm unconvinced that bumping the priority on the other terminal
> emulators is an adequate solution, hence I'm opening this "general" bug
> for discussion on how to reflect individual users' choices properly.
>
> It has been suggested on #debian-devel that maybe creating a per-user
> ~/bin with its own alternatives links might be an option, however there
> needs to be a fallback mechanism in case the currently selected option
> goes away.

To make this concrete:

. unlike browsers with $BROWSER and desktop-specific settings, there
  is no standard, cross-distro way to make a user-specific choice of
  terminal

. apps integrated into Debian can and should be using
  x-terminal-emulator, without an explicit "/usr/bin/", as hinted at
  by policy §6.1 "Introduction to package maintainer scripts"

. therefore users can put a script implementing whatever policy they
  choose in ~/bin/x-terminal-emulator, but:

   1. that requires more know-how than many users have
   2. applications not integrated into Debian would just use xterm
  anyway, which is not so great.

To solve (1): an interested person could make an app that installs an
easily configurable ~/bin/x-terminal-emulator script.  This seems
like a rfp rather than a general bug, if anything.

To solve (2): one could introduce a TERMINAL environment variable
analogous to MAILER and implement xdg-terminal that reads it.  Please
clone this bug and assign to xdg-utils if interested.

Sensible?
Jonathan



-- 
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/20101124172454.ga1...@burratino

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

[Jonathan Nieder]

clone 348775 -1
reassign -1 xdg-utils 1.0.2+cvs20100307-3
retitle xdg-utils please introduce (sane) xdg-terminal
tags -1 + upstream
quit

Paul Wise wrote:

> In xdg-utils CVS there is an xdg-terminal script, not sure why that
> isn't available in Debian yet:

When no desktop is in use, it uses $TERM to choose a terminal,
so on this machine it would end up trying to run 'linux'. :)
Using $TERMINAL would fix that, I think.



-- 
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/20101125184355.gb17...@burratino

Re: Bug#605009: serious performance regression with ext4

[Jonathan Nieder]

Hi Ted,

Ted Ts'o wrote:

> 1) Suppose package contains files "a", "b", and "c".  Which are you
> doing?
> 
> a)  extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a);
> extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b);
> extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c);
> 
> or
> 
> b)  extract a.dpkg-new ; fsync(a.dpkg-new);
> extract b.dpkg-new ; fsync(b.dpkg-new);
> extract c.dpkg-new ; fsync(c.dpkg-new);
> rename(a.dpkg-new, a);
> rename(b.dpkg-new, b);
> rename(c.dpkg-new, c);
> 
> or
> 
> c)  extract(a.dpkg-new);
> extract(b.dpkg-new);
> extract(c.dpkg-new);
> fsync(a.dpkg-new);
> fsync(b.dpkg-new);
> fsync(c.dpkg-new);
> rename(a.dpkg-new, a);
> rename(b.dpkg-new, b);
> rename(c.dpkg-new, c);
> 
> 
> (c) will perform the best for most file systems, including ext4.
[...]
> I am guessing you are doing (a) today --- am I right?  (c) or (d)
> would be best.

We are doing (c) today.

Regards,
Jonathan


-- 
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/20101127075831.gc24...@burratino

Re: fails to purge not RC

[Jonathan Nieder]

Hi,

Holger Levsen wrote:
> On Donnerstag, 16. Dezember 2010, Jonathan Nieder wrote:

>> Could you elaborate?  I would think that making "dpkg --purge" exit
>> with nonzero status would be serious, though perhaps of the can-defer
>> kind.
>
> It's annoying, it will probably leave cruft and it's a policy violation. But 
> that about it. The exit code is trivial to workaround (just expect that purge 
> will fail for some package, it's a safe bet) and there are basically no 
> consequences. (Except cruft on the system.) 

It means you cannot delete the old configuration and start over.
Sometimes packages include configuration that affects other packages
in the system (e.g., init scripts) and the ability to purge them
really is functionally important.

> At the end of this the dpkg database is in an ok state.
>
> So IMO nothing serious. Important, yes.

Ok.  I checked policy and all I can find on the subject is

Each script must return a zero exit status for success, or a
nonzero one for failure, since the package management system
looks for the exit status of these scripts and determines what
action to take next based on that datum

which leaves us with only common sense to decide the question "what
about maintainer scripts that never succeed?".  So policy agrees with
you.

(Breaking this feature of the packaging system is an important bug but
it seems it was never declared release-critical.  I am fine with that,
on reflection.)

>>> (Plus 27 packages, which even fail to install - but see #595652 for why I
>>> stopped filing those as serious atm and see
>>
>> Failure to install noninteractively sounds less severe[1] than failure
>> to purge.
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=595652
>
> You should have continued until msg=30 and 52 ;-) 

Of course I read the whole log.

> In short: failing to install non-interactivly is ie a problem for automated 
> installations and live-media builds. IOW: in getting the software deployed, 
> not getting rid off it. 
>
> At the end of this the dpkg database is _not_ in an ok state.
>
> That seems more severe to me.

I don't agree, especially because policy states the opposite directly
in §6.3.  In any event, it is hard to find an example of either of
these (broken noninteractive preinst or postinst, broken purge) that
is not a sign of major breakage.

Thanks for a useful clarification.
Jonathan


--
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/20101218092554.ga7...@burratino

Getting warned about and contributing to decisions (Re: Why is help so hard to find?)

[Jonathan Nieder]

Hi Chris,

Chris Carr wrote:

> Sorry to de-lurk with a tangential question, but how can I as an
> interested observer subscribe to the conversations where these decisions
> get made

Good question.  Subscribe to the PTS for the affected packages[1] and
test the versions in unstable and experimental.

> and contribute views *before* things get to this stage?

If by "views" you mean "overlooked use cases or bugs", then filing
bug reports is very welcome.  If by "views" you mean "telling
people what to do", the best way is to get involved in maintenance
(submitting patches, etc), so that the person to tell what to do is
yourself.

> I had the same frustrations as Mike and Roger with insserv

FWIW moving to LSB-style dependency-based boot (abbrev. "insserv") is
an interesting example.  It is a big change.  As mentioned in this
thread, there is a detail still to iron out: what exactly should be
done with stray init scripts without the LSB header?[2]

"Why do some developers like it, then?" you might wonder.  It removes
a huge source of maintenance headache --- the global allocation of
boot sequence numbers[3].

If a year and four months ago someone volunteered to take on that
burden (i.e., take responsibility for making sure the number-based
boot order still works, patching affected packages where appropriate)
for squeeze, then insserv could have been made optional.  I am not
aware of anyone stepping up to do that.

> a deeply
> flawed "upgrade" broke several of my systems and the maintainers'
> response was basically "too bad" (GRUB2).

You filed a bug against the grub-pc package and the response was "too
bad" rather than "here's how we can fix it"?  What is the bug number?

> On a completely separate note, where is the correct place to advertise
> for a new sponsor?

See http://wiki.debian.org/DebianMentorsFaq#HowdoIgetasponsorformypackage.3F

Hope that helps,
Jonathan

[1] 
http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system
[2] http://bugs.debian.org/598020
Maybe insserv can query dpkg itself for init scripts from packages in
the conffiles state.  Or maybe the release notes can provide detailed
instructions for getting past this hurdle.
[3] http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot


-- 
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/20110115105752.GB28165@burratino

Re: ObsoleteConffilesOfInstalledPackages

[Jonathan Nieder]

Mike Bird wrote:

> Some people have expressed interested in obsolete config files
> associated with currently installed packages.
[...]

Correct behavior is to remove obsolete _unmodified_ conffiles,
as Roger mentioned.  Which of the conffiles mentioned below were
modified?  No way to know just yet.

I. Known bugs

> 5.0.7 bittorrent 3.4.2-11.1 /etc/init.d/bittorrent
> 5.0.7 bittorrent 3.4.2-11.1 /etc/default/bittorrent
> 6.0 bittorrent 3.4.2-11.3 /etc/init.d/bittorrent
> 6.0 bittorrent 3.4.2-11.3 /etc/default/bittorrent

http://bugs.debian.org/550229

> 5.0.7 bluez-utils 3.36-3 /etc/modprobe.d/bluez
> 5.0.7 bluez-utils 3.36-3 /etc/modutils/bluez

http://bugs.debian.org/523050

II. Known non-bugs

> 5.0.7 base-files 5lenny8 /etc/nsswitch.conf

2006-03-04, base-files (3.1.11):

  * The file /etc/nsswitch.conf is now created by postinst in the first
install (made by debootstrap), and it's no longer a conffile.

> 5.0.7 bash 3.2-4 /etc/bash_completion

2008-02-09, bash (3.1dfsg-9):

  * Remove bash-completion from the source.
  * Remove the conflict with bash-completion, recommend bash-completion.

> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Editres.ad
> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Emacs.ad
> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/General.ad
> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Motif.ad
> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Tk.ad
> 5.0.7 capplets-data 1:2.22.2.1-2 /etc/gnome/config/Xaw.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Editres.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Emacs.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/General.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Motif.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Tk.ad
> 6.0 capplets-data 1:2.30.1-2 /etc/gnome/config/Xaw.ad

2008-12-27, gnome-settings-daemon (2.24.1-1):

  * Install .ad files in /etc/gnome/config to replace the ones from 
capplets-data which are still used.

> 5.0.7 clamav-freshclam 0.96.5+dfsg-1~volatile1 
> /etc/logrotate.d/clamav-freshclam
> 6.0 clamav-freshclam 0.96.5+dfsg-1 /etc/logrotate.d/clamav-freshclam

Still needed.  /var/lib/ucf/hashfile keeps track of it.

> 5.0.7 desktop-file-utils 0.15-1 /etc/gnome/defaults.list

2009-03-19, gnome-session (2.22.3-3):
  * defaults.list: move the defaults from gnome-vfs.
+ Add some subtypes of text/plain to gedit defaults.

> 5.0.7 gconf2 2.22.0-1 /etc/gconf/2/path

Intended to be present (included in new installations, not a ghost
from the past).  Not a conffile any more.

III. Indeterminate (probably bugs but need checking)

> 5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/13-915-resolution-set.sh
> 5.0.7 acpi-support 0.109-11 /etc/acpi/resume.d/49-915-resolution-set.sh

2008-05-12, acpi-support (0.109-1):

   * Remove /etc/acpi/resume.d/49-915-resolution-set.sh. It will be moved to
 the 915resolution package. Closes: #447742, #467347.

> 5.0.7 apache2.2-common 2.2.9-10+lenny9 
> /etc/apache2/mods-available/sick-hack-to-update-modules

2007-07-01, apache2 (2.2.4-1):

  * remove sick-hack-to-update-modules

> 5.0.7 bind9 1:9.6.ESV.R3+dfsg-0+lenny1 /etc/apparmor.d/apparmor-profile

renamed to usr.sbin.named, 2008-03-01, bind9 (1:9.4.2-6):

  * Correct apparmor profile filename.  LP: #200739

> 5.0.7 clamav-daemon 0.96.5+dfsg-1~volatile1 /etc/default/clamav-daemon
> 6.0 clamav-daemon 0.96.5+dfsg-1 /etc/default/clamav-daemon

2008-11-29, clamav (0.94.dfsg.2-1), checked by interdiff:

  * The TemporaryDirectory option has been added long ago, no need for hacks
via clamav-daemon.default anymore (closes: #253080)

> 5.0.7 e2fsprogs 1.41.3-1 /etc/e2fsck.conf

An odd one.  Maybe /etc/lsb-release said Ubuntu once for some reason?

> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/README
> 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/README

2008-05-24, fontconfig (2.5.93-1):

  * Stick config README in /etc/fonts.conf.d (closes: 393999)

> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/autohint.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-bitmaps.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/no-sub-pixel.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/sub-pixel.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/unhinted.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.d/yes-bitmaps.conf

Strange.  fontconfig.preinst should have taken care of this during the
upgrade to >= 2.3.2-2.

> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/20-lohit-gujarati.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/30-amt-aliases.conf
> 5.0.7 fontconfig-config 2.6.0-3 /etc/fonts/conf.avail/40-generic.conf
> 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/20-lohit-gujarati.conf
> 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/30-amt-aliases.conf
> 6.0 fontconfig-config 2.8.0-2.1 /etc/fonts/conf.avail/40-generic.conf

Various upstream changes.  Probably a bug (why are these conffile

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Jonathan Nieder]

(please drop cc's other than debian-policy in replies if you want to
work on that)

Hi Wookey,

Wookey wrote:

> Debian policy (8.2) says:
> ---
> It is recommended that supporting files and run-time support programs
> that do not need to be invoked manually by users, but are nevertheless
> required for the package to function, be placed (if they are binary)
> in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
> If the program or file is architecture independent, the recommendation
> is for it to be placed in a subdirectory of /usr/share instead,
[...]
> For multiarch, or existing
> dpkg-cross cross-compiling, to work, arch-dependent needs to mean
> either form _or_ content (see below for elaboration).

I always had thought that it's content and that the "if they are
binary" is only a red herring.  I agree with you that the policy ought
to be clarified.  Thanks for bringing this up.

Regards,
Jonathan


-- 
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/20110131174653.GA31826@burratino

The "node" command in Debian

[Jonathan Nieder]

(please follow-up to debian-devel only)
Hi Debianites,

As you may know[0], there are currently two packages in Debian
experimental providing a "node" binary.

[0] http://lists.debian.org/debian-devel/2010/08/msg00568.html

The node.js project
---
One is from the node.js project.  It was renamed from "server" to
"node" on March 3, 2009.  The purpose of this tool is to run servers
and other event-based programs written in Javascript.

The maintainer for this package in Debian has written[1]:

| not having /usr/bin/node as nodejs binary path will without any
| doubt render nodejs package unuseful for a vast majority of users.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=611698

The LinuxNode project
-
The other is a frontend to libax25, an AX.25 implementation for Linux.
Hardware implementations of AX.25 are apparently called "terminal node
controllers" or "nodes" for short; hence this Linux-based
implementation was called LinuxNode and its binary called "node".  It
was introduced in January, 1996.  It seems that its family tree also
includes (unpackaged) implementations named AWZNode and FlexNode.

The node package does not seem to have a very active maintainer since
Joop Stakenborg retired.  On the debian-hams list, we read[2]:

| As a continuous very long term (about 1994) user of kernel ax25 I
| object strongly to this request which will affect far more users
| world-wide than just a few nodejs users.

[2] http://lists.debian.org/debian-hams/2010/08/msg00032.html

Debian policy
-
Both of these projects are, of course, insane to use such a generic
binary name.  But Debian policy does not say "you must not use such a
generic name unless you are a net.god" --- only common sense does.

Problem: scripts may use the 'node' name to refer to either of these
programs.  Which should get the name?  You decide, based not on
popularity or priority but --- well, based on whatever makes sense.

If no consensus emerges, policy §10.1 in its Solomon-like wisdom says
_both_ commands must be renamed.  I hope we can do better.  I will be
happy to file release-critical bugs against both packages to that
effect if not.

With hope,
Jonathan

Disclaimer: I am ignorant about both packages.  Some naïve part of
me believes that it will be possible for mature people not ignorant
about them to figure out a reasonable solution.


--
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/20110207104656.GA10756@elie

Detecing missing Build-Conflicts (Re: Upcoming FTPMaster meeting)

[Jonathan Nieder]

Roger Leigh wrote:

> The other side to this is that fixing such bugs gains us very litle.
>
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.
>
> If we have a random build environment + package build deps, we might
> occasionally find something that needs a build-conflict, but we are
> never going to get complete coverage
[...]
> The former situation is simple, robust and maintainable.  But the
> latter, it's a virtually intractable problem, and given the lack of
> concern about it up to now, it's not a major worry for most people,
> and from a cost/benefit POV it doesn't look practical.

I've built packages from source before, found missing build-conflicts,
reported the bugs and seen them fixed.  The whole experience was
pleasant.  I don't think I'm the only one.

This can be taken as a vote for or against automated testing for
such problems; feel free to pick your favorite and run with it. :)


-- 
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/20110212214404.GA12775@elie

Wanted: maintainer for git's emacs support

[Jonathan Nieder]

Hi,

None of the current Debian git maintainers seem to use emacs.  This
means git's emacs support[1] does not get as much care as it deserves:
see for example bugs #611936, #611931, #611932, #611933, #611934,
#577834, and #611935.

The upstream maintainer is very friendly and responsive though he
doesn't seem to have much time for it these days.  Users are friendly
and responsive, too.  So I wonder:

 - would anyone be interested in adopting this code in Debian?
 - if not, should we be shipping it?

Thoughts welcome.  (Actions even more so. :))
Jonathan

[1] /usr/share/doc/git/README.emacs


-- 
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/20110219031838.GC29369@elie

Re: Call for projects for Google Summer of Code 2011

[Jonathan Nieder]

Paul Wise wrote:

> That is unlikely to be useful, upstream has explicitly said they are
> targeting Linux only.

More precisely[1]:

"Will this run on [insert non-Linux OS here]?

 Unlikely. As pointed out, systemd uses many Linux specific
 APIs […] That said, git supports branches and rebasing quite
 well, in case people really want to do a port.

 […]

 If folks want to implement something similar for other
 operating systems, the preferred mode of cooperation is
 probably that we help you identify which interfaces can be
 shared with your system, to make life easier for daemon
 writers to support both systemd and your systemd counterpart.
 Probably, the focus should be to share interfaces, not code."

So upstream does seem to be interested in cooperating with developers
for other platforms, though not in maintaining the resulting code.

For what it's worth.
Jonathan

[1] http://0pointer.de/blog/projects/systemd.html


--
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/20110303020301.GA22891@elie

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

[Jonathan Nieder]

Hi,

Steve Langasek wrote:

> So in this case the pre-dependency
> should *not* be set, as it only serves to complicate the upgrade path.

I think this example might deserve a closer look.  Documentating the
required dpkg version seems useful for backporters and others who
would use the package in unusual situations.

What dpkg does:

  Since depisok() is called with allowunconfigd == true, to dpkg a
  Pre-Depends is just like a Depends, except that at unpack time dpkg
  checks that the depended-on package:

  - has been configured before
  - satisfied the version relation the last time it was configured
  - has not been removed since then.

  These conditions are trivially satisfied when unpacking a package in
  wheezy.  The pre-dependency would have no effect beyond a Depends
  relation (and in particular, would be safe).

What apt, aptitude do:

  I don't know.  Do they allow an already satisfied Pre-Depends to
  complicate the upgrade path?  IIRC dpkg, as an essential package,
  always gets upgraded first anyway, but I am not so familiar with this
  code.

What policy allows package managers to do:

  Policy is aligned with what dpkg currently does.

What future policy allows:

  Bug#593177 brings the possibility of change.  In the extreme case the
  meaning of Pre-Depends could change to "the depended-on package and
  its dependencies must be configured at the currently unpacked
  version", which would make upgrade impossible in the following case.

  - libc6: Pre-Depends: dpkg (>= ancient).
  - dpkg: Pre-Depends: libc6.

  Luckily, bug#593177 can probably be addressed with less dramatic
  changes.

Conclusions:

  I could go either way on this.  On one hand, versioned Pre-Depends
  on essential packages in the previous release's version seem to be
  harmless with current tools.  On the other hand, as Steve mentioned,
  decreasing the number of pre-dependencies in the archive is good for
  everyone's sanity.

Hope that helps,
Jonathan


-- 
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/20110306002627.GA16386@elie

Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?

[Jonathan Nieder]

To recap, there was some discussion about whether a versioned
Pre-Depends on dpkg-maintscript-helper [dpkg (>= 1.15.7.2)] is a good
idea for packages in wheezy, with no definite conclusion.

The main complication was such Pre-Depends are not needed for
squeezy-to-wheezy upgrades.  Still I believe adding one to the git
package in wheezy would be a good thing, so I'll ask again for your
advice.  (Best of all if it comes with an explanation that can be used
to update debian-policy and save the next person from having to ask on
-devel again.)

Reasons mentioned *not* to add such a pre-dependency:

 - a smaller Packages file;
 - fewer entries in hashtables listing all dependencies;
 - fewer iterations in loops over dependencies, etc;
 - we discourage Pre-Depends in general:
   . Pre-Depends can complicate upgrade paths by constraining
 unpack order;
   . Pre-Depends can complicate upgrade paths by constraining
 configuration order;
   . Pre-Depends loops are unbreakable

However, most of those are not very problematic in the case at hand
(dependencies in wheezy on dpkg-maintscript-helper).

 - it is not obvious that kind of micro-optimization of dependency lists
   is worth much in decreasing the size of Packages and pkgcache.bin;
 - because dpkg is essential and the required version is already in
   squeeze, the kind of pre-dependency being considered does not
   complicate the squeeze-to-wheezy upgrade path.

Reasons mentioned to add a pre-dependency:

 - derivatives with different release schedules (e.g., Ubuntu LTS) would
   be able to reuse the package without changing it;
 - people installing git from sid on lenny systems wouldn't find preinst
   mysteriously failing.  Such an operation is not guaranteed to work
   but why not help out when it's this easy?
 - private backports are likely to leave out the pre-depends by mistake
   if we don't add it;

Does that seem like a fair summary?  Alternatively, what advice would
you give to a packager that wants to (reliably) remove a conffile in
wheezy?

Thanks again for your help.
Jonathan


-- 
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/20110318102631.GC1076@elie

Re: Library depending on -data packages

[Jonathan Nieder]

(dropped cc's; hopefully that's okay.)
Hi!

Luca Capello wrote:

> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless.  But given that it
> seems no one agrees with me, is such a behavior documented somewhere?

Checking policy, I see:

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

which I grant is not all that helpful.  The example I was introduced
to Recommends with is ancient: old X server packages used Recommends
to pull in a font server, because it was possible that your font
server might be running remotely but in all but unusual installations
you want a local one.  (Of course nowadays the X server always has a
built-in font server.)

One use of Recommends I agree with is that most latex packages use
Recommends for their documentation (which _has_ to be part of the
default installation according to the license).

So let's just consider your examples. :)

emacs depends on m17n-db

Bug#599643 is about what relationship m17n-lib has to m17n-db.  Please
correct me if I'm wrong.

 . libm17n provides an API for complex text layout
 . m17n-db provides the actual complex layout rules

So, one might conclude, for libm17n to behave as advertised, one *has*
to have m17n-db installed.  The DB is just an implementation detail
and could be provided just as well with internal tables in the library.

Wait, wait!  But emacs depends on libm17n for complex text layout and
some people are just not going to care.  What to do?

 Option A.  Split the functionality of libm17n-0 into two packages:
 (1) libm17n-0-lib, which ensures binaries linked to libm17n-0 can at
 least start up correctly and (2) libm17n-0, a dependency package
 which depends on libm17n-0-lib and m17n-db and represents the actual
 functionality.  Change emacs to "Depends: libm17n-0-lib" and
 "Suggests: libm17n-0".  Make sure the behavior when m17n-db is not
 installed is reasonable enough to function ok and to give a hint
 that the end-user about what package to ask the sysadmin to install
 to get full functionality.

 Option B.  Make emacs Suggests: and dlopen libm17n, and similarly
 make sure the fallback behavior is okay.

Neither involves a Recommends.  In either case some basic "task"
package probably ought to Recommends: m17n-db.

Many desktop apps depend on libatk1.0-data
--
Bug#599666 is about what relationship libatk has to libatk-data.  Again,
please feel free to correct me if I go wrong.

libatk1.0-data contains soname-independent files which the runtime
libraries need.  It consists mostly of locales and is a lot bigger
than the lib itself --- but that does not seem so unusual to me.
Hopefully some day we will find a better way to detail with
localization packaging to avoid wasting so much space.

emacs depends on anthy-common
-
Bug#582797 is about dependencies on libm17n implying a much heavier
dependency (anthy) whose functionality is not widely used that way.

The complication (again, as I understand it) is that to demote the
dependency to a Suggests would require finding a good fallback
behavior when it is missing.  According to that bug log, libm17n
upstream is working on it.

The plan is for the anthy input module to be in another package that
Depends: libanthy0, if I understand correctly.  That input module
could Enhances: libm17n or libm17n could Suggests it.

Hope that helps,
Jonathan


-- 
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/20110321170149.GA7798@elie

Re: Library depending on -data packages

[Jonathan Nieder]

Hi,

Simon McVittie wrote:

> Which way to break the circular dependency needs to be considered 
> case-by-case;
> neither answer is universally right.

Here (with this statement of the problem) I disagree --- using Depends to
mean Enhances is _always_ wrong.

For example:

> The existence of openarena-data is an implementation detail of openarena,
> so it has this relationship:
>
>/--->--- Depends -->---\
> openarena   openarena-data
>\---<-- Recommends --<--/

That Recommends should be an Enhances.  openarena-data continues to provide
OpenArena game data, regardless of whether openarena is installed (unless I
am missing something, ianal, etc etc).

Thanks for a useful example.
Jonathan


-- 
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/20110321170922.GA8076@elie

Re: Library depending on -data packages

[Jonathan Nieder]

Simon McVittie wrote:

> Or are you saying
> that things with special::auto-inst-parts should never have even a weakened
> dependency on the package of which they're an implementation detail?

Yes.  (Well, a Suggests is okay.)

> In situations where the data and the engine have a many-to-many relationship
> (the various Doom engines, each of which can play Doom, Doom II, FreeDoom or
> FreeDM), I agree that that Recommends might be too strong.

That's why I care.[1]

It seems unlikely that another game is going to start using openarena's
data without the engine but still it is nice to leave the possibility
open.

Regards,
Jonathan

[1] The package now called suckless-tools used to Recommends: dwm,
since its raison d'être was to provide basic functionality for that
window manager.  This meant:

 - for dwm users, not much.  APT's "markauto" functionality already
   ensured that dwm-tools would be uninstalled once dwm is removed.

 - for xmonad users, installing dwm-tools for dmenu would pull in an
   extra window manager.

(Side note: suckless-tools is plenty of fun on its own anyway.)


--
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/20110321191822.GA4051@elie

Bug#664257: multiarch tuples are not documented/defined

[Jonathan Nieder]

Hi Matthias,

Steve McIntyre wrote:

> I've updated http://wiki.debian.org/Multiarch/Tuples with lots more
> information such as links to external ABI specs where I could find
> them.

I think the Multiarch/Tuples wiki page is now in a sane state, though
as always it could presumably be improved even more.  I think future
required improvements can be tracked separately.  Do you mind if this
bug is closed?

Thanks much,
Jonathan



-- 
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/20120418031651.GA26748@burratino

Re: Volunteer-initiated team maintenance as a solution for packages with low activity

[Jonathan Nieder]

Michael Gilbert wrote:

>   Plus I don't have to find hosting for my work elsewhere,
> which is kind of a pain and unwanted.

This at least is easy to address.  Alioth automatically notices
per-user git repositories under ~/public_git[1].  Something similar
works for other version control systems[2], too.

Cheers,
Jonathan

[1] http://wiki.debian.org/Alioth/Git#Using_personal_Git_repositories
[2] http://wiki.debian.org/Alioth/Bzr#Using_personal_bzr_repositories
http://wiki.debian.org/Alioth/Hg#Per-user_repos
http://wiki.debian.org/Alioth/Darcs#Using_personal_darcs_repositories


-- 
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/20120418202114.GA30752@burratino

Bug#664257: multiarch tuples are not documented/defined

[Jonathan Nieder]

reassign 664257 debian-policy 3.9.3.1
affects 664257 =
tags 664257 = upstream
quit

Goswin von Brederlow wrote:

> It is a bug in Debian: The multiarch tuples are not documented/defined
> in Debian.

Fine, reassigning to policy.

Never say I didn't do anything for you... :)

Policy maintainers, see http://wiki.debian.org/Multiarch/Tuples for a
nice table to incorporate.  Ultimately we would like to see this,
along with some more text to make it precise, in some LSB document
such as the FHS.

Thanks for your work, and hope that helps,
Jonathan



-- 
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/20120426232526.GA3102@burratino

Re: RFC: OpenRC as Init System for Debian

[Jonathan Nieder]

Marco d'Itri wrote:

> We can all be "uneasy" about it until we are blue in the face, but since 
> Red Hat maintains most Linux core components and we do not, there is not 
> much we can do about it.

I'll repeat what I said last time you made this (in my opinion
strange) argument:

Red Hat employs some eminently friendly and reasonable people.
Claiming that we are at their mercy is ignoring the ability to reason
with them.  (When that stops being true, we can talk about whether it
is time to work with other distros on a fork, but given that we're not
there yet, I wonder why you keep on raising the point.)


-- 
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/20120429193024.GA28023@burratino

Re: Definition of _boot_

[Jonathan Nieder]

Svante Signell wrote:

> In line with the recent discussion, lets aim at defining what _boot_ is:

Why?  Unless you are suggesting documentation is unclear, I don't see
how this has any impact on the development of Debian.


-- 
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/20120429204859.GA31883@burratino

Re: RFC: OpenRC as Init System for Debian

[Jonathan Nieder]

Marco d'Itri wrote:

> This has been happening more and more after SuSE has become irrelevant.
>
> I will cite just a few simple examples:
> - no good strategy to prevent lockstep udev/kernel upgrades, since RHEL 
>   does not support upgrading to the next major release
> - configuration files in /etc/ overriding configuration files in /lib/, 
>   to work around the inferior configuration files handling of RPM
> - removal from udev/systemd of features which Red Hat will not provide 
>   anymore (e.g. support of persistent names for new network interfaces,
>   choose your own example for systemd)

Thanks for explaining.  Very interesting examples.

Possible conclusions:
- we need to be involved upstream in core projects if we do not want to
  be neglected
- improving OpenSuSE and other distros is another way to help upstreams
  remember how to support more than one setup
- helping RPM and other Red Hat infrastructure is valuable, so they can
  experience the features that it would be nice to preserve in Debian
- sometimes package maintenance involves hard dilemmas


-- 
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/20120430064417.GA10890@burratino

Re: Node.js and it's future in debian

[Jonathan Nieder]

Carsten Hey wrote:

> I don't think that there ever will be a consensus in all those
> discussions without discussing in a reasonable way (which failed in the
> past multiple times).

Note that a consensus does not imply everyone agreeing.  I am starting
to see a consensus already and would welcome well reasoned opinions
and clarifications that show where my understanding is lacking.

By the way, separate from what happens to the "node" command are a few
other questions:

 - Can we come up with alternate names for both commands, so while
   Debian users might be using the "node" command, Debian packages do
   not need to?

   (Among other benefits, this would simplify upgrades for people who
   have /usr/sbin too early in $PATH.)

   I think on the Node.js side this is basically a solved problem,
   though help with the actual coding would be welcome.  (E.g., I have
   a patch against upstream 0.7.y that does the right thing, but 0.7.y
   is not packaged for experimental yet.  Feel free to contact me or
   nod...@packages.debian.org if you have time to help.)

   There is a patch taking the first step in this direction for the
   LinuxNode package at  but no
   maintainer has weighed in since then, except to note on
   debian-devel@ that they are having trouble finding someone to test
   the patch.

 - Is the "node" package undermaintained?  Should it be orphaned to
   encourage active users to take on the burden of its maintenance
   without worrying about stepping on people's toes?

Thanks,
Jonathan


-- 
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/20120501175747.GA31508@burratino

Re: Node.js and it's future in debian

[Jonathan Nieder]

Carsten Hey wrote:

> I was talking about a consensus among the maintainers of the affected
> packages.  Even if all but the maintainers of one of the affected
> packages would agree to a solution, there would be no way to implement
> this solution without asking the tech-ctte or (what would be not
> appropriate for this) a GR.

Wait, really?  What happened to respect by maintainers for the
project?  What happened to NMUs when a maintainer is stalling work?

[...]
> node.js might not be that widespread in use as python, but shipping
> a node.js with /usr/bin/nodejs seems to be broken in a similar way as
> the above example.

I would agree with you if we were proposing going forward against
upstream's wishes.  But I was not proposing that --- we don't know
upstream's wishes yet, but I was going to send a patch once we know
it works.  Sorry for the lack of clarity.

This kind of thing has precedent.  For example, there is gmake and
there are commands like axlisten.

Hoping that clarifies a little,
Jonathan


-- 
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/20120501203050.GA32510@burratino

Re: Node.js and it's future in debian

[Jonathan Nieder]

Steve Langasek wrote:
> On Tue, May 01, 2012 at 03:30:50PM -0500, Jonathan Nieder wrote:

>> Wait, really?  What happened to respect by maintainers for the
>> project?
>
> "The project" is not "a set of random maintainers who have a filename
> conflict with you".

Sorry, I don't understand the above sentence.  Do you mean that it is
impossible to come to a consensus when one maintainer of a relevant
package disagrees?  I can understand that claim, but it doesn't seem
to be the same as the sentence above.

>  We have a constitution to *prevent* such decisions
> being made by a tyranny of the majority of the minority.

Thanks, that perhaps suggests a method for resolving this.  Could you
point to the section of the constitution you are referring to?

> NMUs are *not* a tool for forcing a maintainer to accept a technical outcome
> he disagrees with.

Sure.  To be clear, I should say that I am not advocating that anyone
NMU the node or nodejs package.  What I meant (and I could easily be
wrong) is that when the maintainer of a package is not working on an
important bug and has not given any reason, Debian does not need to be
held hostage by that.

Jonathan


-- 
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/20120501213249.GB1044@burratino

Re: Node.js and it's future in debian

[Jonathan Nieder]

Hi again,

Steve Langasek wrote:

> [Dropped Cc; what does any of this have to do with the DPL?]

I was alerting him to a conversation that was going nowhere fast,
in the hope that he might use his power to

participate in discussions amongst the Developers in a helpful
way

It has also been my experience in the past that he is way better than
I am at figuring out a productive way forward when an endeavor is
stuck.

[...]
> I mean that it is not reasonable to expect a maintainer to recognize a
> "consensus" among other people who are not the maintainer, where his or her
> package is concerned, except when that's a consensus of a
> constitutionally-empowered body such as the TC.

That implies two bugs in debian-policy. :)  You are probably right.

[...]
>   The Technical Committee may:
>
>   [...]
>
>   2. Decide any technical matter where Developers' jurisdictions overlap.

If I understand correctly, the general conclusion in this thread has
been that that is the right way to decide this.

I don't see anything fundamentally opposed to one another about the
goals of Pat, Jonas, and Jérémy, who seem to be the developers who
would be involved.  The implied impossibility of a reasonable
conversation between them without some authority figure arbitrating is
a bit disappointing.  Oh well.

[...]
> Ok - sorry, that's not what came across in your message, it's possible I
> overlooked some context up-thread that would have made this clear.  Yes, a
> bug that's been filed against the package and gone unanswered by the
> maintainer is fair game for NMUing.  OTOH, a bug that the maintainer
> disagrees is a bug would not be fair game.

Thanks again for the clarifications and sorry for the lack of clarity.
(Also sorry for the somewhat inflamatory way I've proceeded in this
discussion --- stating my biases up front and tying this in with my
concerns about lack of an active maintainer to vet changes to the node
package was probably not the best approach.  Someone with a more
delicate touch could probably have gotten more done.)

Sincerely,
Jonathan


--
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/20120502063443.GA2691@burratino

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Jonathan Nieder]

Hi,

(Caveat: I am not a dpkg-source maintainer.)

Sune Vuorela wrote:
> On 2012-05-15, Norbert Preining  wrote:

>> Is there a rational behind not allowing any fuzz?
>
> I think it makes perfect sense to expect the patches to apply perfectly,
> so we don't rely on patch & quilt to be able to unfuzz things.

Indeed, unfuzzing involves guessing where the patch is supposed to
apply, and different versions of GNU patch (which is what quilt uses)
may make different guesses as patch gets smarter.  The same source
package producing a different unpacked result depending on the tools
in the surrounding environment does not sound like fun to me.

I can imagine dpkg-source or wrappers like git-buildpackage learning
to automatically refresh patches when generating the source package if
requested to do so, so it would only have to make the guess once.
Perhaps someone would like to work on that?

Thanks,
Jonathan


-- 
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/20120515061800.GA11441@burratino

Re: Wheezy release: CDs are not big enough any more...

[Jonathan Nieder]

Bjørn Mork wrote:
> Timo Juhani Lindfors  writes:

>> You also need to have root access to some machine to create the USB
>> media.
>
> No, you don't.  On a default Debian system you need to be a member of
> the "floppy" group. From  /lib/udev/rules.d/91-permissions.rules :
>
>  # default permissions for block devices
>  SUBSYSTEM=="block", GROUP="disk"
>  SUBSYSTEM=="block", ATTRS{removable}=="1",  GROUP="floppy"

Yep.

>> This means you can't create the installation media at most
>> university or library machines unlike with CDs.
>
> You mean that they allow you to burn a CD but not write to a USB stick?
> Sounds like they have a support problem which I don't think Debian can
> solve for them.

On large installations (think "computing cluster"), adding untrusted
users to the floppy group is not a great idea, since then they would
have remote access to removable media other users insert.  For CDs
and DVDs, consolekit addresses the problem out of the box and roughly
speaking lets each user access media that they have inserted.  Last
time I checked[1] (a while ago), the same rules did not apply to USB
sticks.

Hope that helps,
Jonathan

[1] http://bugs.debian.org/585463


--
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/20120516153715.GA17460@burratino

Re: Handling of changelogs and bin-nmus

[Jonathan Nieder]

Raphael Hertzog wrote:

> As such, I suggest that we handle "binary rebuild" differently:
> - debian/changelog is left unmodified since it's the source changelog
>   => it defines the ${source:Version} substvar
> - debian/changelog.binary-rebuild (or any other better name) is created
>   when we want to do a bin-nmu
>   => it defines the ${binary:Version} and it's not included in
>   the generated source package

Sounds good to me.  Where would the binary changelog entry and binary
version be stored in the resulting binary package?


-- 
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/20120610171456.GB32613@burratino

Re: Handling of changelogs and bin-nmus

[Jonathan Nieder]

Andreas Barth wrote:

> Do we have other tools than dpkg that parse the changelog to find out
> the package version?

Yes, debian/rules parses the changelog in a low-tech way in some
source packages.  Someone with access to the lintian lab might be able
to say how many packages would be hurt by not being able to read the
binary package version from there (hopefully not many --- most
packages use dpkg-parsechangelog instead).

Jonathan


-- 
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/20120610235358.GA3390@burratino

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Jonathan Nieder]

retitle 678519 after about a month, routing gets wedged
# not a general problem affecting a large portion of the archive
reassign 678519 base
tags 678519 + squeeze
quit

Hi Henrique,

Henrique de Moraes Holschuh wrote:
> On Fri, 22 Jun 2012, Rudy Zijlstra wrote:

>> let system run with IPv4 & IPv6 routing for about 1 month
>>> IPv6 routing will start to fail
>>> IPv4 routing becomes slow and unpredictable
>>
>> no obvious causes visible in the system. top and friends do not show a cpu 
>> hog
>>
>> a reboot will bring the system back to normal behaviour. 
>
> Please use (as root) "ip neigh show", and "ip route list cache" to try to
> track down any weird differences between the box when it is behaving
> normally, and the box when wedged.  You may want to compare it to a healthy
> box on the same network segment.

Thanks for starting to track this down.  Any idea which package might
be responsible?

Rudy, is this a regression, or has this system always behaved this
way?  How many times has it happened?  How reliable is the 1 month
gestation time?  When did it start?

Thanks,
Jonathan



-- 
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/20120625022342.GA3712@burratino

Use of the "general" and "base" packages (Re: general: after about 1 month...)

[Jonathan Nieder]

Hi Holger,

Holger Levsen wrote:
> On Sonntag, 24. Juni 2012, Jonathan Nieder wrote:

>> retitle 678519 after about a month, routing gets wedged
>> # not a general problem affecting a large portion of the archive
>> reassign 678519 base
>
> reassigning bugs from general to base is pretty useless, as both pseudo-
> packages bugs are "maintained" by the same persons... 
>
> Basically the base-pseudo package is pretty useless as well, all it's 
> (current) bugs should probabyl be carefully assigned to the kernel, for 
> #678519 I just wasnt sure yet if its really a kernel or user configuration 
> problem...
>
> The general pseudo-package has some approriate bugs OTOH.
>
> But mostly bugs filed against those two pseudo-packages really need to be 
> assigned to a real package.

I figured the discussion of which package is resposible was more on
topic for virtual-pkg-base-maintainers@ than debian-devel@.  Though I
could easily be wrong.

In any event, I reassigned the bug to the kernel a few minutes later.

Hoping that clarifies,
Jonathan


-- 
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/20120625200508.GA10213@burratino

Bug#679173: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X

[Jonathan Nieder]

tags 679173 + wheezy moreinfo
quit

Hi Jean Pierre,

HOAREAU jean pierre wrote:

>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?

Could you answer the above questions?  (No need to separate the
answers --- a simple explanation that answers all those questions
would be good enough.)  In other words, if I had the same hardware
you have, what should I do to experience the problem for myself?

Curious,
Jonathan



-- 
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/20120626214910.GA30167@burratino

Bug#679173: [Jean Pierre Hoareau: Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X]

[Jonathan Nieder]

submitter 679173 Jean Pierre Hoareau 
quit

Forwarding with permission.
--- Begin Message ---

Dear Jonathan,

Thanks for your quick answer, and sory for ma late answer due to a 
failure on my mailbox "jphoar...@free.fr". Use my primary mailbox  
"*hoarea...@free.fr*" for all new communication about this bluetooth 
failure.


  You wil find her under some detail about what hapen when I try to 
send a file to my  "HTC ONE X" smartphone . I think you are able to 
reproduce this fail if you use the same hardware.


*Hardware Sumary *:

root@soleil:~# lsusb
Usb Bluetooth Dongle : Bus 006 Device 002: ID 0a5c:2121 Broadcom 
Corp. BCM2210 Bluetooth


root@soleil:~# dmesg
[   14.784063] Bluetooth: RFCOMM TTY layer initialized
[   14.784069] Bluetooth: RFCOMM socket layer initialized
[   14.784070] Bluetooth: RFCOMM ver 1.11
[   14.798390] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   14.798392] Bluetooth: BNEP filters: protocol multicast
[ 2488.100300] usb 2-6.1: reset high-speed USB device number 5 
using ehci_hcd
[ 2498.084251] usb 2-6.1: reset high-speed USB device number 5 
using ehci_hcd


SMARTHONE
 HTC-ONE-X, Androide 4.0.3, ICE.
Bluetooth software 4.0.
API HTC SDK: 4.12


*WHAT I DO :*

1- Start my computer under DEBIAN WHEEZE kernel 3.2.0-2-686-pae
2- Plug ma bluetooth dongle USB
3- Launch "blueman-manager" in console to get messages;
4- Search "new adapter or device" from the screen. (HTC-ONE-X Found)
5- Pair the Computer and the Smartphone. (Pairing OK)
6- Send a file size *17ko* from the PC to Smartphone (result OK)
7- Send a file size *48 ko* .  
 (Result Fail "Request Time Out") no File send.

8- Retry (6) OK
9- Retry (7) OK ..Why ?
10- Send a file size *220 ko*  Result Fail "Request Time Out" no 
File send


After this step any thing you do fail due to a Request Time Out.

*MESSAGES SUMARY *:

*root@soleil:~# blueman-manager *

** (process:3103): WARNING **: Trying to register gtype 
'GMountMountFlags' as enum when in fact it is of type 'GFlags'


** (process:3103): WARNING **: Trying to register gtype 
'GDriveStartFlags' as enum when in fact it is of type 'GFlags'


** (process:3103): WARNING **: Trying to register gtype 
'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'

Loading configuration plugins
Using gconf config backend
_
Load (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:68)
['Services', 'PulseAudioProfile']
_
Load (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:68)
Unable to load plugin module PulseAudioProfile
PulseAudio applet plugin not loaded, nothing to do here
_
__load_plugin 
(/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:142)

loading 
blueman-manager version 1.22 starting
_
on_bluez_name_owner_changed (/usr/bin/blueman-manager:110)
org.bluez owner changed to  :1.5
Using gconf config backend
_
SetAdapter (/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:301)
None
_
on_adapter_changed 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerToolbar.py:89)

toolbar adapter /org/bluez/1528/hci0



*PAIRING PC to SMARTPHONE*

_
on_device_created 
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:282)

created /org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E
_
__init__ (/usr/lib/python2.7/dist-packages/blueman/main/Device.py:35)
caching initial properties
_
do_cache (/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:556)
Caching new device 40:98:4E:55:DA:1E
_
row_update_event 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)

row update event Fake False
_
row_update_event 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)

row update event Trusted 0
_
row_update_event 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)

row update event Paired 0
_
init_services (/usr/lib/python2.7/dist-packages/blueman/main/Device.py:91)
Loading services
_
Generate 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceMenu.py:230)

HTC_ONE_X
_
row_update_event 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)

row update event Fake False
_
on_property_changed 
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:180)
adapter propery changed Devices 
dbus.Array([dbus.ObjectPath('/org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E')], 
signature=dbus.Signature('o'), variant_level=1)

_
on_device_property_changed 
(/usr/lib/python2.7/dist-packages/blueman/gui/DeviceList.py:191)
list: device_prop_ch Connected 1 
/org/bluez/1528/hci0/dev_40_98_4E_55_DA_1E () {}

_
row_update_event 
(/usr/lib/python2.7/dist-packages/blueman/gui/manager/ManagerDeviceList.py:278)

row update event Connected 1
_
Generate 
(/us

Bug#679173: blueman-manager: File Send and all later operations time out (Re: No transfert file from or to the smartphones and my PC: SONY xperia x10 and HTC One X)

[Jonathan Nieder]

reassign 679173 blueman
quit

Hi Jean Pierre and blueman maintainers,

Jean Pierre Hoareau wrote

>   You wil find her under some detail about what hapen when I try to
> send a file to my  "HTC ONE X" smartphone . I think you are able to
> reproduce this fail if you use the same hardware.

Thanks much for this.

[...]
> root@soleil:~# lsusb
> Usb Bluetooth Dongle : Bus 006 Device 002: ID 0a5c:2121 Broadcom Corp. 
> BCM2210 Bluetooth
[...]
> SMARTHONE
>  HTC-ONE-X, Androide 4.0.3, ICE.
> Bluetooth software 4.0.
> API HTC SDK: 4.12
>
> *WHAT I DO :*
>
> 1- Start my computer under DEBIAN WHEEZE kernel 3.2.0-2-686-pae
> 2- Plug ma bluetooth dongle USB
> 3- Launch "blueman-manager" in console to get messages;
> 4- Search "new adapter or device" from the screen. (HTC-ONE-X Found)
> 5- Pair the Computer and the Smartphone. (Pairing OK)
> 6- Send a file size *17ko* from the PC to Smartphone (result OK)
> 7- Send a file size *48 ko* .
>  (Result Fail "Request Time Out") no File send.
> 8- Retry (6) OK
> 9- Retry (7) OK ..Why ?
> 10- Send a file size *220 ko*  Result Fail "Request Time Out" no
> File send
>
> After this step any thing you do fail due to a Request Time Out.
>
> *MESSAGES SUMARY *:
[logs snipped, available from [1]]

Jean Pierre: please attach output from the "reportbug --template blueman"
command.  You can use your mailer's reply-to-all feature to ensure that
the output is included in the bug log and the blueman maintainers
receive it.

Blueman maintainers: Known problem?  Any ideas for tracking it down?

Thanks again and hope that helps,
Jonathan

[1] http://bugs.debian.org/679173



-- 
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/20120701232251.GG3728@burratino

Re: Recommends for metapackages

[Jonathan Nieder]

Hi,

Jonas Smedegaard wrote:

> No, I do not find it right for Debian to mandate meta-packages to only 
> recommend when some users need only a subset of the offerings of said 
> meta-package: There will _always_ be some users needing only a subset of 
> things, rendering all dependencies "wrong" by that logic!

Now hold on a second.

I don't think Eugene would advocate any such sweeping principle as the
one described above.  One thing he did say is that he is against is a
magic "metapackages" section transforming Depends into something
weaker.  I imagine you'd agree with him about that.

So where is the point of disagreement here?

There is a danger in overgeneralizing too early.  As far as I can
tell, the actual problem at hand is:

 - The gnome-core metapackage is very useful to some people.  It helps
   people install a standard GNOME installation, keep it installed,
   and remove it later if they wish, using a single package.

 - Some of the same people do not want to have network-manager
   installed.  They also do not want to have network-manager
   fake-installed using equivs because they want to notice if they try
   to install something that actually requires network-manager.

Given the above problem description, using a Recommends in the
metapackage would seem like a pretty reasonable solution.

Unfortunately there is another complication that throws a spanner in
the works:

 - Some higher-level package managers do not honor Recommends
   correctly (I do not know the details of this and would love to see
   a link to the relevant bug), and therefore the Debian GNOME
   maintainers are very wary of using Recommends in their metapackages

See?  Two reasonable perspectives.  Nothing left to argue about.

I'd encourage anyone wanting to move forward to take all three items
listed above into account.

Hope that helps,
Jonathan


-- 
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/20120710214627.GA20337@burratino

Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Jonathan Nieder]

affects 637232 + release-notes
quit

Hi,

Matthias Klose wrote:
> On 08/09/2011 07:31 PM, Aurelien Jarno wrote:

>> I got fed up by people reporting bug on libc6, while this problem results
>> from a decision Debian to implement multiarch. People should work on
>> implementing a compatibility wrapper and to make upstream toolchain
>> multiarch aware. Until this is done, this bug should be kept opened.
>
> just do it.

To be realistic, is anyone actually going to do this?

Avenues forward:

 a) Help upstream authors of toolchain components with hardcoded
header and library search paths to implement multiarch.

gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!)
clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541
icc (Intel C++): status?
pathcc (PathScale ekopath): status?
tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22
pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309
cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037

 b) There is a workaround described in libc6/NEWS.Debian.gz which
works fine:

LIBRARY_PATH=/usr/lib/
CPATH=/usr/include/
export CPATH LIBRARY_PATH

It's probably worth advertising that more widely, for example in
the release notes.

 c) Compatibility wrapper.  If someone needs this, feel free to email
me and I'll help out however I can.


-- 
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/20120722175210.GA24772@burratino

Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Jonathan Nieder]

Hi,

Goswin von Brederlow wrote:
> On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:

>>  a) Help upstream authors of toolchain components with hardcoded
>> header and library search paths to implement multiarch.
[...]
> What I don't understand is why compilers (which probably means ld from
> binutils in all cases) won't use ld.so.conf to find the libs. It only
> does so to find libs linked into libs you link against. So it is used
> execpt for the verry first level of recursion.

The ld library path and compiler library path represent different
things[*].

[..]
>Maybe this could be fixed
> better in a single common point.

Something like "getconf CPATH" and "getconf LIBRARY_PATH" producing
approprite lists for passing to -I and -L to find the system libs and
headers without having to parse "gcc -print-search-dirs" output could
be interesting.  Is that what you mean?

[...]
> I find it a bit hard to believe CPATH is needed. That directory has
> been in use for years and years way before multiarch.

>From the bug log:

| Bug#637218 is a similar problem about headers moving.

Have you tried it and run into different results?

>>  c) Compatibility wrapper.  If someone needs this, feel free to email
>> me and I'll help out however I can.
>
> If you write one of those then please make sure it works with gcc, gcc
> -m32, gcc -m64 and uclibc
[...]

Let's not get ahead of ourselves.  I'm not aware of a wrapper having
been written, and I certainly wouldn't want to impose additional
requirements on someone trying unless someone interested is providing
the patches to support those.

Hope that helps,
Jonathan

[*]
- One is looking for libfoo.so.5, the other for libfoo.so and
  libfoo.a.
- One points to libs on the arch with running binaries, while the
  other has libs for the cross-compilation target.
- One contains /lib, the other doesn't.
- One should not contain compiler-specific directories like
  /usr/lib/gcc/i486-linux-gnu/4.6, while the other does.
- One can be manipulated for special-case tricks with LD_LIBRARY_PATH,
  the other with LIBRARY_PATH.

Declaring that the compiler library path always include the ld library
path would not take care of cross-compilation anyway, so my first
reaction is to suspect it wouldn't be worth the side-effects.


-- 
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/20120723114458.GC14294@burratino

Priority field of xz-utils package

[Jonathan Nieder]

(please direct replies to debian-devel only)

Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz
command is no longer needed in a minimal Debian system.  Based on its
list of reverse-dependencies, it would presumably even be safe to
lower its priority to optional.

I think "standard" or "optional" is the correct priority.  To be
conservative I'd also be open to making the priority "important".

Dear Debianites, what do you prefer?  I'm cc-ing the release team
because either change this late in the release cycle would require a
freeze exception (and I'd be interested in their advice) and the
installer team because of the effect on the installer size and the
installed package set.

Looking forward to your thoughts,
Jonathan


-- 
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/20120818022337.GA1305@mannheim-rule.local

Microcode and the installer (Re: Towards d-i wheezy beta 3)

[Jonathan Nieder]

(replying to -devel and -boot only)
Henrique de Moraes Holschuh wrote:
> On Mon, 10 Sep 2012, Philipp Kern wrote:

>> If we do that the same should also happen for firmware-linux-nonfree. Loading
>> the radeon KMS module without firmware available results in an unusable
>> (text) console. (Yes, it might be considered a bug that radeon is loadable
>> without.)
>
> Sounds good to me.
>
> What should I clone and hack to try to implement this?

, I think.

> Is there any
> preference over install-by-default or ask-if-the-user-wants-it ?

Very good question.  Neither sounds great to me --- let me explain
why.

If d-i asks if the user wants microcode, the user will presumably get
a question along the following lines (yes, I am exaggerating):

Install binary gobbledegook from $hardware_vendor?

There is some software that can run on your hardware
and can be regularly be updated through the package
management system, but we don't really know what it
does in detail.  If you don't install this, your
computer will probably explode.  Install it?

[ Yes ] [ No ]

The answer is always "yes", right?  The user is going to wonder why we
wasting their time to ask them.

On the other hand, if we make the decision for the user (taking the
choice to fetch from non-free sources as permission), then it is hard
to claim that Debian is totally free and that non-free is only a
collection of packages that are not from the OS that have been
packaged to work well with Debian.  This would be a fundamental change
to what it means to enable non-free.

The benefit of not requiring or installing any non-free software by
default cannot be preserved by throwing up any number of nagging
prompts.  If the operating system includes only free software by
default (even when non-free is enabled in sources.list), the user gets
a few moments of seeing what free software can provide before making
an informed decision about what is right for their needs.

If I ran the world, then:

 - if the user has gone to the trouble of providing firmware or
   microcode on a USB stick or similar, then the installer would
   just use it.

 - likewise, a separate menu item that the user can choose in
   order to install firmware or microcode sounds useful

 - however, by default the installer would provide an OS with
   full functionality without having to install non-free
   software

 - documentation such as the release notes would emphasize important
   non-free packages, especially when they provide functionality for
   which there is no free alternative

 - on those radeons where the firmware is necessary for the
   radeondrmfb driver, the installer would fall back to vesafb, with
   clear instructions for switching back to radeon after installing
   the firmware

Of course I don't run the world. :)  Have fun.

Hope that helps,
Jonathan


-- 
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/20120910224128.GA1226@mannheim-rule.local

Re: mass bug filing about packages manipulating/deleting shipped files

[Jonathan Nieder]

Nicholas Bamber wrote:

> Moreover as I understand it the version of piuparts that runs these
> tests is not yet in sid. Surely it is unreasonable to expect people to
> fix these bugs - in the middle of a freeze no less - without this tool.

Doesn't debsums catch it?


-- 
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/20120926195703.GA5300@elie.Belkin

Re: Temporary solution for changelog problem in binNMUs

[Jonathan Nieder]

Hi,

Ian Jackson wrote:

> The real problem is that these changelog files are primarily intended
> for human beings.  They should live in /usr/share/doc, and their
> location should be transparent.

I was convinced of this until I remembered that package descriptions
are very similar in this respect.  My gut feeling to expect to find
changelogs in /usr/share/doc/ is actually mostly due to
habit, I suspect.

That doesn't mean it makes sense to ignore that habit, though.  If we
go down this path that dpkg might need to install a symlink under
/usr/share/doc to help people get used to the file's new location.
"dpkg-query --status" should give a hint about how to show the
changelog, too.

> The right answer is the IMO the splitting as proposed by Ansgar.

One problem that that doesn't solve is what to do when a package would
be able to borrow its /doc/ directory from another package
(using a symlink) but for the changelog and copyright (which gets even
harder when binnmus are involved).  See http://bugs.debian.org/556015

Thanks,
Jonathan


-- 
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/20130513201451.gd3...@google.com

Re: Temporary solution for changelog problem in binNMUs

[Jonathan Nieder]

Ian Jackson wrote:
> Jonathan Nieder writes ("Re: Temporary solution for changelog problem in 
> binNMUs"):

>> One problem that that doesn't solve is what to do when a package would
>> be able to borrow its /doc/ directory from another package
>> (using a symlink) but for the changelog and copyright (which gets even
>> harder when binnmus are involved).  See http://bugs.debian.org/556015
>
> Well, without having thought about this properly, I'm tempted to
> suggest linkfarming.

That sounds like a fine approach to me.  So would we be okay with
prohibiting doc/ being a symlink in jessie?


-- 
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/20130513235605.gk3...@google.com

Bug#718394: ITP: buck -- Facebook's build system for large Java projects

[Jonathan Nieder]

Package: wnpp
Severity: wishlist
Owner: jrnie...@gmail.com

* Package name: buck
  Version : 0.20130612-1
  Upstream Author : buck-bu...@googlegroups.com (Facebook)
* URL : http://facebook.github.io/buck/
* License : Apache-2.0
  Programming Lang: Java
  Description : Build system for large Java projects

I plan to upload buck from
https://git.wikimedia.org/summary/operations%2Fdebs%2Fbuck
to experimental, assuming the maintainer is ok with it.
Development of the packaging would be coordinated as before on
gerrit.wikimedia.org.

Thoughts welcome, as always.

Regards,
Jonathan


-- 
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/20130731034629.GC11068@elie.Belkin

Re: Built-Using description too aggressive

[Jonathan Nieder]

Hi,

Charles Plessy wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5563,7 +5563,13 @@ Replaces: mail-transport-agent
>   
>  
>   
> -   A Built-Using field must list the corresponding source
> +   When the licensing terms of the incorporated parts require to provide
> +   their source 
> +   ,
> +   a Built-Using field must list the corresponding source
> package for any such binary package incorporated during the build

The above looks sensible.  As a small nit, it's not just the licensing
terms of the incorporated parts --- for example, if the incorporated
part were public domain but the code incorporating it had terms
requiring all corresponding source to be included with binaries,
it would probably still be wise to use Built-Using.

How about something like "When the license terms of a binary package
require providing the corresponding source incorporated from other
packages, [...]"?

> + As of September 2013, the current practice in Debian is to consider
> + that we can benefit from the GPL exceptions for the libc, GCC and
> + similar packages.

I can't agree with the above paragraph, mostly because I don't
understand it completely.  What GPL exception?

I am convinced it is legally fine to distribute a binary package of
Git because there is not a substantial amount of GPLv2-incompatible
code in the binary.  GCC's runtime exception doesn't help with that
at all, unfortunately (a GPLv2-incompatible license + GCC runtime
exception is still GPLv2-incompatible), but fortunately there is not
much GCC runtime code in the binary.

Of course that is only my own understanding, I am not an ftpmaster,
I am not a lawyer, etc etc.

Besides, this "As of September 2013" statement in policy feels quite
strange.

Would it be okay to leave out the footnote, or to say something more
practical like the following?


  
For example, a cross-compiler package which Build-Depends on
gcc-5.2-source and whose source package consists of build rules
instead of compiler code should use "Built-Using: gcc-5.2
(= )" to ensure the archive includes the corresponding
source for the produced binary.
  

  
Most packages do not need to use Built-Using, since the archive
maintenance tools already normally ensure that source for at least
one version of their build-time dependencies is present.
  


Hope that helps,
Jonathan


-- 
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/20130923035638.GA2487@elie.Belkin

Re: On Sid and Experimental

[Jonathan Nieder]

Hiya,

Manjul Apratim wrote:

> I cannot help but view too many apt pins
> as an intentional recipe for disaster!

If you really want to experience life on the edge, you can try this:

echo 'APT::Default-Release "experimental";' \
>/etc/apt/apt.conf.d/preferexperimental.conf

Used in combination with apt-listbugs, the result generally pretty
pleasant and stable.

To piggy-back on what Martin said: the current suites all have release
management roles.  See the suite update policy at
 for an overview.

 stable:

  the released OS distribution, which has received a lot of QA
  work.  Does not change except at point releases (every few
  months) and major release (every couple of years or so).

 stable-proposed-updates:

  where the next minor update of stable cooks.  People prepare
  packages for here directly, and although the individual fixes
  that get used are tested in unstable first, the reliability of
  the final packages is mostly due to code review.

 testing:

  where the next major update of stable cooks.  No package
  should be missing dependencies, except occasionally when needed
  to get through a transition.  Packages come from unstable (with
  a few exceptions) and get tested there first.  The purpose of
  the testing suite is to make sure packages work well together
  and can function as a coherent distribution.

 unstable:

  where packages for testing get built and initially tested.  No
  package enters here unless the package maintainer is confident that
  it or some later version will be suitable for the next stable
  release.  Build-time dependencies of packages in unstable are taken
  from unstable, so maintainers exercise care before updating
  ABI-incompatible new versions of libraries here --- and (at least in
  simple cases) when library ABI changes happen, related packages get
  rebuilt and accumulate here before they can move all at once to
  testing.  Nevertheless, unstable can be a site of rapid change.  It
  is normal for packages in unstable to be missing dependencies that
  have not been built or uploaded yet.

 experimental:

  where packages are uploaded when either (a) they should not be
  uploaded to unstable to avoid disrupting an ongoing interface
  transition or (b) they are not ready for upload to unstable for some
  other reason (maybe they need more testing before reaching a large
  audience).

Much of GNOME 3 falls in category (a) --- these packages are moving
from experimental to unstable in small, coherent batches so they can
migrate to testing more efficiently.

If I understand its goals correctly, CUT would also play a release
management role.  In addition to making it easier for people to test
that packages in testing work well together, it could provide the
raw material for making pre-releases of the next version of the
installation media.

Hope that clarifies a little.
Jonathan


-- 
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/20111002103726.GA14294@elie

Re: ITP: susv4 -- Fetch and install SUSv4 (POSIX.1:2008) documentation

[Jonathan Nieder]

Hiya,

David Weinehall wrote:

>   Description : Fetch and install SUSv4 (POSIX.1:2008) documentation
>
> The Single Unix Specifications are not permitted to be generally
> redistributed, so this is an installer that fetches them and installs
> them in a Debian appropriate way.

See  and the manpages-posix
package.  Maybe someone interested (you?) could pick up where Andries
left off.


-- 
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/20111004223107.GA31864@elie

Re: regression: "sh -c" change causes FTBFS

[Jonathan Nieder]

Stéphane Glondu wrote:
> On 10/06/2011 04:07 PM, Jonathan Nieder wrote:

>> ksh93 -c "/bin/sleep 100 >dev/null" does skip a fork().  I suspect
>> bash does not skip a fork in this case for the same reason that
>>
>>  bash -c 'echo hi; /bin/sleep 100'
>>
>> does not skip a fork.
>
> POSIX's Shell and Utilities (XCU) 2.12 [1] does say that "[the]
> environment of the shell process shall not be changed by the utility",
> and that environment includes open files. My understanding is that
> dash's new behaviour (and incidentally, ksh93's one) is incorrect.

Is your question about POSIX or about correct behavior in Debian?  If
POSIX, the list to contact is austin-grou...@opengroup.org.  If
Debian, please feel free to brainstorm at debian-devel@, to provide
supporting information to d...@packages.debian.org (or any dash bug
report), to clarify policy using the debian-policy@ list, or to
consult debian-ctte@ if you do not trust Gerrit's judgement.

Hope that helps,
Jonathan


--
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/20111006144058.GA5415@elie

Bug#637965: general: Kernel panic when unmounting partitioned Hitachi X500 USB disk

[Jonathan Nieder]

reassign 637965 linux-2.6
forcemerge 634681 637965
quit

Hi José,

José Hipólito Moyano wrote:

> When my hitachi X500 500GB USB external disk is unmounted, it has more than 
> 50%
> probability of cause a kernel panic.

"general" is not the package for kernel bugs.

> Call Trace:
>  [] ? __blk_put_request+0x23/0x8d
[...]
> EIP: [] elv_completed_request+0x33/0x3e SS:ESP 0068:f5c5ff10
[...]
> Pid: 3, comm: ksoftirqd/0 Tainted: G  DO 3.0.0-1-686-pae #1

Nice screenshot. :)   This should be fixed by version 3.0.0-5 from
unstable; if that doesn't work, please feel free to let us know.

Thanks for reporting,
Jonathan



--
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/20111017032545.ga5...@elie.hsd1.il.comcast.net

Bug#616317: base: commit= ext3 mount option in fstab has no effect.

[Jonathan Nieder]

reassign 616317 initscripts
quit

Roger Leigh wrote:
> On Sun, May 08, 2011 at 05:24:09AM +0100, Ben Hutchings wrote:

>> Could we not have init remount root based on /etc/fstab?
[...]
> Also, with the version of initscripts in experimental, the domount
> mount helper can remount filesystems with the options from /etc/fstab.

I guess that means this bug was fixed by initscripts 2.88dsf-13.5.

[...]
>> I suppose the problem then is that some
>> mount options can't practically be changed when remounting.  (Worse, the
>> failure to change them is silent in some cases.  And that is definitely
>> a bug.)

That sounds like a separate bug, though probably an important one.
Could you say more about it?  For example, which package would have to
be changed to fix it?

lazily,
Jonathan



-- 
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/20111017033708.ga6...@elie.hsd1.il.comcast.net

Bug#626736: general: can't ping windows machine by name

[Jonathan Nieder]

retitle 626736 debian-reference: please explain how to set up NETBIOS name 
resolution
reassign 626736 debian-reference 2.46
severity 626736 wishlist
quit

Hi Sergey,

sergey wrote:

> I had the next situation some time ago: several computers with
> Windows and one GNU/Linux system connected to router with DHCP
> server. DHCP server dynamically assign IP addresses to this
> machines.
[...]
> I can't use name of machine because GNU/Linux is not support NETBIOS
> name resolution by default.
>
> IMHO it is great secret for typical user that it can be enabled
> througth nsswith.conf. 

This isn't a bug that affects a large subset of the archive, so
"general" was the wrong package to file it against.

Anyway, if I understand correctly, you are saying that the method
for enabling WINS hostname resolution (using nsswitch.conf) is too
difficult to discover.  I'm reassigning to the Debian reference,
so we can consider explaining it in an appropriate place there.

Help of all kinds (finding where to put this text, rough wording,
proofreading) would of course be very welcome.

Thanks for your interest,
Jonathan



-- 
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/20111017034719.ga6...@elie.hsd1.il.comcast.net

Bug#635157: cups: please support Brother HL-2130 laser printer out of the box

[Jonathan Nieder]

retitle 635157 Brother HL-2130 laser printer support
severity 635157 important
severity 618640 important
reassign 635157 cups
quit

Hi,

micha...@gmail.com wrote:

> Using Squeeze and wanted to install a new Brother HL-2130 laser printer.
> Noticed that the printer is not in the printer list from Debian.
>
> Went to Brother's Linux driver site
> (http://welcome.solutions.brother.com/bsc/public_s/id/linux/en/download_prn.html#HL-2130),
> download the packages and everthing works well.
>
> Suggest to update Debian's driver list (since Brother is providing them) so
> that these working drivers can be added to benefit future users.

Thanks for a nice report.  I'm passing it on to the Debian CUPS
maintainers with this message.



-- 
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/20111017035151.ga6...@elie.hsd1.il.comcast.net

Bug#635462: general: Update manager freezes when started

[Jonathan Nieder]

reassign 635462 update-manager-gnome
tags 635462 + moreinfo
quit

Hi Eric,

Eric Wilson wrote:

> Package: general

This report concerns one package rather than a large portion of the
archive, so "general" is not the right package.

> Update manager opens then freezes while checking for updates

Could you provide more details?  For example, are you able to close
the program, and how does this compare to symptoms reported in other
bugs against the update-manager-gnome package?



-- 
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/20111017035617.ga6...@elie.hsd1.il.comcast.net

Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when disabled via /etc/default/foo

[Jonathan Nieder]

tags 601455 - patch
retitle 601455 multiple, annoyingly different ways to disable an init script
quit

Hi Mathias,

Mathias Kub wrote:

> When I try to stop a daemon after I disabled it in /etc/default/foo,
> I get an error-message that I can not stop it, because it is
> disabled.
>
> Shouldn't I be able to stop it even if I disabled it first?

Yes, I agree that this is a bug.  Nowadays the appropriate way
to disable an init script is to remove the 'S' links without removing
the 'K' links, for example by running

update-rc.d foo disable

Unfortunately:

 1. That is not as well known is it ought to be.  For example, section
4.6.3. "Restricting access to some server services"[1] of
debian-reference could be clarified to emphasize this method.

 2. Many packages seem to provide ENABLE/DISABLE variables in
/etc/default/foo, providing a confusing red herring for this
task --- a second method which does not work nearly as well,
as you pointed out.

 3. The tempting "update-rc.d foo remove" (which removes the 'K'
links, too) might _seem_ to work, except that the next time the
foo package is upgraded, the service is back again.

One possible way to move forward would be to write a patch to the
debian reference and any other pertinent documentation to address (1)
and (3) and (once consensus that this is a good idea is reached) to
file bugs requesting removal of the ENABLE/DISABLE vars to address (2),
blocking this bug by them.  When the last such variable is eliminated
from the default conffiles in /etc/default, this bug could be closed.

A complicating factor is that the sysadmin may already have customized
some ENABLE/DISABLE settings and a move like this should not override
their settings.  So perhaps packages should stop advertising the
ENABLE/DISABLE vars in /etc/default/, but continue to respect
them when set.

Sane?

Thanks,
Jonathan

[1] 
http://www.debian.org/doc/manuals/debian-reference/ch04.en.html#_restricting_access_to_some_server_services



-- 
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/20111017041202.ga6...@elie.hsd1.il.comcast.net

Bug#601455: general: can't stop daemon using /etc/init.d/foo stop when, disabled via /etc/default/foo

[Jonathan Nieder]

Hi,

peter green wrote:

> Though there are some situations where it is nessacery. Consider vtund for
> example which has seperate enable/disable flags for running in server and
> client modes (with the potential for multiple seperate client instances).

Thanks for this clarification.  Luckily vtun's RUN_SERVER option is
not an instance of the DISABLE pattern Mathias mentioned: it does not
work by exiting the init script early, and it does not prevent
stopping the server.

> regardless of any plan to discourage use of the /etc/default
> mechanism (I think removing it altogether is not really reasonable)

To be clear, I didn't mean to suggest that configurability through
/etc/default is something to be phased out or discouraged --- only the
DISABLE variables.  If you consider that unreasonable, could you
explain how, so others can come up with something better that
addresses your concerns?

[...]
> I think
> the original bug of being unable to stop
> a dameon after disabling it in /etc/default still needs to be fixed.

Feel free to file reports against individual packages (especially
reports with patches!).  However, if one wants to make a serious dent
in this in the archive as a whole, it seems worthwhile to take the
extra minutes to move to a saner interface for disabling services at
the same time, instead of just patching the current "pretend you're
running, but don't run" method.

Cheers,
Jonathan



-- 
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/20111021002636.ga17...@elie.hsd1.il.comcast.net

Re: segfault error 4 in libpthread-2.13.so X86_64

[Jonathan Nieder]

Dallas Clement wrote:

> Will report back what I find.

Please don't.  This is the wrong list --- it is about development _of_
Debian, not development _on_ Debian.

You might find the libc-help list[1] to be more helpful.  Or if your
questions are Debian-specific, debian-user[2] can be a great help.

Hope that helps,
Jonathan

[1] see http://sourceware.org/glibc/
[2] http://lists.debian.org/debian-user/


-- 
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/20111031194208.ga10...@elie.hsd1.il.comcast.net

Re: Minified files and source code requirement

[Jonathan Nieder]

Russ Allbery wrote:

> I think a better line is whether the source tarball includes all the
> pieces required for someone with appropriate skills to make modifications
> to the software with reasonable ease.  The advantage of that, as opposed
> to trying to weigh whether upstream has additional advantages, is that
> it's a judgement call that can be made solely based on the contents of the
> source tarball without reference to anything external.

Do we agree that minified Javascript libraries do not meet this
criterion (for non-broken definitions of "reasonable")?  If so, I'd
leave the other theoretical cases for until someone proposes an
appropriate wording for a change to the constitution or policy (so
then we can have the shared goal of debugging that wording[*]).

If not, of course, that point of disagreement seems like a good place
to focus the discussion.

Hope that helps,
Jonathan

[*] of course, the current wording ("The program must include source
code") is buggy because vague.  But that's harder to debug without an
example people disagree about.


-- 
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/2002195530.ga17...@elie.hsd1.il.comcast.net

Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Hi,

In February, I wrote[1]:

> Both LinuxNode (package "node") and node.js (package "nodejs") are
> designed to be accessed through the command name "node".
[...]
> If there is any way I can help, please feel free to ask.

No response from the "node" package maintainers.  My offer still
stands, but I am worried that this is not going to be fixed before the
next release.

So, what next?  Should the node package be orphaned?  Based on popcon,
it seems to have a small but respectable and growing number of users.
Maybe if the current status of the package were more obvious, someone
would start working on it (well, one can hope).

Yours,
Jonathan

[1] http://bugs.debian.org/614907


-- 
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/2006072651.ga31...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Hi Pat,

Patrick Ouellette wrote:

> The binary on the ham radio side is not "LinuxNode" in package "node" it is
> simply "node" in package "node"
>
> Since you are still concerned with this issue, and neither side has shown a
> willingness to change, I would say the time has come for both packages to be 
> renamed.

Just to be clear: both package names are fine --- it's the names of
the binaries that cause trouble.

Being a user of neither package, I'd actually prefer for the name of
the javascript interpreter to stay "node" (sorry!).  It is the
difference between needing to change the configuration of one
superserver and needing to change the shebang line and content of many
scripts.  However, if the only way to include both node and nodejs in
wheezy is for the interpreter binary to be renamed, too, that's ok
with me.  There's currently a release-critical bug against nodejs
about that.

Should the binary on the ham radio side be called ax25-node, or
LinuxNode, or something like that?  Given a proposed name, I would be
happy enough to assume I have your blessing and start sending patches
to the node bug. :)

> Pat (one of the unresponsive ham radio maintainers)

Glad to hear from you, and thanks for your hard work keeping the
amateur radio stack working.


-- 
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/2007032031.ga25...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Patrick Ouellette wrote:

> You claim to not use either package, but yet you advocate for the node.js
> package to keep the executable name "node" - this is strange to me.

Sorry, I must have been unclear.  I was only explaining my preference.
I wasn't lying.  I also said:

>> However, if the only way to include both node and nodejs in
>> wheezy is for the interpreter binary to be renamed, too, that's ok
>> with me.

Indeed, renaming both is what policy (and good sense) requires in the
absence of consensus.  I guess it was foolish of me to imagine that
there could be a discussion resulting in consensus based on something
other than which tool is most important!  (Both tools are obviously
important in their communities.)

[...]
> Are you a ham radio operator, or do you have another reason to be interested
> in the eventual name of the ham radio package?
[...]
> When the ham radio maintainers decide on how to implement the
> fix, they will.

No, I am not a ham radio operator.  I was worried because this
(release-critical) bug had received no response for three quarters of
a year.  I'm glad to hear you say "when" rather than "if" here --- as
far as I can tell, you are saying that I should not be worried and
this bug is not stalled after all.

I am interested in Debian remaining useful for a variety of purposes,
which is why I want to see some proposed fix enter unstable early
enough to shake out problems so wheezy can both include fundamental
tools for ham radio operators and for web developers.

Sorry for the lack of clarity.
Jonathan


-- 
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/2007053255.gc25...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

(+cc: nod...@packages.debian.org.  Sorry for the noise.)
Jonathan Nieder wrote:
> Patrick Ouellette wrote:

>> You claim to not use either package, but yet you advocate for the node.js
>> package to keep the executable name "node" - this is strange to me.
>
> Sorry, I must have been unclear.

A few more words of clarification:

It might seems strange that someone using neither package cares about
these bugs.  So here is why I care:

 1. I use Debian.  I do not want it to be broken (one aspect of "broken"
is the same command having different effects depending on which
package is installed).  My experience is that for better or worse, if
the project can't fix a bug like this one, new maintainers of other
packages in similar situations will take it as an example and
introduce even more breakage.

 2. Ham radio projects seem neat to me.  Lots of nice people,
including John Goerzen, are ham radio operators.  It would be nice
to make sure Debian continues to make their lives pleasant and
makes my life pleasant if I ever acquire the appropriate hardware.

 3. node.js seems neat to me.  Lots of nice people including Jonas
Smedegaard use it to program.  I imagine that at some point in the
future, even if I never start to use the language myself, I might
find myself running programs using it (like has happened to me
with ruby already).

I hope you care some small amount about packages you don't currently use,
too. :)


-- 
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/2007055326.gd25...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Cyril Brulebois wrote:
> Vincent Bernat  (14/11/2011):

>> See how communities may react to  this. Ruby community does not like our
>> packaging just  because we enforce stability over  freshness. What would
>> think  node.js community  if  we are  using  /usr/bin/nodejs instead  of
>> /usr/bin/node. Debian would  be listed as a black sheep  in every FAQ or
>> tutorial and  users will  be invited to  just install some  non official
>> package or use the source.
>
> Oh noesoneoneoneeleven

Or to put it another way, one could kindly explain to such people that

 (1) the node.js packaging in unstable or experimental is reasonably up to
 date (if that is true --- I just don't know, but it presumably could
 be easily could be made to be so if someone wants to do that)

 (2) faced with a diverse userbase that was using the "node" command for
 two different purposes, Debian is doing the only thing it can do to
 make scripts reliable: rename both.  As a nice side-effect, we get a
 simple, Google-able name for the tool.  People unhappy with the
 divergence from upstream can do one of two things:

 (a) install a /usr/local/bin/node -> ../../bin/nodejs symlink locally,
 by running the following handy install-nodejs-symlink script

 (b) work with upstream to provide the interpreter under both names,
 so scripts can use "#!/usr/bin/env nodejs" to be self-documenting
 and work reliably everywhere

(By the way, most of the description under (2) might apply to the ham
radio tool, too.  In other words, none of this seems particularly unique
to interpreted languages.)


-- 
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/2014214013.ga3...@elie.hsd1.il.comcast.net

Re: Two groups of users, one distro in the middle

[Jonathan Nieder]

Hi,

Alex Pennace wrote:

> According to [1], this isn't the first time the nodejs folks ran into
> a name problem. Up until March of 2009 they were using the name
> "server,"

I suspect this was just a working title for the program being
developed, in the half month before Ryan was able to come up with a
real name[2].  I mentioned it in [1] just as a "Why the name?" factoid
and have regretted mentioning it ever since.

> [1] http://bugs.debian.org/611698#40
[2] commit 19478ed4: 'Major refactoring: program name now "node"',
2009-03-03.


-- 
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/2014235008.ga5...@elie.hsd1.il.comcast.net

Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

[Jonathan Nieder]

Wolfgang Tichy wrote:

> Thanks for your answer. I think the intel compiler does support the -B
> and -I options. So I think your suggestion would work. However, I am
> not sure if I like this solution.

It's only a workaround.  A fix would involve contacting the Intel
developers to get icc to search the new paths by default.

> I always loved debian for the fact
> that libraries and include files were in standard places (unlike say
> in redhat based distributions). So it was always easy to compile with
> any compiler.

Yes, I understand.

> Moving them to other places seems to complicate things.
> I mean I am no expert on multiarch and guess there are good reasons
> for that. But why can't there be symlinks to the files you need for
> your own architecture in standard places? Would that break something?

There are two sides to that question: would adding such symlinks be
feasible?  And would the resulting behavior of the system be desirable?

Compatibility symlinks for multiarch: the use case
--

Let's take the second question first.  If /usr/lib and /usr/include
were filled with symlinks to the corresponding architecture-specific
files for the native architecture, there would be some nice benefits:

 - multiarch-unaware compilers would continue to work
 - programs hard-coding paths to libraries would continue to work

On the other hand, binaries and builds for foreign architectures
would be likely to misbehave when libraries for that arch are missing
(/usr/lib//foo.so is missing and /usr/lib/foo.so is not).  So
for someone using only multiarch-aware programs, the net effect is
negative.

Compatibility symlinks for multiarch: feasibility
-

Now the first question.  In wheezy, packages that are marked as such
can be installed on multiple architectures at once.  So, for example,
I can install the i386 and the amd64 versions of libavcodec at the
same time.

Which package would get to put a symlink to its library in /usr/lib?

It's tempting to say "the native one", but it is not always clear
which one that is.  In fact, one of the goals of multiarch is to be
able to (gradually) upgrade an i386 system to an amd64 one.  At what
point has the native architecture switched?

A proposal
--

The above suggests to me a possible way forward.  To be clear, I do
not want to work on this; this is just a sketch of one way that people
who do want to work on it could try.

The idea is that there would be a separate package that installs
compatibility symlinks pointing to /usr/lib//* and
/usr/include//* to help people still using multiarch-unaware
tools.

Its post-installation script would be a simple script that scans
/usr/lib/ and /usr/include/ for added or removed
libraries and updates the corresponding symlinks in /usr/lib and
/usr/include.  Using triggers (see [1]) it would ensure that this
script is run for each apt run in which a file is installed to or
removed from /usr/lib/ or /usr/include/.

This compatibility package could be removed at any time and
multiarch-aware packages would continue to work.

(Based on an idea from Matthias Klose[2].)

Of course, I would be even happier to see tools like icc learn about
the new paths.

Hope that helps,
Jonathan

[1] /usr/share/doc/dpkg-dev/triggers.txt.gz
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821

> Thanks,
> Wolfgang
>
> PS: I do not mean to complain. I think Debian is great and I am
> grateful for the job you maintainers do. I only write because I like
> Debian, and thought this might be helpful...



-- 
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/2016035012.ga5...@elie.hsd1.il.comcast.net

Re: what if a package needs to be "recalled"

[Jonathan Nieder]

Russell Coker wrote:

> Isn't this one of the reasons for the epoch field?

No.  If chromium 14.0.835.202~r103287-1 actually worked[1], the
thing to do would be to upload a package with version number
15.0.874.106~r107270+really14.0.835.202~r103287-1.  That way,
the blip in version numbering can be only temporary.

[1] Alas, it doesn't work: http://bugs.debian.org/649378


-- 
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/2021000958.ga11...@elie.hsd1.il.comcast.net

Re: Piklab

[Jonathan Nieder]

Salvo Tomaselli wrote:

> Perhaps you could consider maintaining it?

Unless you're suggesting that Richard maintain KDE3, too, that doesn't
seem like very practical advice.

Following the links from , I see
that piklab was removed because it unfortunately has no KDE4 port.  So
if you would like to see it back in Debian, a good strategy might be
to port it to KDE4[1] and then file a request for package[2].

Sincerely,
Jonathan

[1] 
http://techbase.kde.org/index.php?title=Development/Tutorials/KDE4_Porting_Guide
[2] http://www.debian.org/devel/wnpp/#l1


-- 
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/2022115120.ga10...@elie.hsd1.il.comcast.net

Re: Piklab

[Jonathan Nieder]

Salvo Tomaselli wrote:
> Il 22.11.2011 12:31 Richard ha scritto:

>> Can piklab be added to the distro, its stable and runs Ok on wheesy/sid.
[...]
> Perhaps you could consider maintaining it?

My last reply completely missed the point.  According to [1] the
program was already ported to Qt 4.

Sorry for the noise!  Salvo's advice is excellent --- preparing and
maintaining a package using the pointers from [2] would be greatly
appreciated.  (Otherwise, feel free to file a "request for package"
bug and help whoever responds to it in whatever way you can.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604320#29
[2] http://www.debian.org/devel/


-- 
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/2022115719.ga10...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Ian Jackson wrote:

> I think the best way to fix this is to prepare both renaming uploads
> in advance, and allow either of the two contending maintainers to
> upload both packages simultaneously.

Thanks, that sounds sensible to me.

Since this still seems to be stalled, I would like to hear from the
nodejs maintainers whether this approach would be okay with them and
whether there is anything others involved with Debian can do to help
with the migration.

(Yes, that includes helping talk with upstream to get nodejs accepted
as a synonym so scripts with "#!/usr/bin/env nodejs" can work
everywhere.  Yes, that includes changing policy, if you happen to have
a coherent proposal in mind.)

Regards,
Jonathan


-- 
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/2028231624.ge20...@elie.hsd1.il.comcast.net

Re: Is anyone maintaining (the ham radio tool) node?

[Jonathan Nieder]

Jérémy Lal wrote:

> I can prepare a patch for nodejs package.

Thanks!

[...]
> - I can't help but talk about "npm", an essential development tool distributed
> in latest nodejs (can be compared to ruby's gem). It allows one to install and
> publish npm packages to a common registry.
> It will need a patch to rename shebangs on-the-fly, and maybe rename them back
> when publishing. Npm author is working closely with nodejs authors.

Filed as bug#650345.

[...]
>> Yes, that includes changing policy, if you happen to have
>> a coherent proposal in mind.)
>
> I don't understand, could you explain why / which policy ?

Debian policy.  I was thinking of [1] as I said this.  But I do not
personally have any idea about how policy could be improved in this
area.

Sincerely,
Jonathan

[1] http://lists.debian.org/debian-devel/2011/11/msg00380.html


--
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/2029012236.gc28...@elie.hsd1.il.comcast.net

Bug#646622: Changelog for new upstream release should include summary of upstream changelog

[Jonathan Nieder]

retitle 646622 apt-listchanges: please parse upstream changelog, too (perhaps 
with packages' help)
reassign 646622 apt-listchanges 2.85.8
quit

Hi,

Nemo Inis wrote:

> I have a suggestion from an end-user point of view:
>
> All too often when checking incoming updates (in Synaptic or other tools) the
> Debian changelog includes a mere mention "new upstream release".
[...]
> But for the convenience of the end-user, it would be nice
> if a summary of the upstream's changelog would be included too (like new
> features, UI changes, backward compatibility problems, etc..) This would avoid
> having to go hunt for it on every single package, and would make the whole
> process more user-friendly.

The package you are looking for is debian-policy.  But I am going to
assign this report to apt-listchanges instead --- if apt-listchanges
could parse upstream changelogs (with maintainer help), then there
would be no need for a summary in the Debian changelog except when a
particularly notable upstream change has appeared.

I can imagine two different ways to do that:

 A. Encourage packagers to provide a metadata file with the following
information:

format: the upstream changelog format.  The value is the name
of a changelog parsing helper fulfilling the
dpkg-parsechangelog interface, like the argument to
"dpkg-parsechangelog -F"

dversionmangle: a rule to map from the upstream component of
the Debian version to an upstream version number, just like in
uscan's "debian/watch" file.

Or:

 B. Maintain state out-of-band to indicate how much of the upstream
changelog has been read.  E.g., keep the top few lines read and
total number of lines, and for each new version we look for lines
similar to those lines the indicated number of lines from the end
of the file to decide where the new changelog entries stop.

Sane?

Thanks and hope that helps,
Jonathan



-- 
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/2029094532.ga1...@elie.hsd1.il.comcast.net

Re: suggestion: build-blockers field in control file

[Jonathan Nieder]

peter green wrote:

[...]
> This leads to the building of
> uninstallable packages which in turn leads to problems with testing
> transition of packages.
>
> Currently there are two workarounds for this situation
>
> 1: manually alter the package's architecture list to limit building to those
> architectures where runtime dependencis
> 2: add an artificial build-dependency

For completeness, it's probably worth mentioning a third option:

 3: use the architecture list to document fundamental portability hurdles
and packages-arch-specific[*] to document accidental ones

[*] 
http://www.debian.org/doc/manuals/developers-reference/pkgs.html.en#packages-arch-specific


-- 
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/2029200854.ga9...@elie.hsd1.il.comcast.net

Re: from / to /usr/: a summary

[Jonathan Nieder]

Hi,

Just a quick side-note.

Marco d'Itri wrote:

> Some changes are coming from upstream and we will have to either embrace
> them or actively revert them.

There is a third option: help upstream to maintain what they consider
the "legacy" alternative.  Many upstreams, including at Red Hat, seem
to be willing to work with downstream packagers that contribute
patches.

Of course that has nothing to do with the real motivation no one has
mentioned, which is that deciding for each binary whether to put it in
/bin or /usr/bin is a pain in the neck.  It very well may be sensible
to tweak the boot process to mount /usr sooner to avoid that trouble.
The main technical difficulty seems to be platforms where it is common
to boot without an initramfs (for example, if it is hard to
reconfigure the bootloader and the bootloader is already set up to use
a plain kernel).

Hope that helps,
Jonathan


-- 
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/20111208194638.ga5...@elie.hsd1.il.comcast.net

Re: from / to /usr/: a summary

[Jonathan Nieder]

Marco d'Itri wrote:

> In this case, it has been made repeatedly clear by the upstream
> maintainers that they have no desire to accept code to support this and
> other things.

_If_ upstream is taking the stance that portability to other platforms
is something they want nothing to do with, then that's fine.  Each
developer is free to work on what she finds useful.  It just means
that one has to find some other way to cooperate with others
interested in portability patches.

I don't think this phenomenon is in any way unique to udev.  E.g., if
I remember correctly then core (OpenBSD) OpenSSH development and
portable OpenSSH are maintained as distinct projects.

> (Often, the same code was actually removed from the package.)

BTW, thanks for your work, and I don't mean to imply that the choices
you are advocating are bad ones.  Just that I'd find proposals
justified on technical grounds more convincing than acting helpless
and claiming we are at the mercy of an upstream that is not willing to
listen.

Sincerely,
Jonathan


-- 
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/20111209062504.ga9...@elie.hsd1.il.comcast.net

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

[Jonathan Nieder]

Roger Leigh wrote:

> The question that needs answering is this:
>
>   "what are the reasons, today, for a separate /usr?"

No, I don't think an answer to that precise question today would be
especially helpful.  As far as I can tell, it is not especially
unsensible to use separate partitions for /usr, /etc, /var, /boot, and
/opt.  And whether it is sensible or not, unless you have a tool in
mind that will automatically change the partitioning scheme of a
running system, that's not going to help udev or crda very much.

An obvious question to answer to help these programs is whether it
makes sense to make /usr a separate partition and not mount it before
starting init.  An even more obvious question is "where is the patch
for initramfs-tools?". ;-)

[...]
> The same argument applies to encryption.  / and /usr both contain a
> selection of programs, libraries etc.  If you're encrypting one, why
> would you not encrypt all of it?  And the same for mounting read-only.

Regarding mounting read-only: files in /etc change far more often than
files in /usr/bin, for one thing.

Hope that helps,
Jonathan



-- 
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/20111214211419.ga3...@elie.hsd1.il.comcast.net

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

[Jonathan Nieder]

Two clarifications:

Jonathan Nieder wrote:
> Roger Leigh wrote:

>> The question that needs answering is this:
>>
>>   "what are the reasons, today, for a separate /usr?"
>
> No, I don't think an answer to that precise question today would be
> especially helpful.

I'd like to apologize for this response.  Hearing use cases is always
welcome, especially when they are given in the spirit of being helpful
rather than defensiveness.

> As far as I can tell, it is not especially
> unsensible to use separate partitions for /usr, /etc, /var, /boot, and
> /opt.

It occured to me too late that it might sound like I am saying a /etc
partition separate from / can work.  By "separate" I only meant
"distinct" (i.e., the /usr, /etc, /var, etc inodes all coming from
different mounts).

I also think I misunderstood your message.  What kind of unification
are you advocating?  Fedora's setup, for example, allows /usr to be a
separate filesystem.

Sorry for the noise,
Jonathan



-- 
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/20111214213141.ga4...@elie.hsd1.il.comcast.net

Re: authbind (LD_PRELOAD) and multiarch

[Jonathan Nieder]

Osamu Aoki wrote:

> Also, for such input method plugins, we have a hook and configuration script
> "im-config" to initialize such input method environment while starting X.

Could you spell this out more?  What environment variables will
im-config set that include architecture names?  Which architecture
should they name --- the architecture of the /usr/bin/X binary?

> To update im-config for multiarch, I would like to have access to following
> commands without depending on the dpkg-dev package since user program 
> depending
> on -dev package is weired:
>
> * current-library-path
>   equivalent of
>   $ dpkg-architecture|sed -n 's/^DEB_HOST_MULTIARCH=\(.*\)/\1/p'

When building a new program, "gcc -print-multiarch" seems to be the
usual way.

> * installed-library-path
>   list all library-path
>   I do not know how to get this reliably

ld.so does not expose that information.  However, you can search for a
library used by a binary on the library path with "ldd".

[...]
> On Thu, Dec 22, 2011 at 08:01:24PM +0100, Goswin von Brederlow wrote:

>> This is something that could use some native english speaker to write a
>> proposal/specs for with some examples where it is needed. Any takers?
>
> Yes.
>
> (I guess since we are talking spec, there is no tools such as apt-get nor
> aptitude to manage such dependencies.)

While the kind of interfaces you are talking about would be welcome, I
don't think they are what Ian and Goswin were looking for.  I think they
wanted a way to tell the packaging system "This package (fakeroot)
depends on this library (libfakeroot) from all enabled architectures",
or "This package (something-input-method-related) depends on this
library (some-input-method-plugin) from the same architecture as this
other package (some-daemon-that-will-dlopen-it)".

Hope that helps,
Jonathan


-- 
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/20111224014501.GA26794@elie.Belkin

Re: Outstanding /dev/.udev bugs for /run migration

[Jonathan Nieder]

Roger Leigh wrote:

> There are 19 packages still using /dev/.udev after udev transitioned
> to /run/udev.  Unless there are any objections, I'd like to raise the
> severity of these bugs from important to serious, given that the /run
> migration is a release goal.

If "given that the /run migration is a release goal" were the rationale,
I'd object.

Am I correct in understanding that these are potentially important or
grave bugs because any code relying on /dev/.udev is simply broken
with current udev?  /dev/.udev doesn't seem to exist.


-- 
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/20120112230813.GA20584@burratino

clarifying copyright policy (Re: status of DEP5: Machine-readable debian/copyright)

[Jonathan Nieder]

Charles Plessy wrote:

> I would love the answer to this question documented somewhere, but I think
> that it would not belong to the DEP 5 document.  If you would like, you
> can send the question to the FTP Master team and CC the bug number #462996
> (“Document requirements for copyright file.”).

Or you could send a proposal to bug#462996 or another policy bug and
cc the FTP team as an affected party when it is time to build
consensus.  After all, taking on the legal risk and administrative
burden of _carrying out_ the decision of whether packages are
appropriate for inclusion in the archive doesn't imply they have
volunteered to also do the difficult work of writing a complete and
unambiguous specification about it.  Others can help them.

Hope that helps,
Jonathan


--
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/20120117173602.GA20476@burratino

Bug#658980: [skge] transmit queue 0 timed out

[Jonathan Nieder]

severity 658980 important
reassign 658980 src:linux-2.6 3.1.8-2
quit

burek wrote:

>   I was watching a movie online, using VLC media player and it
> just stopped playing. [...]  The debian was completely cut off of
> the internet.  Ping couldn't resolve any host, ifconfig reported
> nothing unusual, /etc/init.d/networking restart didn't help
[...]
> WARNING: at 
> /build/buildd-linux-2.6_3.1.8-2-i386-3fqT1n/linux-2.6-3.1.8/debian/build/source_i386_none/net/sched/sch_generic.c:255
>  dev_watchdog+0xb1/0x104()

Thanks for reporting it.  Is this reproducible?

Curious,
Jonathan

> Hardware name: To Be Filled By O.E.M.
> NETDEV WATCHDOG: eth0 (skge): transmit queue 0 timed out
> Modules linked in: snd_seq_dummy ppdev lp bnep rfcomm snd_hrtimer fuse loop 
> snd_usb_audio snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss 
> snd_pcm snd_hwdep snd_usbmidi_lib radeon snd_seq_midi snd_seq_midi_event 
> snd_seq ttm drm_kms_helper cryptd drm aes_i586 joydev aes_generic snd_rawmidi 
> snd_timer snd_seq_device i2c_algo_bit uvcvideo power_supply ecb videodev 
> usbhid media hid snd iTCO_wdt btusb iTCO_vendor_support i2c_i801 i2c_core 
> bluetooth soundcore shpchp pci_hotplug snd_page_alloc rfkill crc16 rng_core 
> evdev pcspkr parport_pc parport processor button thermal_sys ext3 jbd mbcache 
> sd_mod sr_mod crc_t10dif cdrom ata_generic ata_piix libata scsi_mod skge 
> uhci_hcd ehci_hcd usbcore [last unloaded: scsi_wait_scan]
> Pid: 0, comm: swapper Not tainted 3.1.0-1-686-pae #1
> Call Trace:
>  [] ? warn_slowpath_common+0x68/0x79
>  [] ? dev_watchdog+0xb1/0x104
>  [] ? warn_slowpath_fmt+0x29/0x2d
>  [] ? dev_watchdog+0xb1/0x104
>  [] ? local_bh_enable+0x2/0x2
>  [] ? run_timer_softirq+0x150/0x1f3
>  [] ? netif_tx_unlock+0x3a/0x3a
>  [] ? local_bh_enable+0x2/0x2
>  [] ? __do_softirq+0x94/0x12f
>  [] ? local_bh_enable+0x2/0x2
>[] ? irq_exit+0x32/0x80
>  [] ? smp_apic_timer_interrupt+0x5b/0x65
>  [] ? apic_timer_interrupt+0x31/0x38
>  [] ? native_safe_halt+0x2/0x3
>  [] ? default_idle+0x52/0x87
>  [] ? cpu_idle+0x90/0xaa
>  [] ? start_kernel+0x32a/0x32f
> ---[ end trace 42a84afd9f63b42e ]---
> skge :02:05.0: eth0: disabling interface
> skge :02:05.0: eth0: enabling interface
[...]
> After that, I restarted my home router and then I was able to ping
> it and log into it over the web interface, but nothing after the
> router could be accessed, until the reboot.



-- 
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/20120207074002.GA5060@burratino

Re: Please test gzip -9n - related to dpkg with multiarch support

[Jonathan Nieder]

Henrique de Moraes Holschuh wrote:

> Maybe you can switch to sha256 and add the new functionality while at
> it?  Detect which mode (md5sum raw, sha256 uncompress) by the size of
> the hash.  Old debsums won't work with the new files, but is that really
> a problem?  That's what stable updates and backports are for...

No, I do not believe random Debian-internal compatibility breaks are
what stable updates are for.


-- 
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/20120207234446.GB5928@burratino

Re: Please test gzip -9n - related to dpkg with multiarch support

[Jonathan Nieder]

Ian Jackson wrote:

> Another relevant question is whether there are other files that are
> shared, and which don't want to move, besides ones in /usr/share/doc.

One example is header files in /usr/include, from -dev packages.  In
the simple examples I've seen, putting them in /usr/include/,
works fine.  It is always possible to split off a separate "Multiarch:
foreign" -dev-common package if needed in order to save space.

Another example is manpages, also in -dev packages.  That's more
fussy.


-- 
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/20120208172627.GA6712@burratino