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: 1) Solution should be technically correct. 2) It should have the least possible negative impact on unstable users. For starters, it seems that only 000000000070c5c8 w DF .text 0000000000000024 Base lstat64 000000000042ee4c w DF .text 0000000000000022 Base fstat64 00000000006075ea w DF .text 0000000000000024 Base stat64 are relevant for libqt3-mt case out of all symbols listed at [1]. I see two major strategies how to deal with the breakage: 1) Ignore the fact that libqt3-mt ABI changed incompatibly because it affects a very low number of packages depending on libqt3-mt (maybe ~5-7 out of 396). In this case we could wait till qt3 3.3.8b-1 was build on all arches and binNMU those ~5-7 affected packages. Later if other packages are discovered, binNMU them immediately. This way of action is (imho): 1) technically incorrect (dropped symbols cannot be ignored in any case) 2) broken partial upgrades from etch are possible. 3) quality is traded for the fast/almost immediate solution with least hassle for developers (in the short term) and light load on buildds. In my opinion, this strategy is not acceptable for Debian (as I understand the Debian way of doing things) due to all points above. 2) The 2nd strategy would be to start libqt3-mt library transition. There are ~396 source packages, which binaries depend on libqt3-mt. However, this library transition would be a big inconvenience for developers and users (criteria 2) because it would take long time (397 packages to rebuild + delays while waiting until some are built on all arches). 1. Therefore, in my option, it''s a must to "unbreak" libqt3-mt or affected packages before starting the transition. This could be done in two ways: a) add missing symbols back to libqt3-mt by uploading 3.3.8b-2 with patch like [2] applied. Then wait at least until 3.3.8b-2 is built on all arches having 3.3.8b-1 installed before starting the transition. In this case libqt3-mt ABI compatibility is fully restored, users can use previously broken known (to us) _and unknown_ packages w/o problems. Futhermore, temporary solving this problem in QT3 means less hassle for developers of affected packages. Finally effect of this solution should be nearly immediate. b) binNMU affected packages against libqt3-mt 3.3.8b-1 now. However, this would "unbreak" only those packages which were discovered until the start of the transition. Later discovered packages would have to wait until the end of the transition to be usable (or a user could take action (c) below). This solution means more communitication and a bit more delay. c) Don''t do anything and tell users to downgrage libqt3-mt to 3.3.7-9 until transition ends. The problem is that we can''t tell all users to do this and (a) (especially) or (b) seem much easier & more smooth ways. In case of (c), we could start transition immediately. 2. When #464946 & friends are temporary resolved one way or the other, transition could be started. This would involve renaming of libqt3-mt to e.g. libqt3-mt-1 or whatever and, once the latter has been built on all arches, binNMU''ing of all libqt3-mt reverse dependences. We could binNMU packages in groups doing the libraries and the most popular packages first (based on popcon rating) to avoid overloads on buildds. If either 1a or 1b has been done before transition, it should be nearly no hassle for our users, because aptitude (and apt-get too) should automatically hold libqt3-mt-1 and binNMU''ed packages until all (or most) packages installed on user''s machine have been transitioned. Since all(1a)/most(1b) old versions of software will work with libqt3-mt, inconvenience should be minimal. By the way, transition should be started before upload of kde 3.5.9 to minimize load on buildds (hence all of KDE won''t need to be binNMUed for transition, simply new upstream version will be uploaded for transition). Any suggestions? 1. http://article.gmane.org/gmane.linux.debian.devel.glibc/25981 2. http://alioth.debian.org/~modax-guest/qt/01_stat_extern_inline_hack.diff -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080214/2220762d/attachment.pgp
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 trustedqsl may not be related to the others. It does not use Qt or have any stat64-related symbols, and is the only package with a missing atoi symbol.> 1) Solution should be technically correct. > 2) It should have the least possible negative impact on unstable users. > > For starters, it seems that only > 000000000070c5c8 w DF .text 0000000000000024 Base lstat64 > 000000000042ee4c w DF .text 0000000000000022 Base fstat64 > 00000000006075ea w DF .text 0000000000000024 Base stat64 > are relevant for libqt3-mt case out of all symbols listed at [1].With the exception of "atoi" in trustedqsl, these are indeed the only problematic symbols of that list. Attached is a list of packages & files with the missing symbols. -------------- next part -------------- digikam_2:0.9.3-1_i386.deb /usr/lib/kde3/kio_digikamalbums.so 00000000 DF *UND* 00000032 lstat64 00000000 DF *UND* 00000032 stat64 /usr/lib/libdigikam.so.0.0.0 00000000 DF *UND* 00000032 fstat64 00000000 DF *UND* 00000032 stat64 k3b_1.0.4-6_i386.deb /usr/bin/k3b 00000000 DF *UND* 00000032 lstat64 00000000 DF *UND* 00000032 stat64 kcontrol_4:3.5.8.dfsg.1-7_i386.deb /usr/lib/kde3/kcm_fonts.so 00000000 DF *UND* 00000032 lstat64 kdirstat_2.4.4-4_i386.deb /usr/bin/kdirstat 00000000 DF *UND* 00000032 lstat64 kexi_1:1.6.3-4_i386.deb /usr/lib/libkeximain.so.2.0.0 00000000 DF *UND* 00000032 stat64 konq-plugins_4:3.5.8-3_i386.deb /usr/bin/fsview 00000000 DF *UND* 00000032 lstat64 konqueror_4:3.5.8.dfsg.1-7_i386.deb /usr/lib/kde3/konq_sidebartree_dirtree.so 00000000 DF *UND* 00000032 stat64 ktorrent_2.2.5.dfsg.1-1_i386.deb /usr/lib/libktorrent-2.2.5.so 00000000 DF *UND* 00000032 fstat64 00000000 DF *UND* 00000032 lstat64 00000000 DF *UND* 00000032 stat64 libk3b3_1.0.4-6_i386.deb /usr/lib/libk3b.so.3.0.0 00000000 DF *UND* 00000032 lstat64 00000000 DF *UND* 00000032 stat64 libmyth-0.20.2_0.20.2.svn20080126-0.0_i386.deb /usr/lib/libmyth-0.20.2.so.0.20.2 00000000 DF *UND* 00000032 stat64 /usr/lib/libmythlivemedia-0.20.2.so.0.20.2 00000000 DF *UND* 00000032 stat64 /usr/lib/libmythtv-0.20.2.so.0.20.2 00000000 DF *UND* 00000032 lstat64 00000000 DF *UND* 00000032 stat64 /usr/lib/libmythupnp-0.20.2.so.0.20.2 00000000 DF *UND* 00000032 stat64 mythdvd_0.20.2.svn20080126-0.0_i386.deb /usr/bin/mtd 00000000 DF *UND* 00000032 stat64 mythmusic_0.20.2.svn20080126-0.0_i386.deb /usr/lib/mythtv/plugins/libmythmusic.so 00000000 DF *UND* 00000032 fstat64 00000000 DF *UND* 00000032 stat64 mythtv-backend_0.20.2.svn20080126-0.0_i386.deb /usr/bin/mythbackend 00000000 DF *UND* 00000032 stat64 /usr/bin/mythtranscode 00000000 DF *UND* 00000032 stat64 pdfedit_0.3.2-5_i386.deb /usr/bin/pdfedit 00000000 DF *UND* 00000032 stat64 trustedqsl_1.11-5_i386.deb /usr/bin/tqsl 00000000 DF *UND* 00000038 atoi /usr/bin/tqslcert 00000000 DF *UND* 00000038 atoi virtualbox-ose_1.5.4-dfsg-4_i386.deb /usr/lib/virtualbox/VirtualBox 00000000 DF *UND* 00000032 stat64 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/716ed436/attachment.pgp
Hi, 2008 m. February 16 d., Saturday, Matthew Rosewarne ra??:> 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-oseAnd kmail on powerpc: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465555 -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/acf28aa9/attachment.pgp
On Sat, Feb 16, 2008 at 08:08:17AM +0000, 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-oseOkay 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 madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/c2f6dc1d/attachment.pgp
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 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi $ objdump -tT /usr/bin/tqslcert | grep atoi 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi 0000000000000000 DF *UND* 0000000000000015 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 <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/c0e8cd86/attachment.pgp
On Sat, Feb 16, 2008 at 10:52:01AM +0000, 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 > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > $ objdump -tT /usr/bin/tqslcert | grep atoi > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoiatoi is a libc symbol, so I don''t see a problem with that: $ objdump -T /lib/libc-2.7.so|grep atoi 0000000000032530 g DF .text 0000000000000015 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 fstat64I 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 madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/f064be3b/attachment-0001.pgp
On Sat, Feb 16, 2008 at 10:58:13AM +0000, 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 madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/63ee1bbb/attachment.pgp
On Sat, Feb 16, 2008 at 01:22:31PM +0000, 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 madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080216/b7117c09/attachment.pgp
On Saturday 16 February 2008, Pierre Habouzit wrote:> > 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 > > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > > $ objdump -tT /usr/bin/tqslcert | grep atoi > > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > > $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi > > 0000000000000000 DF *UND* 0000000000000015 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 > 0000000000032530 g DF .text 0000000000000015 GLIBC_2.2.5 atoi > > The fact that atoi is clearly versionned should have given you a hint ;PI''m not quite sure why atoi showed up undefined/unversioned in trustedqsl. I got: trustedqsl_1.11-5_i386.deb /usr/bin/tqsl 00000000 DF *UND* 00000038 atoi /usr/bin/tqslcert 00000000 DF *UND* 00000038 atoi This package was recently updated in Sid, so I would assume it''s probably fixed anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080217/83c867cf/attachment.pgp
On Sat, Feb 16, 2008 at 10:17:33AM +0100, Pierre Habouzit wrote:> > 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.Well, considering this is a very small percentage of the total libqt3 reverse-deps, I think it''s at least a "less bad" solution than a library transition. I don''t know for sure, but would expect the impact on dist-upgrades to be manageable.> 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.I would be inclined to argue that the conflicts should still be there in the lenny+1 libqt3 package, since nothing else would enforce at the package level that a user doesn''t partially upgrade to lenny and then partially upgrade again to lenny+1. -- 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 Developer http://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org
On Sun, Feb 17, 2008 at 10:08:08PM +0000, Matthew Rosewarne wrote:> On Saturday 16 February 2008, Pierre Habouzit wrote: > > > 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 > > > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > > > $ objdump -tT /usr/bin/tqslcert | grep atoi > > > 0000000000000000 DF *UND* 0000000000000015 GLIBC_2.2.5 atoi > > > $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi > > > 0000000000000000 DF *UND* 0000000000000015 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 > > 0000000000032530 g DF .text 0000000000000015 GLIBC_2.2.5 atoi > > > > The fact that atoi is clearly versionned should have given you a hint ;P > > I''m not quite sure why atoi showed up undefined/unversioned in trustedqsl. I > got: > trustedqsl_1.11-5_i386.deb > /usr/bin/tqsl > 00000000 DF *UND* 00000038 atoi > /usr/bin/tqslcert > 00000000 DF *UND* 00000038 atoi > > This package was recently updated in Sid, so I would assume it''s probably > fixed anyway.We don''t care, atoi is a glibc symbol, so it''ll work. -- ?O? Pierre Habouzit ??O madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080218/d33ae799/attachment.pgp
On Mon, Feb 18, 2008 at 08:39:51AM +0000, Steve Langasek wrote:> On Sat, Feb 16, 2008 at 10:17:33AM +0100, Pierre Habouzit wrote: > > > 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. > > Well, considering this is a very small percentage of the total libqt3 > reverse-deps, I think it''s at least a "less bad" solution than a library > transition. I don''t know for sure, but would expect the impact on > dist-upgrades to be manageable.Well, actually, it seems that (with our more extended search) stat64 and friends are the 3 sole missing symbols, and they will be hacked back in, as qt3 is in the leave on the long term (probably will still be here in lenny+1, probably not in lenny+2). We understand fully why they are missing now, and that''s why we''re sure that (1) the problem is limited to Qt and (2) it won''t show up again[0]. There is an experimental package with the symbols hacked back in and built with -O2, we should avoid (1) a transition (2) conflicts (3) delaying kde 3.8.9 upload. I''ll still check that none of the other symbols that got missing due to the use of -O2 were really used in any qt3 rdeps somewhere in the week though. Thanks a _lot_ to Modestas for his invaluable help on that issue. [0] basically you need to (1) be a library (2) in c++ (3) built with -O0 (4) with an old glibc (<= 2.6) to get the symbols. We hope qt3 was the sole library meeting these conditions, and if not, the hack will be the same: reinstate the missing symbols back in, as the real source of the bug isn''t really libc6-dev, but the fact that the library was built with -O0 despite the policy. -- ?O? Pierre Habouzit ??O madcoder at debian.org OOO http://www.madism.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20080218/5da40a4b/attachment.pgp