Re: extern inline and ?stat64 fun in glibc
On Thu, Feb 14, 2008 at 10:47:00AM +, Pierre Habouzit wrote: > On Wed, Feb 13, 2008 at 11:21:46PM +, Sune Vuorela wrote: > > Hi! > > > > As many people know, som header change in libc6-dev made libqt3-mt (and > > maybe > > other packages) drop some symbols on one or more archs. > > > > For full details, see the thread starting here: > > http://lists.debian.org/debian-devel/2008/02/msg00439.html, especially the > > post by Pierre here: > > http://lists.debian.org/debian-devel/2008/02/msg00580.html > > > > For the result of this change, see the RC buglist against libqt3-mt > > > > The question is now - what to do? > > > > 1) Roll back the changes to libc6-dev and rebuild qt3 > > 2) patch in those symbols in qt3 > > 3) rename libqt3-mt and rebuild all 500 rdeps, including all of kde3. > > 4) something else ? > > > > I am currently most in favour of 1. And very much against 2. But hoping for > > 4. > > Well, I'd like to avoid (1) if possible. > > > But please discuss and comment - and please keep me cc'ed. I am not > > subscribed > > to glibc list. > > Well, there is a possibility, the affected packages are ones that have > undefined symbols on stat64 and that used to get their crack from > another library (libqt3 here). We have to scan the whole archive for > undefined symbols on stat64 and other alike symbols (we can probably > find an exhaustive enough list, grep for __extern_inline in the > libc6-dev basically). > > If that amount of packages is small, then the libraries that used to > provide the symbols for them should have versionned conflicts, bump > their shlibs, and then those packages should be binNMUed. > > Though this approach only works if there is (and I believe it's the > case) few packages matching. > > What do you think ? > > [ basically for qt3 it seems it would be only 3 conflicts, we can live > with that ] FWIW the list of symbols on amd64 seems to be the one attached. Don't be afraid, there is a lot of guards to get them, and it's really likely we won't have any matches in the archive on UNDEFINED symbols on them. I don't have time to perform the scan yet though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org __argp_usage __argz_next __cmsg_nxthdr __option_is_end __option_is_short __pthread_cleanup_routine __signbit __signbitf __signbitl argz_next atof atoi atol atoll btowc cimag conj creal feof_unlocked ferror_unlocked fgetc_unlocked fputc_unlocked fstat fstat64 fstatat fstatat64 getc_unlocked getchar getchar_unlocked getline gnu_dev_major gnu_dev_makedev gnu_dev_minor lstat lstat64 mbrlen mknod mknodat pthread_equal putc_unlocked putchar putchar_unlocked stat stat64 strtoimax strtoumax tolower toupper vprintf wcstoimax wcstoumax wctob pgphcQdk9sSf9.pgp Description: PGP signature
Re: extern inline and ?stat64 fun in glibc
On Wed, Feb 13, 2008 at 11:21:46PM +, Sune Vuorela wrote: > Hi! > > As many people know, som header change in libc6-dev made libqt3-mt (and maybe > other packages) drop some symbols on one or more archs. > > For full details, see the thread starting here: > http://lists.debian.org/debian-devel/2008/02/msg00439.html, especially the > post by Pierre here: > http://lists.debian.org/debian-devel/2008/02/msg00580.html > > For the result of this change, see the RC buglist against libqt3-mt > > The question is now - what to do? > > 1) Roll back the changes to libc6-dev and rebuild qt3 > 2) patch in those symbols in qt3 > 3) rename libqt3-mt and rebuild all 500 rdeps, including all of kde3. > 4) something else ? > > I am currently most in favour of 1. And very much against 2. But hoping for 4. Well, I'd like to avoid (1) if possible. > But please discuss and comment - and please keep me cc'ed. I am not > subscribed > to glibc list. Well, there is a possibility, the affected packages are ones that have undefined symbols on stat64 and that used to get their crack from another library (libqt3 here). We have to scan the whole archive for undefined symbols on stat64 and other alike symbols (we can probably find an exhaustive enough list, grep for __extern_inline in the libc6-dev basically). If that amount of packages is small, then the libraries that used to provide the symbols for them should have versionned conflicts, bump their shlibs, and then those packages should be binNMUed. Though this approach only works if there is (and I believe it's the case) few packages matching. What do you think ? [ basically for qt3 it seems it would be only 3 conflicts, we can live with that ] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQ9lwOx3VRH.pgp Description: PGP signature
extern inline and ?stat64 fun in glibc
Hi! As many people know, som header change in libc6-dev made libqt3-mt (and maybe other packages) drop some symbols on one or more archs. For full details, see the thread starting here: http://lists.debian.org/debian-devel/2008/02/msg00439.html, especially the post by Pierre here: http://lists.debian.org/debian-devel/2008/02/msg00580.html For the result of this change, see the RC buglist against libqt3-mt The question is now - what to do? 1) Roll back the changes to libc6-dev and rebuild qt3 2) patch in those symbols in qt3 3) rename libqt3-mt and rebuild all 500 rdeps, including all of kde3. 4) something else ? I am currently most in favour of 1. And very much against 2. But hoping for 4. But please discuss and comment - and please keep me cc'ed. I am not subscribed to glibc list. /Sune - one of your friendly kde/qt packagers.< -- Man, do you know how may I do for getting access on a kernel? You have to digit on the connection to reset the mousepad. signature.asc Description: This is a digitally signed message part.
