PROTECTED];
debian-glibc@lists.debian.org
Subject: Re: 2.3.2-1
At Tue, 13 May 2003 22:28:32 +0200,
Matthias Klose wrote:
please wait two days, until
I get it.
- gcc-3.3 moves to testing (uploaded for mipsel, currently building
for mips)
- gcc-defaults is uploaded to make gcc
BTW, what is the status for hppa? If it's not so much, I would like
to help you, AFAIC.
The problem is not an issue of development, I have all the patches
required to _build_ glibc. It's down to the nitty-gritty right now. I
need help from more eyes that know hppa assembly _well_. I'm
BTW, what is the status for hppa? If it's not so much, I would like
to help you, AFAIC.
The problem is not an issue of development, I have all the patches
required to _build_ glibc. It's down to the nitty-gritty right now. I
need help from more eyes that know hppa assembly _well_. I'm
At Tue, 13 May 2003 09:31:05 -0700,
Randolph Chung wrote:
A lot of people use ix86. It's majority. It may be radical
statement, but I think ix86 user's priority is higher than minor
architecture breakage. Many users don't know except for ix86 :-)
this is not a democracy :) if we are
At Tue, 13 May 2003 22:28:32 +0200,
Matthias Klose wrote:
please wait two days, until
I get it.
- gcc-3.3 moves to testing (uploaded for mipsel, currently building
for mips)
- gcc-defaults is uploaded to make gcc to point to gcc-3.3
- binutils-2.14.90.0.1 is uploaded (and we can
At Mon, 12 May 2003 12:58:27 -0400,
Carlos O'Donell wrote:
Well, this seems an idea, but still many bugs are remained in BTS.
Debian glibc stores up many bugs.
So what? As long as they're known to be fixed by 2.3.2, what's the
big deal? Stalling all of sarge for the sake of closing
At Mon, 12 May 2003 20:19:46 -0700,
Randolph Chung wrote:
I don't know what a good answer is. How much do we compensate for
porters who don't take care of their toolchain?
One of the great things about the Debian release policy IMO is that we
do a good job at really supporting the dozen
A lot of people use ix86. It's majority. It may be radical
statement, but I think ix86 user's priority is higher than minor
architecture breakage. Many users don't know except for ix86 :-)
this is not a democracy :) if we are going to go the route of x86 is
95% of the users, so let's treat
Hiho ..
On Wed, May 14, 2003 at 01:18:50AM +0900, GOTO Masanori wrote:
One of the great things about the Debian release policy IMO is that we
do a good job at really supporting the dozen or so architectures we
claim to support. We do not compromise and say that it's ok to release
Goto,
please wait two days, until
- gcc-3.3 moves to testing (uploaded for mipsel, currently building
for mips)
- gcc-defaults is uploaded to make gcc to point to gcc-3.3
- binutils-2.14.90.0.1 is uploaded (and we can enable gcc-3.3 and
glibc for x86-64)
I don't know if we should wait for
Hi,
On Mon, May 12, 2003 at 12:32:34PM +0900, GOTO Masanori wrote:
* mips/mips: Guido Guenther [EMAIL PROTECTED] sent us the patch to
build correctly on these architectures.
I've built with gcc-3.3 (3.2 miscompiles two testcases) and binutils
2.14.90.0.1 (fixes symbol visibility
At Mon, 12 May 2003 10:50:04 +0200,
Guido Guenther wrote:
On Mon, May 12, 2003 at 12:32:34PM +0900, GOTO Masanori wrote:
* mips/mips: Guido Guenther [EMAIL PROTECTED] sent us the patch to
build correctly on these architectures.
I've built with gcc-3.3 (3.2 miscompiles two
At Mon, 12 May 2003 12:32:34 +0900,
GOTO Masanori wrote:
I plan to upload 2.3.2-1 within a few days. This is the major update
and it fixes a lot of bugs. You can download 2.3.2-1 from:
http://people.debian.org/~gotom/2.3.2-1/
Side note: from my test on i386, linux kernel 2.5.68 has a
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
On Mon, May 12, 2003 at 07:51:04PM +0900, GOTO Masanori wrote:
BTW, is mips64 biarch issue similar to sparc64/amd64/s390x? If so,
Arnd and Gerhard works (that merges *-64 archs into one lib64c
package) can be applied to mips64?
It's a bit more complicated. We have actually three ABIs o32
On Mon, May 12, 2003 at 11:50:28PM +0900, GOTO Masanori wrote:
At Mon, 12 May 2003 13:28:47 +0200,
Guido Guenther wrote:
On Mon, May 12, 2003 at 07:51:04PM +0900, GOTO Masanori wrote:
BTW, is mips64 biarch issue similar to sparc64/amd64/s390x? If so,
Arnd and Gerhard works (that merges
At Mon, 12 May 2003 10:56:21 -0400,
Daniel Jacobowitz wrote:
On Mon, May 12, 2003 at 11:50:28PM +0900, GOTO Masanori wrote:
At Mon, 12 May 2003 13:28:47 +0200,
Guido Guenther wrote:
On Mon, May 12, 2003 at 07:51:04PM +0900, GOTO Masanori wrote:
BTW, is mips64 biarch issue similar to
At Mon, 12 May 2003 12:17:13 +0100,
James Troup wrote:
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
On Tue, May 13, 2003 at 12:12:25AM +0900, GOTO Masanori wrote:
- What is the status or direction to use o32/n32/n64?
What do you mean exactly? O32 is the current abi. I wasn't able to build
a triple ABI glibc yet. I intend to look into it once I have more time
but don't hold your breath.
-
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_
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 it
was in unstable? A large portion of
I cheer each architecture porters to work it :-) (If not, I should
work it, well...)
Fixing Glibc is hard :)
- There is no mips/mipsel public machine. Thus I can't compile on
_all_ architectures. Sometimes I hit the problem that dchroot
environment is not well prepared (ex:
Well, this seems an idea, but still many bugs are remained in BTS.
Debian glibc stores up many bugs.
So what? As long as they're known to be fixed by 2.3.2, what's the
big deal? Stalling all of sarge for the sake of closing a bunch of
bugs in one package seems like a stunningly pyrrhic
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
I don't know what a good answer is. How much do we compensate for
porters who don't take care of their toolchain?
One of the great things about the Debian release policy IMO is that we
do a good job at really supporting the dozen or so architectures we
claim to support. We do not compromise
25 matches
Mail list logo
