On Sun, Nov 05, 2006 at 12:03:32AM -0800, Steve Langasek wrote: > On Sun, Nov 05, 2006 at 08:32:29AM +0100, Daniel Baumann wrote: > > Luk Claes wrote: > > > If it's only about the security bug, I don't think it's a good idea to > > > remove > > > giflib from testing at this time as the bug can easily be fixed by giflib > > > leaving the NEW queue or patching giflib 3 AFAICS. Though if you think > > > giflib > > > 3.x is not fit for release even if the security bug where fixed, then I'll > > > happily remove giflib 3.0-12 from testing :-)
> > Since giflib 3.x is not used by any package at all, This turns out to not be the case. The package 'paul' has a dependency on libungif3g (>= 3.0-2) | giflib3g (>= 3.0-5.2) on most architectures, which is only satisfiable in testing by giflib3g since libungif3g is long gone. Only i386 is linked against a different version of libungif, in defiance of the package's own build-dependencies. So paul seems to need a sourceful fix first for us to be able to remove giflib 3 from etch without affecting any other packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
