-Wl,--as-needed considered possibly harmful

[Simon Richter]

Hi,

due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.

THIS IS NOT A GOOD IDEA.

You are essentially telling gcc to pass an option to the linker without
understanding what it does, and, more specifically, an option that tells
the linker to second-guess the gcc compiler driver. This can introduce
really interesting and subtle bugs that will be difficult to find.

If there are broken scripts adding too many libraries then it is time to
fix those scripts, not employ an evil hack that makes the symptoms go away.

   Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#454162: libxine1-plugins: should not depend on libxine1-gnome

[Reinhard Tartler]

Philippe Cloutier <[EMAIL PROTECTED]> writes:

>>
>> This bug is now about that all plugins are installed by default,
>> dragging in too many dependencies at install/upgrade time. I have the
>> following compromise in mind, which I first want to be commented on
>> before I do the follwing changes:
>>
>> a) Let's introduce 2 meta packages: libxine1-all-plugins, which depends on
>> all binary packages including libxine1-gnome, and another one
>> libxine1-common-plugins, which depends on all packages except
>> libxine1-gnome.
>>
> I'm not sure about a) ; how would these meta packages be used?

Like this:

Package: libxine1
Architecture: i386
Source: xine-lib
Version: 1.1.8-4
Depends: libc6 (>= 2.6.1-1), libxine1-bin (= 1.1.8-4), libfreetype6 (>= 2.3.5), 
libxine1-common-plugins (= 1.1.8-4) | libxine1-misc-plugins (= 1.1.8-4), zlib1g 
(>= 1:1.2.3.3.dfsg-1)
Recommends: libxine1-doc | libxine-doc, libxine1-ffmpeg
Suggests: gxine, xine-ui
Description: the xine video/media player library, binary files
 This is the xine media player library (libxine).
 ...

libxine1-common-plugins would depend on libxine1-x and libxine1-mpeg.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Zack Weinberg]

> due to the recent dpkg-shlibdeps changes, people have started adding
> -Wl,--as-needed into their LDFLAGS.
>
> THIS IS NOT A GOOD IDEA.
>
> You are essentially telling gcc to pass an option to the linker without
> understanding what it does, and, more specifically, an option that tells
> the linker to second-guess the gcc compiler driver. This can introduce
> really interesting and subtle bugs that will be difficult to find.

To first order, the only scenario I am aware of in which it can cause
problems is if someone uses a global variable with a C++ constructor
in a shared library, that constructor does critical work for the
application the library is linked into, and the application does not
reference any symbols whatsoever from the shared library.  This is not
impossible, but it is so unlikely IMO that the possibliity can be
neglected.

I have in the past argued for --as-needed to be made the default in
upstream binutils; that's how safe I think it is.  (Upstream
maintainers, conscious of the above and other (isomorphic) corner
cases, wanted a distribution to try it on a large scale first.  Thus I
am very happy to see Debian experimenting with it.)

I'm curious what prompted your message.  Did a program you use
actually break?  What was the failure mode?

> If there are broken scripts adding too many libraries then it is time to
> fix those scripts, not employ an evil hack that makes the symptoms go away.

There are a *lot* of broken scripts.  Would you like to mass-file bugs
on every package that contains a binary that links to libnsl? (this
iscommon, thanks to a buggy example in the autoconf manual, but
completely unnecessary under glibc for anything other than a small
handful of NIS-related programs, which probably have their own copies
of that code anyway)  How about programs that link to libm, but every
symbol they use from libm happens to have been replaced by inline
code?  (I have seen this happen in real life.)  Libraries that are
linked against libpthread as a defensive measure for actual use of
threads by their users, but only need the stubs in libc for that?
(Can causes severe performance hits for single-threaded users of that
library.)

zw


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Syslog file paths in 'metalog'? (#423299)

[Christoph Haas]

On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote:
> Christoph Haas wrote:
>> At work we are using syslog-ng a lot and it's very useful for a central
>> logging server. However I don't like the syntax because it's verbose and
>> typo-prone. So I was looking at metalog and seeing it orphaned I decided
>> to adopt it (#423299). I've started bringing the package into good shape
>> again. There is just an issue with the paths and files where metalog
>> writes syslog informaton to. The difference to the sysklogd...
>>
>> sysklogd:
>> /var/log/mail.log
>> /var/log/mail.log.0
>> /var/log/mail.log.1.gz
>> /var/log/mail.log.2.gz
>
> Mmmh.  Strictly speaking, sysklogd logs mail to /var/log/mail.log, along 
> with duplicating (!!) much of the content to (IIRC) /var/log/messages and 
> /var/log/mail.{err,info,warn}. .0, .1.gz, etc are created by the 
> non-logrotate widget Debian uses for rotating system logs.
>
> In general, I would say as a sysadmin that any syslog daemon that does not 
> allow me to configure any given log facility and priority to (at least!) an 
> arbitrary file wherever I want it is inherently broken.

I think I agree to that. Thus I will request the removal of the package
until metalog will one day be more configurable and allow to mimic other
syslog daemons' file schemes.

Thanks you all for your feedback.

Cheers
 Christoph
-- 
[EMAIL PROTECTED]  www.workaround.org   JID: [EMAIL PROTECTED]
gpg key: 79CC6586 fingerprint: 9B26F48E6F2B0A3F7E33E6B7095E77C579CC6586


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Romain Beauxis]

Le Sunday 09 December 2007 09:56:39 Zack Weinberg, vous avez écrit :
> I'm curious what prompted your message.  Did a program you use
> actually break?  What was the failure mode?

Yes, I agree too.

I've been using this flag recently, and in most cases it just does what's 
required...


I think that before warning in capital letters it would be good to study and 
advertise the case when it's potentially harmfull..

There's a good reference there:
  http://www.gentoo.org/proj/en/qa/asneeded.xml


Romain

Re: Injecting versions of build-deps in the deps

[Raphael Hertzog]

On Fri, 07 Dec 2007, Loïc Minier wrote:
> On Fri, Dec 07, 2007, Raphael Hertzog wrote:
> > libgtk-x11-2.0.so.0 libgtk2.0-0 #MINVER#
> > * Devel-Package: libgtk2.0-dev
> >  [EMAIL PROTECTED] 2.8.0
> >  ...
> > How does that sound ?
> 
>  Sounds like a good start!  Perhaps the injection should be explicitely
>  requested with:
>   * UseBuildDepVersionAsMinVer: yes
>  or the field could be named to reflect that it's used for bdeps:
>   Build-Depends-Package: libgtk2.0-dev

Yeah, I settled on "Build-Depends-Package". I implemented this. You can
test with this package:
http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.13_all.deb

I'd like some more feedback that this is considered a good idea before I
push this on dpkg's git repo. But otherwise it seems to work quite well
here.

>So it only leaves dealing with multiple bdeps: I suppose they could
>  all be copied over and will generate the same warning that the
>  duplicate build-dep.

It will just take the biggest minimal version required.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Josselin Mouette]

Le dimanche 09 décembre 2007 à 09:03 +0100, Simon Richter a écrit :
> Hi,
> 
> due to the recent dpkg-shlibdeps changes, people have started adding
> -Wl,--as-needed into their LDFLAGS.
> 
> THIS IS NOT A GOOD IDEA.

Of course it is. This is the most reliable way of dropping unneeded
dependencies. All other ways will keep some of them.

If there are bugs in --as-needed, we need to fix them. It is much easier
than fixing thousands of packages. Or are you willing to drop
dh_fixperms and fix thousands of broken packages by hand as well?

> If there are broken scripts adding too many libraries then it is time to
> fix those scripts, not employ an evil hack that makes the symptoms go away.

Some of these scripts cannot be “fixed”. And for others, well, good luck
in getting libtool’s upstream to integrate the required changes. Maybe
they will be here in 5 years, and in 15 years all upstreams will have
migrated to a recent enough version.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: -Wl,--as-needed considered possibly harmful

[Bernhard R. Link]

* Josselin Mouette <[EMAIL PROTECTED]> [071209 18:48]:
> > due to the recent dpkg-shlibdeps changes, people have started adding
> > -Wl,--as-needed into their LDFLAGS.
> > 
> > THIS IS NOT A GOOD IDEA.
> 
> > If there are broken scripts adding too many libraries then it is time to
> > fix those scripts, not employ an evil hack that makes the symptoms go away.
> 
> Some of these scripts cannot be ???fixed???. And for others, well, good luck
> in getting libtool???s upstream to integrate the required changes. Maybe
> they will be here in 5 years, and in 15 years all upstreams will have
> migrated to a recent enough version.

Just curing the symptoms instead of the problems will not help to get
there any sooner. There might be stuff where the stuff at hand is not
easily fixed, but that is no reason to not consider it not worth doing.
(or to consider using -Wl,--as-needed as anything short of giving in
to a broken build system and putting the dirt under the carpet, so
people do no longer get dirty feet walking around most of the time).

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Josselin Mouette]

Hi,

Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> Just curing the symptoms instead of the problems will not help to get
> there any sooner.

What if there is no problem?

For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this is perfectly intentional. The former is
here because you can assume glib functions are available when doing
"#include ". The latter is here because some macros need math
functions. Still, many binaries using it don’t need glib, and most of
them don’t need libm. There is nothing that can be done to avoid that,
the only way is a check that removes the dependency if it isn’t actually
needed.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Key signing party in Lille 9-10 dec ?

[Vincent Danjean]

  Hi,

  In Lille (France) there is a meeting organized  by the INRIA (40 years of
this French institute of computer science). I just realized there should be
other (future?) DD or DM here, so we can try to organized a key signing
party.

  Best regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 [EMAIL PROTECTED]
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Michael Banck]

On Sat, Dec 08, 2007 at 11:28:27AM +0100, Frans Pop wrote:
> Frans Pop wrote:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=partman-lvm;dist=unstable
> hurd 11 uploads behind; 7 out of 20 bugs long solved
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=base-installer;dist=unstable
> hurd 31 uploads behind, 7 out of 33 bugs long solved
> 
> And note that that is not because we upload new versions every day.
> partman-lvm: last version built for hurd: 45; uploaded: 2006-07-19 (1.5 
> years!)
> base-installer: last version built for hurd: 1.57; uploaded: 2006-05-14

D'oh, that's a known bug in dak which does not generate Packages.gz for
d-i/hurd-i386 [1]; I've been told it's low priority.  I suggest you prod the
ftp-masters to get this fixed.

base-installer is uptodate on hurd-i386, partman-lvm is Arch: all
AFAICT?


cheers,

Michael

[1] e.g. http://ftp.de.debian.org/debian/dists/unstable/main/debian-installer/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Michael Banck]

On Fri, Dec 07, 2007 at 07:14:31PM -0800, Don Armstrong wrote:
> [There is some argument that I should completely ignore hurd-i386 by
> default since it isn't keeping up *at all* but I haven't made that
> change yet.]

Well, feel free to ignore hurd-i386 for that.

I'm not going to argue about how good it is keeping up.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Kurt Roeckx]

On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
> Hi,
> 
> Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> > Just curing the symptoms instead of the problems will not help to get
> > there any sooner.
> 
> What if there is no problem?
> 
> For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
> -lglib-2.0 and -lm. And this is perfectly intentional. The former is
> here because you can assume glib functions are available when doing
> "#include ". The latter is here because some macros need math
> functions. Still, many binaries using it don't need glib, and most of
> them don't need libm. There is nothing that can be done to avoid that,
> the only way is a check that removes the dependency if it isn't actually
> needed.

I can't seem to find any example of a macro calling a math functions?
I also can't find any header that includes .  I do see
that libgtk-x11-2.0.so uses symbols from libm, like log10, atan2, sin,
cos, tan, pow, ceil.  But I can't find anything in the header files
that would use them.

It's gdk-pixbuf-2.0.pc and cairo.pc that have -lm in them.

Anyway, I think it is bad style to use macro's in public header
files that call functions from another library.  It's also easy
to replace them with real functions.  If there are such functions
being called I suggest you replace them.

What might be harder is avoiding the includes from other libraries
because you use types from the other library.  It would be great
if you didn't have to do that, and there are some ways to avoid that.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the MIA team

[Michael Banck]

On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
> I don't agree with this. In a team, it's difficult to notice that one
> member disappeared. And lack of involvement in one package doesn't mean
> being completely MIA. As co-maintainer I wouldn't want to remove someone
> if I'm not sure that he won't come back.

Fair enough, but filing an RC bug still looks out of place to me.  


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Romain Beauxis]

Le Sunday 09 December 2007 20:03:27 Kurt Roeckx, vous avez écrit :
> Anyway, I think it is bad style to use macro's in public header
> files that call functions from another library.  It's also easy
> to replace them with real functions.  If there are such functions
> being called I suggest you replace them.
>
> What might be harder is avoiding the includes from other libraries
> because you use types from the other library.  It would be great
> if you didn't have to do that, and there are some ways to avoid that.

Ok, let's consider another very simple case:
libshout allows to perform streaming of speex, vorbis, and theora formats.

Hence, when asking for the libs to link with, you got -lspeex and -ltheora 
since it's needed to cover all build cases.

However, most of the applications don't need to link against theora and speex.

So, not only do I agree with Josselin, but I think that looking at each 
project to fullfill any possible use case IS the problem itself. we can't 
expect any upstream to commit and release every little hack that might solve 
this or that issue.

The solution is, indeed, to link what's needed for each application and 
nothing else.


Romain

Re: old bugs are still shown on the bugs page

[Frans Pop]

Michael Banck wrote:
> > And note that that is not because we upload new versions every day.
> > partman-lvm: last version built for hurd: 45; uploaded: 2006-07-19 (1.5
> > years!) base-installer: last version built for hurd: 1.57; uploaded:
> > 2006-05-14
>
> D'oh, that's a known bug in dak which does not generate Packages.gz for
> d-i/hurd-i386 [1]; I've been told it's low priority.  I suggest you prod
> the ftp-masters to get this fixed.

I suggest that is the porter's job. I'd say it's the porters who are
responsible for getting a new arch properly supported.
At least you now have a good argument why it should _not_ be low priority.

> base-installer is uptodate on hurd-i386,

That's not what the buildd pages tell me [1]:
hurd-i386  1.86  Needs-Build (1122)  23d 10:34  unknown:out-of-date  
debian-installer  no log

Or is this another example of incomplete support of hurd-i386?

> partman-lvm is Arch: all AFAICT?

Yes.

[1] http://buildd.debian.org/~jeroen/status/package.php?p=base-installer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Michael Banck]

On Sun, Dec 09, 2007 at 08:06:58PM +0100, Frans Pop wrote:
> Michael Banck wrote:
> > > And note that that is not because we upload new versions every day.
> > > partman-lvm: last version built for hurd: 45; uploaded: 2006-07-19 (1.5
> > > years!) base-installer: last version built for hurd: 1.57; uploaded:
> > > 2006-05-14
> >
> > D'oh, that's a known bug in dak which does not generate Packages.gz for
> > d-i/hurd-i386 [1]; I've been told it's low priority.  I suggest you prod
> > the ftp-masters to get this fixed.
> 
> I suggest that is the porter's job. 

I reported it, yes.

> > base-installer is uptodate on hurd-i386,
> 
> That's not what the buildd pages tell me [1]:
> hurd-i386  1.86  Needs-Build (1122)  23d 10:34  unknown:out-of-date  
> debian-installer  no log
> 
> Or is this another example of incomplete support of hurd-i386?

Yes, the wanna-build admins decided to drop hurd-i386 from
buildd.debian.org a couple of years ago.  Use
http://buildd.debian-ports.org/ for that.


Michael

-- 
 my first day at work, I installed sid and beryl
 the techs that work under me think I'm a linux guru
 they were all trying to show me vista and windowblinds and shit
 I just loaded up beryl and they all shut up


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Frans Pop]

Michael Banck wrote:
> On Sun, Dec 09, 2007 at 08:06:58PM +0100, Frans Pop wrote:
> > Michael Banck wrote:
> > > D'oh, that's a known bug in dak which does not generate Packages.gz
> > > for d-i/hurd-i386 [1]; I've been told it's low priority.  I suggest
> > > you prod the ftp-masters to get this fixed.
> >
> > I suggest that is the porter's job.
>
> I reported it, yes.

I'll interpret that as "I've reported it again today". Thanks.

And maybe the ftp-masters will also just pick up on this thread. I hope
they'll agree that having completely wrong info on BTS pages is enough
reason to fix this. It really is a very annoying inconvenience for the
D-I team that old bugs don't disappear like they should.

> > > base-installer is uptodate on hurd-i386,
> >
> > That's not what the buildd pages tell me [1]:
> > hurd-i386  1.86  Needs-Build (1122)  23d 10:34  unknown:out-of-date 
> > debian-installer  no log
> >
> > Or is this another example of incomplete support of hurd-i386?
>
> Yes, the wanna-build admins decided to drop hurd-i386 from
> buildd.debian.org a couple of years ago.  Use
> http://buildd.debian-ports.org/ for that.

Hmmm. Let's CC Jeroen on this. The stale info there is the main reason why
I concluded that the BTS problem was due to hurd-i386 not keeping up. My
apologies for drawing the wrong conclusion.

Jeroen:
Apparently the info for hurd-i386 is completely stale as that arch was
removed from wanna-build. This results in incorrect info like [1].
Could you perhaps filter out hurd-i386 so at least others are not confused
like I was? Or maybe you know a better solution.

Cheers,
FJP

[1] http://buildd.debian.org/~jeroen/status/package.php?p=base-installer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Don Armstrong]

On Sun, 09 Dec 2007, Michael Banck wrote:
> D'oh, that's a known bug in dak which does not generate Packages.gz
> for d-i/hurd-i386 [1]; I've been told it's low priority. I suggest
> you prod the ftp-masters to get this fixed.
> 
> base-installer is uptodate on hurd-i386, partman-lvm is Arch: all
> AFAICT?

Right, which is why I was kind of suprised that it was out of date
according to the Packages.gz that I have available to debbugs.
[Anyway, hopefully whatever is causing this will be resolved.]


Don Armstrong

-- 
Some pirates achieved immortality by great deeds of cruelty or
derring-do. Some achieved immortality by amassing great wealth. But
the captain had long ago decided that he would, on the whole, prefer
to achieve immortality by not dying.
 -- Terry Pratchet _The Color of Magic_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Don Armstrong]

On Sat, 08 Dec 2007, Frans Pop wrote:
> Don Armstrong wrote:
> > [There is some argument that I should completely ignore hurd-i386 by
> > default since it isn't keeping up *at all* but I haven't made that
> > change yet.]
> 
> It's been anoying for a long time and there is absolutely no
> improvement.

[...]

> I think I have requested this before. Can we now just do it, pretty
> please?

I've modified the code to now have an explicit default list of
architectures instead of assuming that all architectures are keeping
up [and made the version display more verbose for things that matter.]

That said, whoever is responsible for hurd these days should really
get it caught up.


Don Armstrong

-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Russ Allbery]

Romain Beauxis <[EMAIL PROTECTED]> writes:

> Ok, let's consider another very simple case:
> libshout allows to perform streaming of speex, vorbis, and theora formats.
>
> Hence, when asking for the libs to link with, you got -lspeex and -ltheora 
> since it's needed to cover all build cases.

Why?  Aren't you calling a function in libshout to stream such files?
libshout should then link against libseepx and libtheora, but why should
the *application* have to do so if it's using libshout?

This sounds broken to me.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: old bugs are still shown on the bugs page

[Frans Pop]

Don Armstrong wrote:
> I've modified the code to now have an explicit default list of
> architectures instead of assuming that all architectures are keeping
> up [and made the version display more verbose for things that matter.]

Thanks a lot Don. The bugs have now moved down to "Resolved". Looks much
better.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Bill Allombert]

On Wed, Dec 05, 2007 at 11:10:29AM +0100, Andreas Tille wrote:
> On Wed, 5 Dec 2007, Bill Allombert wrote:
> 
> >Actually this is not true: You can just add
> >!C menu-1
> >to the start of each files (or each menu-1 files if you prefer)
> >before concatening them.
> >Menu change format each time it see a !C request, even inside a file.
> 
> OK, this hint (is it documented somewhere?) would probably help

Not yet, though you are welcome to provide a patch for the menu
manual.

> to fix cdd-common easily.  But my question regarding the general
> menu strategy obviousely remains.

My strategy is simply to let developers experiment with the menu-2
format.  If at one point we decide that menu-1 is too ugly to be kept,
we could deprecate it, but we are not there yet.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Nikita V. Youshchenko]

> Ok, let's consider another very simple case:
> libshout allows to perform streaming of speex, vorbis, and theora formats.
> 
> Hence, when asking for the libs to link with, you got -lspeex and -ltheora
> since it's needed to cover all build cases.
> 
> However, most of the applications don't need to link against theora and
> speex.

Doesn't libshout reference symbols from libspeex and libtheora?

If it does, resulting binary must be linked against both these libraries.
Unresolved symbols within binaries are really bad, because they will once
be unexpectedly called (e.g. in some init or deinit or error-handling), and
binary will crash, leaving user data unsaved.

If it does not, then what for -lspeex and -ltheora are in the script output?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Kurt Roeckx]

On Mon, Dec 10, 2007 at 12:45:46AM +0300, Nikita V. Youshchenko wrote:
> > Ok, let's consider another very simple case:
> > libshout allows to perform streaming of speex, vorbis, and theora formats.
> > 
> > Hence, when asking for the libs to link with, you got -lspeex and -ltheora
> > since it's needed to cover all build cases.
> > 
> > However, most of the applications don't need to link against theora and
> > speex.
> 
> Doesn't libshout reference symbols from libspeex and libtheora?
> 
> If it does, resulting binary must be linked against both these libraries.

Where "binary" means libshout, yes.  The application does not
directly use libspeex and libtheora so should not have any undefined
symbols that are defined in either libspeex or libtheora.

> Unresolved symbols within binaries are really bad, because they will once
> be unexpectedly called (e.g. in some init or deinit or error-handling), and
> binary will crash, leaving user data unsaved.
> 
> If it does not, then what for -lspeex and -ltheora are in the script output?

That is only useful for linking to a static version of libshout.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Romain Beauxis]

Le Sunday 09 December 2007 22:45:46 Nikita V. Youshchenko, vous avez écrit :
> > However, most of the applications don't need to link against theora and
> > speex.
>
> Doesn't libshout reference symbols from libspeex and libtheora?

Yes

> If it does, resulting binary must be linked against both these libraries.
> Unresolved symbols within binaries are really bad, because they will once
> be unexpectedly called (e.g. in some init or deinit or error-handling), and
> binary will crash, leaving user data unsaved.

I think you are confusing the issue.

Yes, libshout uses symbols from libspeex:
objdump -x /usr/lib/libshout.so | grep NEEDED | grep speex
  NEEDED  libspeex.so.1

However, not all applications uses those symbols in their current code, so 
they do not need to be linked against speex themselves.


Of course, correct dependencies will be pulled when requesting libshout.


Romain

Re: Bits from the MIA team

[Luk Claes]

Michael Banck wrote:
> On Sat, Dec 08, 2007 at 06:39:15PM +0100, Raphael Hertzog wrote:
>> I don't agree with this. In a team, it's difficult to notice that one
>> member disappeared. And lack of involvement in one package doesn't mean
>> being completely MIA. As co-maintainer I wouldn't want to remove someone
>> if I'm not sure that he won't come back.
> 
> Fair enough, but filing an RC bug still looks out of place to me.  

Please don't answer when you don't have read the whole thread... It was
already very clearly mentioned that the team decided to file with
severity important instead...

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Syslog file paths in 'metalog'? (#423299)

[Milan P. Stanic]

On Sun, Dec 09, 2007 at 01:42:02PM +0100, Christoph Haas wrote:
> On Thu, Dec 06, 2007 at 01:11:32PM -0500, Kris Deugau wrote:
> > Mmmh.  Strictly speaking, sysklogd logs mail to /var/log/mail.log, along 
> > with duplicating (!!) much of the content to (IIRC) /var/log/messages and 
> > /var/log/mail.{err,info,warn}. .0, .1.gz, etc are created by the 
> > non-logrotate widget Debian uses for rotating system logs.
> >
> > In general, I would say as a sysadmin that any syslog daemon that does not 
> > allow me to configure any given log facility and priority to (at least!) an 
> > arbitrary file wherever I want it is inherently broken.

What do you mean by "configure any given log facility and priority to an
arbitrary file"?

Metalog can be configured to log given log facility and priority to an
arbitrary directory, but (yes) not to file.

> I think I agree to that. Thus I will request the removal of the package
> until metalog will one day be more configurable and allow to mimic other
> syslog daemons' file schemes.

I'm using metalog on some of the servers so I would like it to remain in
Debian. I can maintain it if someone want to sponsor me.

Best regards


signature.asc
Description: Digital signature

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:

> Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
> > Just curing the symptoms instead of the problems will not help to get
> > there any sooner.

> What if there is no problem?

> For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
> -lglib-2.0 and -lm. And this is perfectly intentional.

Just because it's intentional doesn't mean it isn't absurd and wrong.

> The former is here because you can assume glib functions are available
> when doing "#include ". The latter is here because some macros
> need math functions. Still, many binaries using it don’t need glib, and
> most of them don’t need libm. There is nothing that can be done to avoid
> that, the only way is a check that removes the dependency if it isn’t
> actually needed.

No, what can be done is to fix upstream's broken declaration that 'you can
assume glib functions are available when doing "#include "'.  It
doesn't follow that just because this works in practice, it should be a
supported usage.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Sun, Dec 09, 2007 at 11:31:19PM +0100, Romain Beauxis wrote:
> Le Sunday 09 December 2007 22:45:46 Nikita V. Youshchenko, vous avez écrit :
> > > However, most of the applications don't need to link against theora and
> > > speex.

> > Doesn't libshout reference symbols from libspeex and libtheora?

> Yes

> > If it does, resulting binary must be linked against both these libraries.
> > Unresolved symbols within binaries are really bad, because they will once
> > be unexpectedly called (e.g. in some init or deinit or error-handling), and
> > binary will crash, leaving user data unsaved.

> I think you are confusing the issue.

> Yes, libshout uses symbols from libspeex:
> objdump -x /usr/lib/libshout.so | grep NEEDED | grep speex
>   NEEDED  libspeex.so.1

> However, not all applications uses those symbols in their current code, so 
> they do not need to be linked against speex themselves.

And therefore, the scripts generating dependency information for dynamically
linking to libshout should *not* list libspeex or libtheora, and
consequently there's no need for -Wl,--as-needed.  (When statically linking,
-Wl,--as-needed is also irrelevant, because unused symbols from static libs
are already discarded.)

> Of course, correct dependencies will be pulled when requesting libshout.

No, currently the dependencies pulled in are overbroad.  Please fix
/usr/lib/pkgconfig/shout.pc to list the dependent libraries in
"Requires.private", not in "Requires".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the MIA team

[Michael Banck]

On Sun, Dec 09, 2007 at 11:31:27PM +0100, Luk Claes wrote:
> Please don't answer when you don't have read the whole thread... It was
> already very clearly mentioned that the team decided to file with
> severity important instead...

Please don't CC me on replies, I am subscribed.


cheers,

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Steve Langasek]

On Sun, Dec 09, 2007 at 03:47:52PM -0800, Steve Langasek wrote:
> > However, not all applications uses those symbols in their current code, so 
> > they do not need to be linked against speex themselves.

> And therefore, the scripts generating dependency information for dynamically
> linking to libshout should *not* list libspeex or libtheora, and
> consequently there's no need for -Wl,--as-needed.  (When statically linking,
> -Wl,--as-needed is also irrelevant, because unused symbols from static libs
> are already discarded.)

> > Of course, correct dependencies will be pulled when requesting libshout.

> No, currently the dependencies pulled in are overbroad.  Please fix
> /usr/lib/pkgconfig/shout.pc to list the dependent libraries in
> "Requires.private", not in "Requires".

... also, -Wl,--as-needed is *not* a complete solution for the problems
caused by generating extra -l arguments.  Every -lfoo option passed to the
linker requires the corresponding -dev package to be installed at build
time; while it is a bug if the -dev packages don't declare their
dependencies, the impact of such bugs (which do happen fairly often) would
be limited to static linking if appropriately-constructed .pc files were
available.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

libgpg-error0 and libgcrypt11: static linking or move from /usr/lib to /lib?

[Jonas Meurer]

Hey,

in the cryptsetup package we currently link statically against libgcrypt11
and libgpg-error0. cryptdisks is run before mountall.sh, thus we cannot
depend on libraries which are are located in /usr/lib. in many systems
/usr is a seperate partition.

static linking has been a good solution in the past, but from a security
point of view it should be avoided.

if libgcrypt11 and libgpg-error0 libraries would be moved from /usr/lib
to /lib, dynamical linking would be an option. that's how it seems to be
done in ubuntu:

https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/139635

what do you think? should we ask libgcrypt11 and ligpg-error0 maintainers
to move the libraries to /lib, or is it better to stay with static linked 
libraries?

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: -Wl,--as-needed considered possibly harmful

[Felipe Sateler]

Steve Langasek wrote:

> ... also, -Wl,--as-needed is *not* a complete solution for the problems
> caused by generating extra -l arguments.  Every -lfoo option passed to the
> linker requires the corresponding -dev package to be installed at build
> time; while it is a bug if the -dev packages don't declare their
> dependencies, the impact of such bugs (which do happen fairly often) would
> be limited to static linking if appropriately-constructed .pc files were
> available.

Note that pkgconfig is not the only problem here. Some extra links arise
from the fact that several utilities or plugins for an application are
built with the same "environment" (ie: the same flags), and not all of them
require all the linked libraries. Of course, one could argue that fixing
the build script is the way to go, but sometimes it is not trivial to do
that (badly crafted or unmaintained build scripts tend to be quite ugly).


-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is menu orphaned? (Was: Debian Menu transition status)

[Andreas Tille]

On Sun, 9 Dec 2007, Bill Allombert wrote:


OK, this hint (is it documented somewhere?) would probably help


Not yet, though you are welcome to provide a patch for the menu
manual.


As ususal.  I hope there are not even more hidden/undocumented
features which are waiting for patches in the docs.


My strategy is simply to let developers experiment with the menu-2
format.  If at one point we decide that menu-1 is too ugly to be kept,
we could deprecate it, but we are not there yet.


And we will never come to this point if there is no clear guideline.
The strategy that menu-2 was basically ignored by developers for eight
years would lead me to the conclusion that the experiment failed.
Why should I change something for no profit at all - at least up
to now nobody was able to epxlain any advantage of menu-2 over menu-1.
Why should any developer change a running system for no profit at
all.  So finishing the experiment and droping some unused stuff (well
I understand that it is used in menu methods but you also did not really
explained why this might be superior) would sound reasonable to me.

Bill, I'm afraid you might ignore the fact that there are many developers
who consider menu outdated and more or less just add menu files to just
avoid a lintian warning about a missing menu file.  There are enough
developers that would be in favour of freedesktop.org menus as I wrote
before.  I do not think so and even if I'm lacking the time to actively
work on menu I'm in favour of this because it works with all UIs in
Debian.

If you will not manage to form a _group_ that _actively_ develops
menu and sets clear and reasonable guidelines for developers that
should be applied to their packages the menu system in Debian will
not be able to compete with alternatives in the future (which
would be really sad).

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is menu orphaned?

[Russ Allbery]

Andreas Tille <[EMAIL PROTECTED]> writes:

> Bill, I'm afraid you might ignore the fact that there are many
> developers who consider menu outdated and more or less just add menu
> files to just avoid a lintian warning about a missing menu file.

Hm, which lintian warning is that?  There was a wishlist bug for such a
thing, but I don't think any warning was ever committed.

> There are enough developers that would be in favour of freedesktop.org
> menus as I wrote before.

At least the Debian menu system has a documented format and standard that
everyone follows, unlike freedesktop.org where KDE, Gnome, and GNUstep
implement three subtlely different things, none of the differences are
adequately documented, and writing lintian checks for the whole thing
without stumbling over yet another strange system-specific divergence has
proven quite difficult.

> I do not think so and even if I'm lacking the time to actively work on
> menu I'm in favour of this because it works with all UIs in Debian.

Well, having had the *.desktop files in Debian thrust upon me during my
well-meaning but rather frustrating effort to merge a contributed patch to
check them with lintian, I'm surprised you all manage to put together a
coherent menu structure using them.  I like the three different spellings
of ActionGame, for example, and the widespread use of categories that
aren't in the menu category standard at all (like Application).

*.desktop files are certainly a richer format and likely have more
long-term potential given that someone is at least trying to make them a
cross-environment and cross-distribution standard, but they're rather
frustrating to deal with just at the moment.  Hopefully this is improving.
It would be lovely if some of the people who think that *.desktop files
are great could work with freedesktop.org to get the standard updated to
reflect reality, thus allowing people to write code against it.  It's not
helpful, for example, for KDE to support an Actions keyword that isn't
documented anywhere in the standard, even though the standard has a whole
section specifically for KDE-only keywords.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]