Package: libc6
Version: 2.5-4
Severity: serious
| Preparing to replace libc6 2.3.6.ds1-11 (using
.../archives/libc6_2.5-4_arm.deb) ...
| Unpacking replacement libc6 ...
| dpkg: error processing /var/cache/apt/archives/libc6_2.5-4_arm.deb (--unpack):
| dpkg: warning - old post-removal script
reassign 339415 glibc
thanks
Daniel Jacobowitz [EMAIL PROTECTED] writes:
This bug was both worked around in the glibc CVS and fixed in binutils.
It was only present in binutils HEAD for a week or two.
[AFAIK (and based in no small part on the conversation I had with
you?)] We already have a
Martin Michlmayr [EMAIL PROTECTED] writes:
* GOTO Masanori [EMAIL PROTECTED] [2004-08-02 12:16]:
2004-04-15 Atsushi Nemoto [EMAIL PROTECTED]
* sysdeps/mips/dl-machine.h (RTLD_START): Do not use nested .end.
BTW please dupload -15 binary NMU with this patch. At least we don't
GOTO Masanori [EMAIL PROTECTED] writes:
localedef uses trampoline in its internal; it may conflict with
exec-shield like pax, please see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198099
Hmm, Red Hat _must_ have a patch for that by now
They do. I've attached
tags 231438 + patch
thanks
Daniel Jacobowitz [EMAIL PROTECTED] writes:
localedef uses trampoline in its internal; it may conflict with
exec-shield like pax, please see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198099
Hmm, Red Hat _must_ have a patch for that by now
GOTO Masanori [EMAIL PROTECTED] writes:
The last time we tried a libc soname transition was
years ago, took an entire release, and involved probably only 10% of
the number of packages it would involve now.
Does this transition mean libc5 - libc6 ?
Obviously, yes?
If so, I guess the
[ Dropped external lists and people ]
GOTO Masanori [EMAIL PROTECTED] writes:
We're no problem of the transition to libc6.2
Err, really? The last time we tried a libc soname transition was
years ago, took an entire release, and involved probably only 10% of
the number of packages it would
Manoj Srivastava [EMAIL PROTECTED] writes:
Hmm. I can get rid of exec-shield and compile a new set, to
try and narrow down the patch.
Eh, just turn off exec-shield in proc[0] - no need to recompile your
kernel.
--
James
[0] echo 0 /proc/sys/kernel/exec-shield
--
To UNSUBSCRIBE,
Manoj Srivastava [EMAIL PROTECTED] writes:
Hmm. I can get rid of exec-shield and compile a new set, to
try and narrow down the patch.
Eh, just turn off exec-shield in proc[0] - no need to recompile your
kernel.
--
James
[0] echo 0 /proc/sys/kernel/exec-shield
Ross Boylan [EMAIL PROTECTED] writes:
Package: libc6
Version: 2.3.2.ds1-11
Severity: normal
During a recent apt-get dist-upgrade the log shows the following error:
Preparing to replace libc6 2.3.2.ds1-10 (using .../libc6_2.3.2.ds1-11_i386.deb) ...
/var/lib/dpkg/tmp.ci/preinst: line 184: [:
Ross Boylan [EMAIL PROTECTED] writes:
Package: libc6
Version: 2.3.2.ds1-11
Severity: normal
During a recent apt-get dist-upgrade the log shows the following error:
Preparing to replace libc6 2.3.2.ds1-10 (using
.../libc6_2.3.2.ds1-11_i386.deb) ...
/var/lib/dpkg/tmp.ci/preinst: line 184:
severity 231015 important
thanks
Yann Dirson [EMAIL PROTECTED] writes:
Package: libc6
Version: 2.3.2.ds1-11
Severity: serious
policy 10.5 says: [...] symbolic links pointing from one top-level
directory into another should be absolute.
should != serious.
--
James
--
To UNSUBSCRIBE,
severity 231015 important
thanks
Yann Dirson [EMAIL PROTECTED] writes:
Package: libc6
Version: 2.3.2.ds1-11
Severity: serious
policy 10.5 says: [...] symbolic links pointing from one top-level
directory into another should be absolute.
should != serious.
--
James
Mike Fedyk [EMAIL PROTECTED] writes:
Package: libc6
Version: 2.3.2.ds1-9
Severity: normal
The change mentioned at [1]doesn't seem to have made it into the debian
libc6 package.
It was only committed today... :-P
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
GOTO Masanori [EMAIL PROTECTED] writes:
* mips/mipsel:no machine to build. Guido, please check.
There are some debian mips/el machines now. casals and williams
maybe? I can't remember and db.d.o is still dead.
Matthias, could you tell me that --enable-sjlj-exception is really
GOTO Masanori [EMAIL PROTECTED] writes:
* mips/mipsel:no machine to build. Guido, please check.
There are some debian mips/el machines now. casals and williams
maybe? I can't remember and db.d.o is still dead.
Matthias, could you tell me that --enable-sjlj-exception is really
GOTO Masanori [EMAIL PROTECTED] writes:
One concern item is this 2.3.2-1 freezes sarge again due to FTBFS on
mips64 support (mips/mipsel), unwind (m68k/arm/hppa). It needs some
periods to fix. However we provided the previous 2.3.1-17 (it did not
build on mips/mipsel though), so it does not
GOTO Masanori [EMAIL PROTECTED] writes:
Sometimes release sarge is not the first target for all
users/developers.
Yes, that's already been well demonstrated by how long glibc held up
all of testing last time; I'm asking you to not do that again.
- Please tell me how to test it on _all_
Jeff Bailey [EMAIL PROTECTED] writes:
On Mon, May 12, 2003 at 04:50:47PM +0100, James Troup wrote:
You upload it to experimental and then you ask porters to build test
it. I never suggested you personally had to test it.
How do you expect that to work when porters weren't testing it when
Clint Adams [EMAIL PROTECTED] writes:
-MYCC = gcc-3.2 -m64
+MYCC = gcc-3.3 -m64
Don't forget a build-depends on gcc-3.3 if you do this...
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Clint Adams [EMAIL PROTECTED] writes:
-MYCC = gcc-3.2 -m64
+MYCC = gcc-3.3 -m64
Don't forget a build-depends on gcc-3.3 if you do this...
--
James
Debian Installer [EMAIL PROTECTED] writes:
Accepted:
libc6-dev-sparc64_2.3.1-16_sparc.deb
to pool/main/g/glibc/libc6-dev-sparc64_2.3.1-16_sparc.deb
libc6-sparc64_2.3.1-16_sparc.deb
to pool/main/g/glibc/libc6-sparc64_2.3.1-16_sparc.deb
Oi! Whoever's doing this, stop it. You've nicely
Debian Installer [EMAIL PROTECTED] writes:
Accepted:
libc6-dev-sparc64_2.3.1-16_sparc.deb
to pool/main/g/glibc/libc6-dev-sparc64_2.3.1-16_sparc.deb
libc6-sparc64_2.3.1-16_sparc.deb
to pool/main/g/glibc/libc6-sparc64_2.3.1-16_sparc.deb
Oi! Whoever's doing this, stop it. You've nicely
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
glibc_2.3.1-16.diff.gz
glibc_2.3.1-16.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives within 22:02:00, the files will be
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
glibc_2.3.1-16.diff.gz
glibc_2.3.1-16.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives within 22:39:56, the files will be
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
glibc_2.3.1-16.diff.gz
glibc_2.3.1-16.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives within 22:02:00, the files will be
Probably you are the uploader of the following file(s) in
the Debian upload queue directory:
glibc_2.3.1-16.diff.gz
glibc_2.3.1-16.dsc
This looks like an upload, but a .changes file is missing, so the job
cannot be processed.
If no .changes file arrives within 22:39:56, the files will be
GOTO Masanori [EMAIL PROTECTED] writes:
Please don't do this.
Look at the prior changelog in BenC's.
Pointing to someone doing something wrong previously doesn't prove
anything.
If you aren't making a change in the package,
then close the bug by sending mail to bug-done, not by adding
Package: glibc
Version: 2.3.1-10
| elmo /usr/bin/wget: relocation error: /usr/bin/wget: undefined symbol: __umoddi3
| elmo anyone know why I might be seeing that on sparc ?
[...]
| pb_ glibc might want to see about exporting those libgcc symbols
| on sparc for the benefit of any other
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
I would be really worried that if we did this that we'd be forced to
conflict with every package that at some version relied on undefined
behaviour in glibc. Sadly, I don't think there's a solution to this
that wouldn't result in just as
Randolph Chung [EMAIL PROTECTED] writes:
* #167794: Wrong Pre-Depends
Package: libc6; Severity: critical; Reported by: Martin Schulze [EMAIL
PROTECTED]; 25 days old.
Looks like this might be a problem in the buildd setup? There's not
enough information in the bug to say, and I'm
glibc_2.3.1-5_sparc.changes uploaded successfully to auric.debian.org
along with the files:
libc6-sparc64_2.3.1-5_sparc.deb
libc6-dev-sparc64_2.3.1-5_sparc.deb
libc6_2.3.1-5_sparc.deb
libc-udeb_2.3.1-5_sparc.udeb
libc6-dev_2.3.1-5_sparc.deb
libc6-prof_2.3.1-5_sparc.deb
glibc_2.3.1-5_sparc.changes uploaded successfully to auric.debian.org
along with the files:
libc6-sparc64_2.3.1-5_sparc.deb
libc6-dev-sparc64_2.3.1-5_sparc.deb
libc6_2.3.1-5_sparc.deb
libc-udeb_2.3.1-5_sparc.udeb
libc6-dev_2.3.1-5_sparc.deb
libc6-prof_2.3.1-5_sparc.deb
33 matches
Mail list logo
