Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 08:08:17AM +, Matthew Rosewarne wrote: On Thursday 14 February 2008, Modestas Vainius wrote: Hi, As of writing, libqt3-mt ABI breakage caused serious 16 bugs (#464946 friends) to be reported by our users. So I think it's high time we took some action today or tommorow to unbreak software affected. I'm concerned about Debian unstable users even though in theory they shouldn't be using unstable if they don't known how to downgrade packages. So this mail is all about how to deal with this situation having two main criteria in mind: I've looked through all C++ packages (libsdtc++6 rdepends), and I think I have a complete list of broken pacakges. They are: digikam k3b kcontrol kdirstat kexi konq-plugins konqueror ktorrent libk3b3 libmyth-0.20.2 mythdvd mythmusic mythtv-backend pdfedit trustedqsl virtualbox-ose Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Qt _has_ to use it to build, though digikam and friends won't, so that they will _stop_ using the damn symbols. This way partial upgrades to lenny works, and in lenny+1 the symbols just disappear for good. No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Then a binNMU campaign of the broken _packages_ has to follow (digikam, k3b, ... ) so that they loose their wrong *UND* symbols for good. I think it's a fair middle ground solution. Thoughts ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQaduxHExK9.pgp Description: PGP signature
Processed: forcibly merging 465844 466026
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.13 forcemerge 465844 466026 Bug#465844: libc6: Can't upgrade from Etch Bug#466026: libc6: doesn't upgrade from etch Bug#465753: libc6: symbol _dl_out_of_memory, version GLIBC_PRIVATE not defined Forcibly Merged 465753 465844 466026. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 10:52:01AM +, Modestas Vainius wrote: Hi, 2008 m. February 16 d., Saturday, Pierre Habouzit rašė: Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Ok, so it's actually a debate whether to readd missing symbols to affected libraries themselves or to libc6-dev. If Matthew is correct, all packages except trustedqsl are victims of libqt3-mt. By the way, I'm not sure if tsql is a problem (atoi is versioned?): $ objdump -tT /usr/bin/tqsl | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -tT /usr/bin/tqslcert | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi atoi is a libc symbol, so I don't see a problem with that: $ objdump -T /lib/libc-2.7.so|grep atoi 00032530 gDF .text 0015 GLIBC_2.2.5 atoi The fact that atoi is clearly versionned should have given you a hint ;P If what you say was true, ktorrent 2.2.5.dfsg.1-1 should not depend on fstat64, because 1. ktorrent 2.2.5.dfsg.1-1 was uploaded on Wed, 06 Feb 2008 23:07:08 +0200, hence built against libc6-dev (= 2.7) without extern inlines in sys/stat.h That's essentially the same as it would be building without -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 2. qt-x11-free 3.3.7-9 was uploaded on Wed, 26 Sep 2007 21:42:24 +0200, hence built against libc6-dev ( 2.7) with extern inlines in sys/stat.h present. That's essentially the same as it would be building with -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 3. ktorrent 2.2.5.dfsg.1-1 was linked against qt-x11-free 3.3.7-9 (app, not using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK, was linked against lib, using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK). As you see, all conditions were met, but, unfortunately, ktorrent 2.2.5.dfsg.1-1 still depends on exported fstat64 I absolutely don't understand how that can be true. I mean it doesn't make sense, ktorrent gets the symbol from the libc6, and it just emits an undefined symbol because qt3 provides it at the time, there is no way it gets it another way. So I'll try to redo a proper test where I'm actually really sure of what I have during the build instead of probable speculations. No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Do you want to add hack to lib6-dev just for Qt3? I fear it's not _only_ qt3. And yes, given that there are 20+ packages affected in the end, I'm more than ready to do it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1ihFnVFxqS.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
Hi, 2008 m. February 16 d., Saturday, Pierre Habouzit rašė: Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Ok, so it's actually a debate whether to readd missing symbols to affected libraries themselves or to libc6-dev. If Matthew is correct, all packages except trustedqsl are victims of libqt3-mt. By the way, I'm not sure if tsql is a problem (atoi is versioned?): $ objdump -tT /usr/bin/tqsl | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -tT /usr/bin/tqslcert | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi Qt _has_ to use it to build, though digikam and friends won't, so that they will _stop_ using the damn symbols. This way partial upgrades to lenny works, and in lenny+1 the symbols just disappear for good. Sorry, but that's wrong. It's true that Qt gets those symbols at compile time, but any binaries linking against Qt references [fl]?stat64 from Qt at link time. Hence as long any application using [fl]?stat64 are linked against Qt3 with [fl]?stat64 exported (and that has nothing to do with headers), it will depend on [fl]?stat64 being present. If what you say was true, ktorrent 2.2.5.dfsg.1-1 should not depend on fstat64, because 1. ktorrent 2.2.5.dfsg.1-1 was uploaded on Wed, 06 Feb 2008 23:07:08 +0200, hence built against libc6-dev (= 2.7) without extern inlines in sys/stat.h That's essentially the same as it would be building without -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 2. qt-x11-free 3.3.7-9 was uploaded on Wed, 26 Sep 2007 21:42:24 +0200, hence built against libc6-dev ( 2.7) with extern inlines in sys/stat.h present. That's essentially the same as it would be building with -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 3. ktorrent 2.2.5.dfsg.1-1 was linked against qt-x11-free 3.3.7-9 (app, not using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK, was linked against lib, using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK). As you see, all conditions were met, but, unfortunately, ktorrent 2.2.5.dfsg.1-1 still depends on exported fstat64 No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Do you want to add hack to lib6-dev just for Qt3? Then a binNMU campaign of the broken _packages_ has to follow (digikam, k3b, ... ) so that they loose their wrong *UND* symbols for good. Unless libqt3-mt loses them, binNMUs won't help. P.S. However, we might want to delay libqt3-mt transition (by adding back [fl]?stat64 symbols one way or another and forgetting it) to lenny+1, because it's very likely that there will have been fewer applications using it by then. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
glibc_2.3.6.ds1-13etch5_i386.changes INSTALLED into stable
Installing: glibc-doc_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/glibc-doc_2.3.6.ds1-13etch5_all.deb glibc_2.3.6.ds1-13etch5.diff.gz to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.diff.gz glibc_2.3.6.ds1-13etch5.dsc to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.dsc libc6-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dbg_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dbg_2.3.6.ds1-13etch5_i386.deb libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dev_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev_2.3.6.ds1-13etch5_i386.deb libc6-i686_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-i686_2.3.6.ds1-13etch5_i386.deb libc6-pic_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-pic_2.3.6.ds1-13etch5_i386.deb libc6-prof_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-prof_2.3.6.ds1-13etch5_i386.deb libc6-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libc6-udeb_2.3.6.ds1-13etch5_i386.udeb libc6-xen_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-xen_2.3.6.ds1-13etch5_i386.deb libc6_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6_2.3.6.ds1-13etch5_i386.deb libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb locales-all_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/locales-all_2.3.6.ds1-13etch5_i386.deb locales_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/locales_2.3.6.ds1-13etch5_all.deb nscd_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/nscd_2.3.6.ds1-13etch5_i386.deb Override entries for your package: glibc-doc_2.3.6.ds1-13etch5_all.deb - optional doc glibc_2.3.6.ds1-13etch5.dsc - source libs libc6-amd64_2.3.6.ds1-13etch5_i386.deb - optional libs libc6-dbg_2.3.6.ds1-13etch5_i386.deb - extra libdevel libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-dev_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-i686_2.3.6.ds1-13etch5_i386.deb - extra libs libc6-pic_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-prof_2.3.6.ds1-13etch5_i386.deb - extra libdevel libc6-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer libc6-xen_2.3.6.ds1-13etch5_i386.deb - extra libs libc6_2.3.6.ds1-13etch5_i386.deb - required libs libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer locales-all_2.3.6.ds1-13etch5_i386.deb - extra libs locales_2.3.6.ds1-13etch5_all.deb - standard libs nscd_2.3.6.ds1-13etch5_i386.deb - optional admin Announcing to [EMAIL PROTECTED] Closing bugs: 460226 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 10:58:13AM +, Pierre Habouzit wrote: I absolutely don't understand how that can be true. I mean it doesn't make sense, ktorrent gets the symbol from the libc6, and it just emits an undefined symbol because qt3 provides it at the time, there is no way it gets it another way. So I'll try to redo a proper test where I'm actually really sure of what I have during the build instead of probable speculations. Okay, so for the others, here is what happens for real: * the extern inlines from sys/stat.h are just gone, and that's just normal in fact. * /usr/lib/libc.so is a linker script that pulls /lib/libc-2.7.so _and_ /usr/lib/libc_nonshared.a. * the latter defines stat64 and friends as weak-symbols and alises to __xstat64 and friends. That's how when you link something that uses fstat64 it finds the symbol at link time, letting you the possibility to override it with your own implementation. The fact that the extern inlines were used at some point in the past _was_ a bug, and let qt3 divert those, which should have not happened in the first place. Sadly, when you link against qt3, it picks those symbols because it will always prefer symbols from a shared lib than from the .a IIRC, or it's due to the link order, anyways, it's not relevant. So with this new information, I'd say that the safest way is to re-add manually (I heard Modestas has a patch for that) the symbols to qt3. It's not pretty, but qt3 will disappear eventually, and it's not a problem to hack it that way, whereas reenabling the patch in the libc will concern more and more symbols with time, and has good chances to become an issue. I'm still not in favor of it. We should still look in the archive if other libraries have the symbols and deal on a per case basis. It seems c++ libraries are the one affected, C ones usually arent as extern inline has a different meaning in C (especially in GNU C 89). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgps4B2iXl9Mo.pgp Description: PGP signature
Bug#460226: marked as done (Memory leak in SUNRPC code)
Your message dated Sat, 16 Feb 2008 12:17:07 + with message-id [EMAIL PROTECTED] and subject line Bug#460226: fixed in glibc 2.3.6.ds1-13etch5 has caused the Debian Bug report #460226, regarding Memory leak in SUNRPC code to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 460226: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460226 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: libc6 Version: 2.3.6.ds1-13etch2 Severity: serious Tags: patch I've already submitted a patch upstream and it has been integrated. http://sourceware.org/bugzilla/show_bug.cgi?id=5541 It should be backported to Etch. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii tzdata2007b-1Time Zone and Daylight Saving Time libc6 recommends no packages. -- debconf-show failed ---End Message--- ---BeginMessage--- Source: glibc Source-Version: 2.3.6.ds1-13etch5 We believe that the bug you reported is fixed in the latest version of glibc, which is due to be installed in the Debian FTP archive: glibc-doc_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/glibc-doc_2.3.6.ds1-13etch5_all.deb glibc_2.3.6.ds1-13etch5.diff.gz to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.diff.gz glibc_2.3.6.ds1-13etch5.dsc to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.dsc libc6-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dbg_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dbg_2.3.6.ds1-13etch5_i386.deb libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dev_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev_2.3.6.ds1-13etch5_i386.deb libc6-i686_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-i686_2.3.6.ds1-13etch5_i386.deb libc6-pic_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-pic_2.3.6.ds1-13etch5_i386.deb libc6-prof_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-prof_2.3.6.ds1-13etch5_i386.deb libc6-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libc6-udeb_2.3.6.ds1-13etch5_i386.udeb libc6-xen_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-xen_2.3.6.ds1-13etch5_i386.deb libc6_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6_2.3.6.ds1-13etch5_i386.deb libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb locales-all_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/locales-all_2.3.6.ds1-13etch5_i386.deb locales_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/locales_2.3.6.ds1-13etch5_all.deb nscd_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/nscd_2.3.6.ds1-13etch5_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Aurelien Jarno [EMAIL PROTECTED] (supplier of updated glibc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 12 Jan 2008 16:06:00 +0100 Source: glibc Binary: libc0.1-prof libc6-dev-amd64 locales-all libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc0.3 libc0.1-i686 libc0.1-i386 libc6.1-dev libc6-s390x libnss-files-udeb libc0.1-dev-i386 libc6-dev-sparc64 libc6-i386 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc0.1-udeb libc6-dev-i386 libc6.1-prof libc0.1-dev locales libc6-pic libc0.3-udeb libc6-dev-powerpc libc0.1-pic libc6-ppc64 libc0.3-dbg libc0.1-dbg libc6-amd64 libc0.1 libc6-prof libc6-xen libc6-powerpc libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc6-dev-s390x Architecture: source i386 all Version: 2.3.6.ds1-13etch5 Distribution: stable Urgency: low Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: glibc-doc - GNU C Library: Documentation libc6 - GNU
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 01:22:31PM +, Pierre Habouzit wrote: We should still look in the archive if other libraries have the symbols and deal on a per case basis. It seems c++ libraries are the one affected, C ones usually arent as extern inline has a different meaning in C (especially in GNU C 89). okay and to finish to nail the problem down: 18:16 MoDaX | libqt-mt is not built with -O2!! 18:16 mukidohime | Sweet zombie jesus! 18:16 mukidohime | Whose idea was that? 18:16 MoDaX | that's why it exposes stat64 and friends 18:17 MoDaX | libs built with -O2 does not 18:17 MoDaX | do not* 18:17 mukidohime | So *that's* why only Qt was affected... Which means that now I'm not only in favour to manually add the symbols to Qt3, but in fact it's also The Right Thing to do, Qt people, please sort out _your_ mess :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmsooRbBtCq.pgp Description: PGP signature
