Package: libc6
Version: 2.3.2.ds1-10
Severity: important
This version of libc6 has a warning about incorrectly built binaries
accessing erno orh_errno etc. NOw apparently sendmail is one of
those and some packages which invoke sendmail do not send the mail if
this happens. Anyway to either get s
Hi,
This bug is coming up on its seventh birthday and there's been no
activity for over a year. Should it be closed?
Thanks,
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo '[EMAIL PROTECTED]' | rot13
Package: libc6
Version: 2.3.2.ds1-10
Severity: important
This version of libc6 has a warning about incorrectly built binaries
accessing erno orh_errno etc. NOw apparently sendmail is one of
those and some packages which invoke sendmail do not send the mail if
this happens. Anyway to either get s
Processing commands for [EMAIL PROTECTED]:
> tags 219352 + moreinfo unreproducible
Bug#219352: Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72:
_dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx'
failed!
There were no tags set.
Tags added: moreinfo, unrepro
Hi,
This bug is coming up on its seventh birthday and there's been no
activity for over a year. Should it be closed?
Thanks,
--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo '[EMAIL PROTECTED]' | rot13
--
To UNSUBSCRIBE, email to [EMAIL PROT
Processing commands for [EMAIL PROTECTED]:
> tags 219352 + moreinfo unreproducible
Bug#219352: Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 72:
_dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!
There were no tags set.
Tags added: moreinfo, unreprod
* Kevin Rosenberg <[EMAIL PROTECTED]> [2003-11-07 09:52]:
> GOTO Masanori wrote:
> > We're encountering #218657. This bug says many programs become
> > unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> > architecture. We all debian-glibc developers can't access such
> > machine, so
* Kevin Rosenberg <[EMAIL PROTECTED]> [2003-11-07 09:52]:
> GOTO Masanori wrote:
> > We're encountering #218657. This bug says many programs become
> > unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> > architecture. We all debian-glibc developers can't access such
> > machine, so
Daniel Jacobowitz wrote:
> I thought you said gcc was broken?
It was on initial testing, but recently I've been able to compile a
simple file.
emacs still fails in an obscure and varying ways on different
invocations. It will be difficult to narrow down the actual cause.
> If it's just statfs, l
On Fri, Nov 07, 2003 at 03:07:01PM -0700, Kevin Rosenberg wrote:
> Daniel Jacobowitz wrote:
> > Yes, substantially. But LD_ASSUME_KERNEL=2.4.1 should undo it. You'll
> > have dig further.
>
> Well, it's not fixing this issue:
>
> [EMAIL PROTECTED]:~> LD_ASSUME_KERNEL=2.4.1 df .
> Filesystem
Daniel Jacobowitz wrote:
> I thought you said gcc was broken?
It was on initial testing, but recently I've been able to compile a
simple file.
emacs still fails in an obscure and varying ways on different
invocations. It will be difficult to narrow down the actual cause.
> If it's just statfs, l
On Fri, Nov 07, 2003 at 04:13:24AM +, Colin Watson wrote:
> I've (er, unilaterally) removed this ban until such time as somebody
> explains it properly, and preferably also sets some kind of time limit
> or conditions on it.
I thank you most gratefully.
> I'd recommend that the glibc close/re
On Fri, Nov 07, 2003 at 03:07:01PM -0700, Kevin Rosenberg wrote:
> Daniel Jacobowitz wrote:
> > Yes, substantially. But LD_ASSUME_KERNEL=2.4.1 should undo it. You'll
> > have dig further.
>
> Well, it's not fixing this issue:
>
> [EMAIL PROTECTED]:~> LD_ASSUME_KERNEL=2.4.1 df .
> Filesystem
Processing commands for [EMAIL PROTECTED]:
> reassign 218639 vlc
Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors
Bug reassigned from package `linux-kernel-headers' to `vlc'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug trackin
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-8
Severity: normal
Dear Glibc maintainers,
Since a few days, the following program
---test.c
#include
-
give:
$ gcc-2.95 -c -Wall test.c 2>&1
In file included from /usr/include/asm/sigcontext.h:4,
f
reassign 218639 vlc
thanks
On Tue, Nov 04, 2003 at 09:48:22AM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 218639 linux-kernel-headers
> Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors
> Bug reassigned from package
On Fri, Nov 07, 2003 at 04:13:24AM +, Colin Watson wrote:
> I've (er, unilaterally) removed this ban until such time as somebody
> explains it properly, and preferably also sets some kind of time limit
> or conditions on it.
I thank you most gratefully.
> I'd recommend that the glibc close/re
Processing commands for [EMAIL PROTECTED]:
> reassign 218639 vlc
Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors
Bug reassigned from package `linux-kernel-headers' to `vlc'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug trackin
Package: linux-kernel-headers
Version: 2.5.999-test7-bk-8
Severity: normal
Dear Glibc maintainers,
Since a few days, the following program
---test.c
#include
-
give:
$ gcc-2.95 -c -Wall test.c 2>&1
In file included from /usr/include/asm/sigcontext.h:4,
f
reassign 218639 vlc
thanks
On Tue, Nov 04, 2003 at 09:48:22AM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 218639 linux-kernel-headers
> Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors
> Bug reassigned from package
Daniel Jacobowitz wrote:
> Yes, substantially. But LD_ASSUME_KERNEL=2.4.1 should undo it. You'll
> have dig further.
Well, it's not fixing this issue:
[EMAIL PROTECTED]:~> LD_ASSUME_KERNEL=2.4.1 df .
Filesystem 1K-blocks Used Available Use% Mounted on
df: `/home': Bad address
>
Daniel Jacobowitz wrote:
> Yes, substantially. But LD_ASSUME_KERNEL=2.4.1 should undo it. You'll
> have dig further.
Well, it's not fixing this issue:
[EMAIL PROTECTED]:~> LD_ASSUME_KERNEL=2.4.1 df .
Filesystem 1K-blocks Used Available Use% Mounted on
df: `/home': Bad address
>
On Fri, Nov 07, 2003 at 01:57:21PM -0700, Kevin Rosenberg wrote:
> Daniel Jacobowitz wrote:
> > What libc function is failing? This sounds like a bug in the 32-bit
> > emulation layer of your kernel, at first look.
>
> The statfs invocation at line 183 in file
> coreutils-5.0.91/lib/fsusage.c is
Daniel Jacobowitz wrote:
> What libc function is failing? This sounds like a bug in the 32-bit
> emulation layer of your kernel, at first look.
The statfs invocation at line 183 in file
coreutils-5.0.91/lib/fsusage.c is the failing function.
Is there much of a difference in the libc/kernel inter
Mike Snitzer wrote:
> To _really_ have a working 2.6 based system the libc should be NPTL aware;
> debian will likely need to vut over to it sooner rather than later.
> [...]
> or LD_ASSUME_KERNEL=2.2.5
I'm running 2.6.0-test8. I tried df with your suggestion and the error
remains.
--
Kevin Ro
On Fri, Nov 07, 2003 at 01:57:21PM -0700, Kevin Rosenberg wrote:
> Daniel Jacobowitz wrote:
> > What libc function is failing? This sounds like a bug in the 32-bit
> > emulation layer of your kernel, at first look.
>
> The statfs invocation at line 183 in file
> coreutils-5.0.91/lib/fsusage.c is
Daniel Jacobowitz wrote:
> What libc function is failing? This sounds like a bug in the 32-bit
> emulation layer of your kernel, at first look.
The statfs invocation at line 183 in file
coreutils-5.0.91/lib/fsusage.c is the failing function.
Is there much of a difference in the libc/kernel inter
Mike Snitzer wrote:
> To _really_ have a working 2.6 based system the libc should be NPTL aware;
> debian will likely need to vut over to it sooner rather than later.
> [...]
> or LD_ASSUME_KERNEL=2.2.5
I'm running 2.6.0-test8. I tried df with your suggestion and the error
remains.
--
Kevin Ro
To _really_ have a working 2.6 based system the libc should be NPTL aware;
debian will likely need to vut over to it sooner rather than later.
What about running commands having set:
export LD_ASSUME_KERNEL=2.2.5
or LD_ASSUME_KERNEL=2.2.5
regards,
Mike
On Thu, Nov 06 2003 at 21:59,
GOTO Masano
GOTO Masanori wrote:
> We're encountering #218657. This bug says many programs become
> unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> architecture. We all debian-glibc developers can't access such
> machine, so could anyone try to reproduce and track this problem?
I setup a chr
On Fri, Nov 07, 2003 at 09:52:56AM -0700, Kevin Rosenberg wrote:
> GOTO Masanori wrote:
> > We're encountering #218657. This bug says many programs become
> > unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> > architecture. We all debian-glibc developers can't access such
> > machi
On Fri, Nov 07, 2003 at 05:24:17PM +0100, Claus Fischer wrote:
>
> Package: libc6
> Version: 2.3.2-9
>
>
> The shell command 'sleep 1' gives an 'illegal instruction' error.
> As you can see below, apparently on an stmxcsr. (I don't speak
> assembler very well :-) This is with the current 'testin
To _really_ have a working 2.6 based system the libc should be NPTL aware;
debian will likely need to vut over to it sooner rather than later.
What about running commands having set:
export LD_ASSUME_KERNEL=2.2.5
or LD_ASSUME_KERNEL=2.2.5
regards,
Mike
On Thu, Nov 06 2003 at 21:59,
GOTO Masano
GOTO Masanori wrote:
> We're encountering #218657. This bug says many programs become
> unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> architecture. We all debian-glibc developers can't access such
> machine, so could anyone try to reproduce and track this problem?
I setup a chr
Package: libc6
Version: 2.3.2-9
The shell command 'sleep 1' gives an 'illegal instruction' error.
As you can see below, apparently on an stmxcsr. (I don't speak
assembler very well :-) This is with the current 'testing' glibc.
Very likely a libc problem.
Apparently someone's encountered that
On Fri, Nov 07, 2003 at 09:52:56AM -0700, Kevin Rosenberg wrote:
> GOTO Masanori wrote:
> > We're encountering #218657. This bug says many programs become
> > unusable when libc6 2.3.2.ds1-8 + kernel 2.6 is used on amd64
> > architecture. We all debian-glibc developers can't access such
> > machi
On Fri, Nov 07, 2003 at 05:24:17PM +0100, Claus Fischer wrote:
>
> Package: libc6
> Version: 2.3.2-9
>
>
> The shell command 'sleep 1' gives an 'illegal instruction' error.
> As you can see below, apparently on an stmxcsr. (I don't speak
> assembler very well :-) This is with the current 'testin
At Thu, 06 Nov 2003 12:33:16 -0600,
Debian Bug Tracking System wrote:
> > reassign 219352 libc6
> Bug#219352: should depend on libmikmod2
> Bug reassigned from package `xmms' to `libc6'.
> Unless libmikmod2 is installed, xmms fails to start with:
>
> libmikmod.so.2: cannot open shared object file
Package: libc6
Version: 2.3.2-9
The shell command 'sleep 1' gives an 'illegal instruction' error.
As you can see below, apparently on an stmxcsr. (I don't speak
assembler very well :-) This is with the current 'testing' glibc.
Very likely a libc problem.
Apparently someone's encountered that
At Thu, 06 Nov 2003 12:33:16 -0600,
Debian Bug Tracking System wrote:
> > reassign 219352 libc6
> Bug#219352: should depend on libmikmod2
> Bug reassigned from package `xmms' to `libc6'.
> Unless libmikmod2 is installed, xmms fails to start with:
>
> libmikmod.so.2: cannot open shared object file
Package: libc6-dev
Version: 2.3.2.ds1-10
Severity: normal
Followup-For: Bug #203303
It looks like it is also a problem on mipsel, arm and sparc.
arm:
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:29,
from
Package: libc6-dev
Version: 2.3.2.ds1-10
Severity: normal
Followup-For: Bug #203303
It looks like it is also a problem on mipsel, arm and sparc.
arm:
In file included from /usr/include/linux/byteorder/little_endian.h:11,
from /usr/include/asm/byteorder.h:29,
from
On Fri, Nov 07, 2003 at 04:13:24AM +, Colin Watson wrote:
> I'd recommend that the glibc close/reopen war in question be handled
> better from now on. Anthony did say "contact the upstream copyright
> holder", and I think it would be a *very good idea* for somebody to do
> that instead of furth
On Fri, Nov 07, 2003 at 04:13:24AM +, Colin Watson wrote:
> I'd recommend that the glibc close/reopen war in question be handled
> better from now on. Anthony did say "contact the upstream copyright
> holder", and I think it would be a *very good idea* for somebody to do
> that instead of furth
44 matches
Mail list logo
