This was fixed incorrectly, and causes regressions. The sparcv9
optimized assembler routines are no longer enabled, amongst other
things. The change should be flat out reverted.
The error message originally reported in the build was due to a
bug in Sparc binutils, it wasn't turning on multiply
The problem is how sha1.cc codes the SHA1 transform, it illegally
casts the on-stack workspace buffer to a type requiring more
alignment than 'workspace' is actually declared to have.
This only shows up recently because gcc-4.6 now does a really
aggressive optimization where it gets rid of the wo
From: Jesper Nilsson
Date: Mon, 17 Jan 2011 10:05:57 +0100
> On Mon, Jan 17, 2011 at 07:07:55AM +0100, David Miller wrote:
>> Ugh, and I just noticed that include/linux/klist.h does this fixed
>> alignment of "4" too, where is this stuff coming from? It's
>&
From: Ben Hutchings
Date: Thu, 04 Mar 2010 14:59:20 +
> On Thu, 2010-03-04 at 10:19 +0100, Josip Rodin wrote:
> [...]
>> Fortunately David Miller came to the rescue and personally debugged the
>> problem on one of the buildds, and fixed the problem. His solution, that
&
From: Julien Cristau
Date: Sun, 24 May 2009 15:52:20 +0200
> I plan to revert it for lenny r2, and if time permits I'll try to
> make the xserver-xorg package generate an xorg.conf with Driver set
> to fbdev instead..
Indeed, that's likely to work much better.
--
To UNSUBSCRIBE, email to deb
From: Julien Cristau
Date: Wed, 25 Feb 2009 13:41:08 +0100
> On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote:
> > On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote:
> > > No, I would have said that if time is tight at least we can use
> > > "fbdev&quo
From: Josip Rodin
Date: Mon, 9 Feb 2009 09:45:27 +0100
> But then, it would have been completely your prerogative to respond to that
> simply by saying - DTRT and go upgrade X, patching old X is a waste of my
> time, and I guess nobody wanted to risk hearing that answer? :)
No, I would have said
From: Josip Rodin
Date: Mon, 9 Feb 2009 09:20:39 +0100
> On Sun, Feb 08, 2009 at 04:58:08PM -0800, David Miller wrote:
> > So you're saying that X working is more important than machines
> > actually booting at all? These priorities are wrong.
>
> When N (where N >
From: Jurij Smakov
Date: Sun, 8 Feb 2009 23:05:21 +
> To give a little bit of background, this patch was supposed to fix
> http://bugs.debian.org/500358. Bug trail contains all the gory
> details, but the crux of the problem (as I understand it) is the
> following: the commit [0] into the
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 13:56:14 -0700 (PDT)
> net: Unbreak userspace which includes linux/mroute.h
Actually, now that I can see how this linux/pim.h thing
is used by both linux/mroute.h and linux/mroute6.h I have
decided to fix the problem in a
From: Jose Calhariz <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 14:43:20 +0100
> I am sending this email again because I have more information.
Thanks for your report.
Yoshifuji-san, nothing in linux/pim.h should be exported to userspace.
The previous location, linux/mroute.h, EXPLICITLY __KERNEL
From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sat, 27 Oct 2007 20:09:47 +0200
> titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s!
> [aptitude:13375]
> [ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC:
> 0042f7d0 Y: Not tainted
> [ 2427.506821]
From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 04:03:44 +0100
>
>
>
> I think things got worse with 2.6.24...
> The machine shoots itself now, I guess by running cron jobs or so.
>
> [29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC:
> 0042f928 Y:
Upstream security advisory for this issue has been posted at
http://www.bugzilla.org/security/2.16.10-nr/
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System
Moritz Muehlenhoff wrote on 12/27/05 8:30 PM:
this has been assigned CVE-2005-4534 by MITRE. Please refer to it
in the 2.16.11 release notes.
Thanks! I'm not getting any traction on trying to push a full release
out for this. Seems nobody cares about the 2.16 branch anymore (it's
two stabl
FYI, the reporter was mistaken, the upstream bug was NOT public. He
could see it because he reported it. It might as well be now. (I just
removed the security flag from it, so it is indeed public now).
The patch he supplied (while a good start) was stated to be untested,
and we also determi
16 matches
Mail list logo
