Bug#162663: libc0.3-dev: depends on gnumach-dev which is priority optional
Package: libc0.3-dev Version: 2.2.5-13 (not installed) Severity: serious Justification: Policy 2.2 libc0.3-dev is priority standard. gnumach-dev is priority optional. libc0.3-dev Depends: on gnumach-dev, which is forbidden. One of the two priorities needs to be adjusted, so that it no longer violates policy, or else libc0.3-dev needs to not depend on gnumach-dev, which is probably a bad idea. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stonewall 2.4.18-k7 #1 Sun Apr 14 13:19:11 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set) -- Brian M. Carlson [EMAIL PROTECTED] http://decoy.wox.org/~bmc 0x560553E7 I always pass on good advice. It is the only thing to do with it. It is never any good to oneself. -- Oscar Wilde, An Ideal Husband msg01096/pgp0.pgp Description: PGP signature
Bug#162551: libc6-sparc64 conflicts with fakeroot
On Fri, Sep 27, 2002 at 03:46:34PM +0900, Julian Stoev wrote: Today's SPARC upgrade is broken. dpkg: error processing /var/cache/apt/archives/libc6-sparc64_2.2.5-11.2_sparc.deb (--unpack): trying to overwrite `/usr/lib/64', which is also in package fakeroot Errors were encountered while processing: /var/cache/apt/archives/libc6-sparc64_2.2.5-11.2_sparc.deb E: Sub-process /usr/bin/dpkg returned an error code (1) fakeroot in stable still uses /usr/lib/64. Do we need a fix for #151448 in woody-proposed-updates? -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#162663: libc0.3-dev: depends on gnumach-dev which is priority optional
On Sat, Sep 28, 2002 at 07:34:35AM +, Brian M. Carlson wrote: libc0.3-dev is priority standard. gnumach-dev is priority optional. libc0.3-dev Depends: on gnumach-dev, which is forbidden. One of the two priorities needs to be adjusted, so that it no longer violates policy, or else libc0.3-dev needs to not depend on gnumach-dev, which is probably a bad idea. Thanks for bringing this to our attention. I will re-assign to gnumach-dev. Tks, jeff Bailey -- learning from failures is nice in theory... but in practice, it sucks :) - Wolfgang Jaehrling -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Bug #162663
Processing commands for [EMAIL PROTECTED]: reassign 162663 gnumach-dev Bug#162663: libc0.3-dev: depends on gnumach-dev which is priority optional Bug reassigned from package `libc0.3-dev' to `gnumach-dev'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
glibc 2.3 very soon
Carlos, It looks like Ulrich is preparing to kick out glibc shortly and roll any remaining fixes into glibc 2.3.1... http://sources.redhat.com/ml/libc-hacker/2002-09/msg00072.html Is hppa building cleanly and passing all of make check from current glibc cvs? If not you might want to push any remaining hppa patches. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.3 very soon
Carlos, It looks like Ulrich is preparing to kick out glibc shortly and roll any remaining fixes into glibc 2.3.1... http://sources.redhat.com/ml/libc-hacker/2002-09/msg00072.html Is hppa building cleanly and passing all of make check from current glibc cvs? If not you might want to push any remaining hppa patches. Jack My current task is to do all of this today and tommorow: - Rewrite and simplify pthreads (rather rote and mechanical) - Submit 'unwind' patch (trivial) - Submit 'tests' patch (trivial) - Submit 'data-start' patch (trivial) - Submit 'mcontext' patch (trivial/review) - Submit 'libgcccompat' (non-trivial/small patch/review) - Submit 'fcntl' (trivial) - Submit 'fcntl64' (trivial) - Submit 'build-hack' (trivial/review) All the trivial pathces are small and only effect HPPA. All the patches that require review do so only for HPPA. Essentially the following patches are small and only touch HPPA as an arch :) With all these changes in CVS, HPPA will be in sync upstream. I'll be pulling the latest glibc CVS within the hour to run another build. c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc 2.3 very soon
Carlos, I thought someone told me that the debian packages for hppa had been run through my findsyms perl script and that no undefined libgcc symbols were detected in any of the binaries or libraries? If that is the case you don't need a libgcc-compat at all. Jack -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
findsyms results?
Hi, If anyone has run my findsyms perl script.. http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00148.html http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00164.html ...and has results for a particular arch, they may want to share this information upstream with Ulrich. Even if it only confirms that the existing libgcc-compat situation if sufficient for an arch it would be polite since we are likely sampling a much larger codebase than they were when the libgcc-compat code went it. Thanks in advance. With glibc 2.3 about to release any moment we might want to give them a heads up on any holes in the libgcc-compat code. Jack ps By information, I mean just the list of hidden libgcc symbols that findsyms found and collated in the final.list file it creates. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#162576: marked as done (libc6-dev: errno is a function call in non-threaded program)
Florian Weimer [EMAIL PROTECTED] wrote:
The slowdown is a price to be paid, otherwise we would need a
different set of almost all shared libraries for linking with
multi-threading programs. I think we already had this situation, and
it wasn't nice at all.
No you don't, all you need to do is to make the errno macro conditional.
You already have to support people not including errno.h...
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
