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
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
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
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
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
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
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
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
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
9 matches
Mail list logo
