Re: Bug handling
* #173082: libnss-db_2.2-6.1(hppa/unstable): FTBFS: assumes __LT_SPINLOCK_INIT is int Probably a libnss-db problem. ``Conflicts: ... libnss-db ( 2.2-6)'' from libc6 might be wrong; it seems like it should be = 2.2-6 if there's been significant changes made. I submitted the patch for this 3 days ago :) c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug handling
Checking for every symbol that _has_ ever leaked is the main thing, so we can get all the broken packages rebuilt. You need that list for glibc anyway, by the looks. I agree, I was learning how to write lintian test for this specific purpose. gcc leaked __clz_tab in HPPA and according to John David Anglin it did so on other arches. This breaks wget on hppa unstable and I need to get around to writing a gcc-compat for this. c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug handling
Hi guys, You have a bunch of RC bugs open: * #180619: Illegal instruction in /lib/libpthread-0.10.so on linux/mipsel Apparently this is a kernel problem, not a glibc problem. neuro 180619 is a kernel thing aj definitely? neuro 180619? yes It should then be reassigned to the appropriate kernel package. * #179781: dcgui: relocation error: /usr/bin/dcgui: undefined symbol: __fixunsdfdi * #180330: libc6, relocation error (dcgui) * #178645: glibc: needs to export __umoddi3 et al. on sparc These are apparently all be the same problem, so the latter bug should be merged with the first two; and they seem to be due to problems in gcc/binutils, so they should probably be reassigned there. * #175526: [m68k] nearly all gcc-3.2 tests fail with glibc-2.3 Possibly a gcc problem, that will be fixed when gcc builds. * #173082: libnss-db_2.2-6.1(hppa/unstable): FTBFS: assumes __LT_SPINLOCK_INIT is int Probably a libnss-db problem. ``Conflicts: ... libnss-db ( 2.2-6)'' from libc6 might be wrong; it seems like it should be = 2.2-6 if there's been significant changes made. * #171659: glibc: Sun RPC code is non-free Not necessarily a problem; needs to be properly investigated. The GNU FDL part of this should be fixed upstream. Which is to say most of these bugs need to be moved and fixed in other packages; keeping them listed on glibc isn't doing anyone any good if the problem's not actually in glibc. The aim's to ensure that glibc doesn't break things -- by including being backwards compatible, and fixing your own bugs, or including Conflicts as appropriate or whatever else. Problems amongst packages need to be handled using dependency info to make sure testing and partial updates work, not by filing other packages' bugs against glibc. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' msg03048/pgp0.pgp Description: PGP signature
Re: Bug handling
On Wed, Feb 12, 2003 at 09:20:39PM +1000, Anthony Towns wrote: * #179781: dcgui: relocation error: /usr/bin/dcgui: undefined symbol: __fixunsdfdi * #180330: libc6, relocation error (dcgui) * #178645: glibc: needs to export __umoddi3 et al. on sparc These are apparently all be the same problem, so the latter bug should be merged with the first two; and they seem to be due to problems in gcc/binutils, so they should probably be reassigned there. Okay, due to gcc/binutils yes (they weren't hiding symbols properly), but it seems to be something that needs to be fixed/worked-around in glibc anyway. You guys get all the fun. In particular it seems that all the symbols that've ever been leaked from gcc-compat need to be exported from glibc. Which means someone needs to do a scan of woody to work out which symbols these are (Ryan and Guido are doing this), these symbols need to be added to glibc and -12 needs to be uploaded, and a lintian test needs to be written to make sure this doesn't happen again, and to remind people to recompile sooner rather than later. So, glibc team? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' msg03051/pgp0.pgp Description: PGP signature
Re: Bug handling
On Thu, Feb 13, 2003 at 12:37:06AM +1000, Anthony Towns wrote: and a lintian test needs to be written to make sure this doesn't happen again, and to remind people to recompile sooner rather than later. Hmm.. How would we lintian test this, other that checking for every symbol that might possibly ever leak? That sounds like a nightmare to maintain, since hidden symbols have no guarantee for consistancy. Tks, Jeff Bailey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug handling
On Wed, Feb 12, 2003 at 07:53:16AM -0800, Jeff Bailey wrote: On Thu, Feb 13, 2003 at 12:37:06AM +1000, Anthony Towns wrote: and a lintian test needs to be written to make sure this doesn't happen again, and to remind people to recompile sooner rather than later. Hmm.. How would we lintian test this, other that checking for every symbol that might possibly ever leak? That sounds like a nightmare to maintain, since hidden symbols have no guarantee for consistancy. Checking for every symbol that _has_ ever leaked is the main thing, so we can get all the broken packages rebuilt. You need that list for glibc anyway, by the looks. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' msg03069/pgp0.pgp Description: PGP signature
