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 yo
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 0
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 usab
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, 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 behavi
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
--
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-
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
> dow
On Wed, 04 May 2011, Russ Allbery wrote:
> Jon Dowland 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 ta
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 t
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins" 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 b
Jon Dowland 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 time, and
Le 04/05/2011 16:02, Goswin von Brederlow a écrit :
> Aurelien Jarno 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
Aurelien Jarno 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 on a thing t
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
> test
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.
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 binari
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
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
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote:
> "Steve M. Robbins" 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 b
Adam Borowski 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 cycles to check f
"Steve M. Robbins" 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 been written
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 f
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 w
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
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 me
26 matches
Mail list logo
