Re: Packages with empty directories

Am Mittwoch, den 21.11.2007, 05:11 +0100 schrieb Michael Biebl: > All of my packages listed there are false positives. What I noticed > though, are a lot of packages, shipping empty /usr/sbin, /usr/bin/, > /usr/lib/ or /usr/include directories. > This directories, very likely, come from dh-make *.d

Re: Early adopters of symbol based dependencies needed

On Tue, Nov 20, 2007 at 04:22:56PM +0100, Raphael Hertzog wrote: > Hello, > > since the upload of dpkg 1.14.8 to unstable, it's now possible for > library packages to generate "symbols" control files that will be used by > other packages to get more accurate (and less strict) dependencies. > > As

Re: Early adopters of symbol based dependencies needed

On Tue, 20 Nov 2007, Russ Allbery wrote: >I always use dependencies like >= 2.10 in shlibs files rather than the >more specific 2.10-1 because of this problem. I'm not sure if that's >the right general solution, but people who start from the seed files >should at least consider rem

Re: Packages with empty directories

Hi, Le mercredi 21 novembre 2007 à 05:20 +0100, Michael Biebl a écrit : > Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and > /usr/include directories (as created by dh-make) would be a good start. Maybe we could check for empty directories except for a number of common fals

Re: Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Mike Hommey wrote: > FWIW, I'm testing this on libxml2. I'd have some remarks: > - The .symbols file in /var/lib/dpkg/info is bigger than all the other > maintainer files there for libxml2. If a significant amount of packages > implement this, it can start to make a difference.

Re: Early adopters of symbol based dependencies needed

Raphael Hertzog <[EMAIL PROTECTED]> writes: > This change was precisely meant to silence those warnings. But it looks > like this line is problematic: > return exists $self->{flags}{DYNAMIC} and $self->{flags}{DYNAMIC} > and exists $self->{SONAME} and $self->{SONAME}; > > It's parsed as: >

Re: Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Russ Allbery wrote: > Be careful about && because you can get the opposite problem. > > exists $self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC} > > will be parsed as > > exists ($self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC}) > > It's often good style to always

Re: Packages with empty directories

* Josselin Mouette <[EMAIL PROTECTED]> [071121 10:08]: > Maybe we could check for empty directories except for a number of common > false positives (like the python-support directories or /var/games), and > for the rest, grep in the maintainer scripts. And menu-methods (which cause a lot of false-

Re: Early adopters of symbol based dependencies needed

Raphael Hertzog <[EMAIL PROTECTED]> writes: > Aren't they supposed to have a prototype to avoid such behaviour? Ah, indeed. I had forgotten about that. You're entirely correct. -- Russ Allbery ([EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMA

Re: Early adopters of symbol based dependencies needed

* Russ Allbery: >> As I understand it, this is only the case on i386 - on other arches, >> /usr/bin/perl links to libperl, although the modules don't. > > ...indeed. That's bizarre. Why is i386 different than all the other > platforms? Performance penalty of PIC code due to register pressure, I

Re: Early adopters of symbol based dependencies needed

This one time, at band camp, Florian Weimer said: > * Russ Allbery: > > >> As I understand it, this is only the case on i386 - on other arches, > >> /usr/bin/perl links to libperl, although the modules don't. > > > > ...indeed. That's bizarre. Why is i386 different than all the other > > platfor

Bug#452264: ITP: libid3-ruby -- Ruby interface to the id3lib library for editing ID3 tags

Package: wnpp Severity: wishlist Owner: Reto Schuettel <[EMAIL PROTECTED]> * Package name: libid3-ruby Version : 0.5.0 Upstream Author : Robin Stocker <[EMAIL PROTECTED]> * URL : http://id3lib-ruby.rubyforge.org/ * License : Ruby's Programming Lang: Ruby, C++

Re: Packages with empty directories

Josselin Mouette wrote: > Maybe we could check for empty directories except for a number of common > false positives (like the python-support directories or /var/games), and > for the rest, grep in the maintainer scripts. > zope-common needs /var/lib/zope and the Zope packages come with somthing

Re: Early adopters of symbol based dependencies needed

Raphael Hertzog wrote: > Given that shlibs are still used as fallback, I don't see a reason to > remove -V, in particular given that unofficial archs might not have > symbols files when they are arch-specific and when something specific > needs to be done to add support for a new arch. I thought t

Re: Early adopters of symbol based dependencies needed

Florian Weimer wrote: > * Russ Allbery: > > >> As I understand it, this is only the case on i386 - on other arches, > >> /usr/bin/perl links to libperl, although the modules don't. > > > > ...indeed. That's bizarre. Why is i386 different than all the other > > platforms? > > Performance penalty

Re: Bug#377392: Bug#450432: ... and even more bugs like this?

> Colin Watson <[EMAIL PROTECTED]> writes: >> In a recent thread in debian-devel, it was suggested that lintian >> could call man(1) in such a way that the groff(1), called by `man', >> will emit warnings for every undefined macro, which is useful in >> catching the bugs like this: >> .B

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

On Wednesday 21 November 2007, Henrique de Moraes Holschuh wrote: > On Tue, 20 Nov 2007, Frans Pop wrote: > > A patch is available, but the question facing Debian is: should we do a > > scan of the archive to see if and which binary packages are affected? > > Given the sort of insiduous, nightmaris

Re: Bug#377392: Bug#450432: ... and even more bugs like this?

On Wed, Nov 21, 2007 at 09:33:49PM +0600, Ivan Shmakov wrote: [snip] > A helper script, `lintian-man', could be introduced to hide all > the hackery, and to provide a way for the developer to reproduce > the problem. Then, Tag: may be changed to, e. g., > `manpage-has-messa

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

* Frans Pop <[EMAIL PROTECTED]> [2007-11-21 17:47]: > The most effective/efficient way to do this may be an archive rebuild with > a modified gcc that emits a warning if this case is hit and then check build > logs for the warning. > > Something like the patch below (stolen from the thread on linu

Re: Early adopters of symbol based dependencies needed

On Wed, 21 Nov 2007, Joey Hess wrote: > Raphael Hertzog wrote: > > Given that shlibs are still used as fallback, I don't see a reason to > > remove -V, in particular given that unofficial archs might not have > > symbols files when they are arch-specific and when something specific > > needs to be

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

On 21/11/2007, Martin Michlmayr wrote: > Sounds like something Lucas (CCed) could do. IIRC he is VAC at the moment, so someone might want to step in, so as to speed up the process. Cheers, -- Cyril Brulebois pgp6UZVhYfduu.pgp Description: PGP signature

Re: Long-term mass bug filing for crossbuild support

Scribit Neil Williams dies 13/11/2007 hora 17:02: > If you want to build an ARM toolchain to crossbuild for amd64 I'm not > going to stop you but don't expect me to debug it!! But do your tools make it already possible for me to just ask for the build of toolchains for an arbitrary list of target

Re: Early adopters of symbol based dependencies needed

On Wed, Nov 21, 2007 at 10:35:50AM +0100, Raphael Hertzog wrote: > On Wed, 21 Nov 2007, Mike Hommey wrote: > > FWIW, I'm testing this on libxml2. I'd have some remarks: > > - The .symbols file in /var/lib/dpkg/info is bigger than all the other > > maintainer files there for libxml2. If a significan

Re: Packages with empty directories

On Wednesday 21 November 2007 04:08:44 am Josselin Mouette wrote: > Hi, > > Le mercredi 21 novembre 2007 à 05:20 +0100, Michael Biebl a écrit : > > Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and > > /usr/include directories (as created by dh-make) would be a good start. > >

Re: Long-term mass bug filing for crossbuild support

Pierre THIERRY wrote: > Scribit Neil Williams dies 13/11/2007 hora 17:02: >> If you want to build an ARM toolchain to crossbuild for amd64 I'm not >> going to stop you but don't expect me to debug it!! > > But do your tools make it already possible for me to just ask for the > build of toolchains

Bug#452306: ITP: extrema -- powerful visualization and data analysis tool

Package: wnpp Severity: wishlist Owner: Christine Spang <[EMAIL PROTECTED]> * Package name: extrema Version : 4.3.0 Upstream Author : Joseph Chuma <[EMAIL PROTECTED]> * URL : http://exsitewebware.com/extrema/ * License : GPLv2 or higher Programming Lang: C++

Bug#132505: Create a successful career within our company

We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. We are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can

Re: Packages with empty directories

On Tuesday 20 November 2007 11:20:17 pm Michael Biebl wrote: > Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and > /usr/include directories (as created by dh-make) would be a good start. I wrote a lintian check implementing the conservative approach, and submitted a patch as

Re: Early adopters of symbol based dependencies needed

Raphael Hertzog wrote: > And shlibs files are ignored if dpkg-shlibdeps is able to find > symbols files. Ah, that wasn't clear, I must have missed that in the documentation. -- see shy jo signature.asc Description: Digital signature

Re: Packages with empty directories

Daniel Schepler wrote: > On Tuesday 20 November 2007 11:20:17 pm Michael Biebl wrote: >> Imho adding a lintian check for empty /usr/bin, /usr/sbin, /usr/lib and >> /usr/include directories (as created by dh-make) would be a good start. > > I wrote a lintian check implementing the conservative appr

Re: Bug#452316: Packages with empty directories

Neil Williams <[EMAIL PROTECTED]> writes: > The only problem with the patch is that /usr/lib/perl5/ is often > included just by creating a perl package. I've tried to get rid of it > but it *is* created during 'make install' by use ExtUtils::MakeMaker; > but it is not necessarily used by package f

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

On 21/11/07 at 18:03 +0100, Martin Michlmayr wrote: > * Frans Pop <[EMAIL PROTECTED]> [2007-11-21 17:47]: > > The most effective/efficient way to do this may be an archive rebuild with > > a modified gcc that emits a warning if this case is hit and then check build > > logs for the warning. > > >

Re: gcc compilation error with abs() affects sarge, etch, lenny, sid

> Today I saw a thread on the linux-kernel list [1] about a gcc compilation > issue that affects _all_ gcc versions in Debian after gcc-2.95. > I've filed bugs reports: > #452108 (gcc-4.2); #452113 (gcc-4.1); #452114 (gcc-3.3); #452115 (gcc-3.4) > > The issue is that in some cases a negative con

Re: Early adopters of symbol based dependencies needed

* Joey Hess: >> Performance penalty of PIC code due to register pressure, I guess. > > I seem to remember it was a threading issue, but I didn't manage to > track down an explanation. Well, Perl should use __thread anyway, so it's unlikely that the issue is still present. -- To UNSUBSCRIBE, em