On Wed, May 04, 2011 at 02:30:35PM +0200, Aurelien Jarno wrote:
Le 04/05/2011 07:42, Steve M. Robbins a écrit :
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
which is fixed (sort of) by commit 0354e355
On Sat, May 07, 2011 at 12:25:15PM +0200, Aurelien Jarno wrote:
On Wed, May 04, 2011 at 02:30:35PM +0200, Aurelien Jarno wrote:
Le 04/05/2011 07:42, Steve M. Robbins a écrit :
P.S. I tried rebuilding glibc myself locally, but gcc also segfaults
in the process :-(
Are you sure it is
On 05/04/2011 11:48 AM, Raphael Hertzog wrote:
While I can sympathize with this (it's what I want as a developer), it's
certainly not a good idea in Debian in general: we have many derivatives
taking unstable/testing at various points in time, and we also want to
make testing generally usable
On Wed, 04 May 2011, Russ Allbery wrote:
Jon Dowland j...@debian.org writes:
On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
While I can sympathize with this (it's what I want as a developer),
it's certainly not a good idea in Debian in general: we have many
derivatives
Le mercredi 04 mai 2011 à 14:58 +0100, Jon Dowland a écrit :
So it's best if you consider unstable always in production-mode by default.
I disagree with this. We expect *our* users of sid to use things like
apt-listbugs and to be wary of blindly upgrading. I think we should hold
Hi,
On Wed, May 04, 2011 at 10:56:27PM -0500, Steve M. Robbins wrote:
And furthermore, even if Debian chooses to fix this, upstreams will
be forced to eventually cater to the default glibc behavior for every
other libc distro out there that does not have their own fix (and
non-libc OS's
On Thu, May 05, 2011 at 09:56:03AM +0200, sean finney wrote:
Maybe valgrind already does checks like this [...]
It does.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
On Wed, 2011-05-04 at 14:06:41 +0200, Raphael Hertzog wrote:
On Wed, 04 May 2011, Aurelien Jarno wrote:
So how do you plan to detect bugs if you never enable a feature?
Really abort()ing is not a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour.
On Thu, May 05, 2011 at 08:55:50AM +0200, Josselin Mouette wrote:
[snip]
The point is not to paralyze Debian development, but you should never
upload to unstable a package that you *know* is broken. Uploading to
unstable means “this should be good enough for a stable release, but it
hasn’t
On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
which is fixed (sort of) by commit 0354e355 (2011-04-01).
Oh my word. So glibc 2.13 breaks
On Wed, 04 May 2011, Adam Borowski wrote:
I'd instead propose to sacrifice a tiny amount of cycles to check for
overlapping and abort()ing so buggy code can be fixed. Random instability
is the worst kind of error, a clean crash is easy to fix. Heck, we can even
make a change just before
Le 04/05/2011 11:48, Raphael Hertzog a écrit :
On Wed, 04 May 2011, Adam Borowski wrote:
I'd instead propose to sacrifice a tiny amount of cycles to check for
overlapping and abort()ing so buggy code can be fixed. Random instability
is the worst kind of error, a clean crash is easy to fix.
Steve M. Robbins st...@sumost.ca wrote:
Hi,
I'm with Linus on this: let's just revert to the old behaviour. A
tiny amount of clock cycles saved isn't worth the instability.
Tiny amount?! The optimized memcpy() variants that break shitty code
bring a 4 to 5x speedup on the processors they've
Adam Borowski kilob...@angband.pl writes:
On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
I'm with Linus on this: let's just revert to the old behaviour. A
tiny amount of clock cycles saved isn't worth the instability.
I'd instead propose to sacrifice a tiny amount of
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
Steve M. Robbins st...@sumost.ca wrote:
Hi,
I'm with Linus on this: let's just revert to the old behaviour. A
tiny amount of clock cycles saved isn't worth the instability.
Tiny amount?! The optimized memcpy() variants
On Wed, 04 May 2011, Aurelien Jarno wrote:
Le 04/05/2011 11:48, Raphael Hertzog a écrit :
So it's best if you consider unstable always in production-mode by
default.
So how do you plan to detect bugs if you never enable a feature?
Really abort()ing is not a nice behaviour, it would be way
Le 04/05/2011 14:06, Raphael Hertzog a écrit :
a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without experiencing a non working-application.
Printing a warning on a thing that is potentially used everywhere,
Le 04/05/2011 07:42, Steve M. Robbins a écrit :
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
which is fixed (sort of) by commit 0354e355 (2011-04-01).
Oh my word. So glibc 2.13 breaks random binaries that
Le mercredi 04 mai 2011 14:23:19, Aurelien Jarno a écrit :
Le 04/05/2011 14:06, Raphael Hertzog a écrit :
a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without experiencing a non working-application.
On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
While I can sympathize with this (it's what I want as a developer), it's
certainly not a good idea in Debian in general: we have many derivatives
taking unstable/testing at various points in time, and we also want to make
testing
Aurelien Jarno aurel...@aurel32.net writes:
Le 04/05/2011 14:06, Raphael Hertzog a écrit :
a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without experiencing a non working-application.
Printing a warning
Le 04/05/2011 16:02, Goswin von Brederlow a écrit :
Aurelien Jarno aurel...@aurel32.net writes:
Le 04/05/2011 14:06, Raphael Hertzog a écrit :
a nice behaviour, it would be way better to print
a warning and fallback to a correct behaviour. Users can then report the
problems without
Jon Dowland j...@debian.org writes:
On Wed, May 04, 2011 at 11:48:33AM +0200, Raphael Hertzog wrote:
While I can sympathize with this (it's what I want as a developer),
it's certainly not a good idea in Debian in general: we have many
derivatives taking unstable/testing at various points in
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
Steve M. Robbins st...@sumost.ca wrote:
Hi,
I'm with Linus on this: let's just revert to the old behaviour. A
tiny amount of clock cycles saved isn't worth the instability.
Tiny amount?! The optimized memcpy() variants
On Wed, May 04, 2011 at 01:34:15PM +0200, sean finney wrote:
And furthermore, even if Debian chooses to fix this, upstreams will
be forced to eventually cater to the default glibc behavior for every
other libc distro out there that does not have their own fix (and
non-libc OS's where this
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote:
Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
which is fixed (sort of) by commit 0354e355 (2011-04-01).
Oh my word. So glibc 2.13 breaks random binaries that happened to
incorrectly use memcpy() instead of
26 matches
Mail list logo
