On Thu, Feb 14, 2008 at 10:47:00AM +0000, Pierre Habouzit wrote: > On Wed, Feb 13, 2008 at 11:21:46PM +0000, 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 madcoder@debian.org OOO http://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
Attachment:
pgpNuSc_wiDGr.pgp
Description: PGP signature