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 pgpx5j0AsiUbC.pgp Description: PGP signature
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 pgp0m4thtr5EK.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.
gfortran release goal?
Hi, As noted by the latest gfortran transition update[1] by Kumar Appaiah, the transition is now in full swing. The complex packages lower in dependency chain have been uploaded to unstable, and for the rest of packages bugs/patches have been filed. Our main problem remains unresponsive maintainers. We suggest promoting gfortran transition to a official release goal, so we can start more aggresively NMU'ing packages. As for the entry for Lenny release goal list[2]: * gfortran transition Advocate: Riku Voipio and Mathias Klose Description: All packages Bug-Tag: gfortran State: xxx Currently the bugs are usertagged[3] gfortran, but with debian-toolchain user. Cheers, Riku [1] http://lists.debian.org/debian-toolchain/2008/02/msg0.html [2] http://release.debian.org/lenny/goals.txt [3] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];usertags=gfortran -- rm -rf only sounds scary if you don't have backups signature.asc Description: Digital signature
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 pgpHCNccGvqje.pgp Description: PGP signature
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 pgpUlie0ufc8X.pgp Description: PGP signature
