On Sat, Mar 31, 2007 at 11:29:23PM +0200, Christoph Anton Mitterer wrote:
> Steve Langasek wrote:
> > Well, there's no reason that someone can't use iommu=soft when booting the
> > installer, as well. So perhaps it would be best to clone that bug and
> > include this information in the installatio
Steve Langasek wrote:
> Well, there's no reason that someone can't use iommu=soft when booting the
> installer, as well. So perhaps it would be best to clone that bug and
> include this information in the installation guide or errata?
>
Yes that's a good idea.
I assume it would be also a probl
On Sat, Mar 31, 2007 at 07:59:44PM +0200, Christoph Anton Mitterer wrote:
> Andreas Barth wrote:
> > BTW, we intended to have frequent kernel uploads to proposed-updates,
> > and frankly speaking, I personally don't mind to already have a newer
> > kernel in proposed-updates during the release, but
On Sat, Mar 31, 2007 at 03:58:49AM -0700, Steve Langasek wrote:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
>
> > As I've told you in my email before I just tested your patch with the
> > following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> > testin
On Sat, Mar 31, 2007 at 08:18:26PM +0200, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [070331 16:03]:
> > The ideal would have been a framework where we could build new kernels and
> > have it integrated within a few days only. I gave a speach about this at
> > FOSDEM, of how we could
* Sven Luther ([EMAIL PROTECTED]) [070331 16:03]:
> The ideal would have been a framework where we could build new kernels and
> have it integrated within a few days only. I gave a speach about this at
> FOSDEM, of how we could use the initramfs incremental nature, to separate
> fully the kernel mo
Andreas Barth wrote:
> BTW, we intended to have frequent kernel uploads to proposed-updates,
> and frankly speaking, I personally don't mind to already have a newer
> kernel in proposed-updates during the release, but that's something I
> want to have signed-off by Martin.
The main problem with the
On Sat, Mar 31, 2007 at 03:11:09PM +0200, Andreas Barth wrote:
> * Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]:
> > On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > > I would say (although I'm by any means not kernel expert) that your
> > > patch looks good and I
* Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]:
> On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> > I would say (although I'm by any means not kernel expert) that your
> > patch looks good and I _strongly_ recommend to include it in etch r0 (!!)...
> > You're the re
Steve Langasek wrote:
> But regardless, there are no plans
> for another kernel update before etch r0, and including one is likely to
> delay the release. I'm of the opinion that this bug does not justify a
> delay at this point.
>
Uhm, sad to hear this...
> With the consent of the kernel
On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote:
> As I've told you in my email before I just tested your patch with the
> following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
> testing, of course on an amd64 system):
> - The patch applies without problems
Hi Steve.
As I've told you in my email before I just tested your patch with the
following results (used linux-source-2.6.18 (2.6.18.dfsg.1-12) from
testing, of course on an amd64 system):
- The patch applies without problems
- The kernel compiles with it without problems (at least with my config)
clone 404148 -1
reassign -1 release-notes
tags 404148 etch-ignore
tags -1 -patch
thanks
Since no one was able to test the provided patch, linux-2.6 2.6.18.dfsg.1-12
has been uploaded to unstable without it, which means fixing this has missed
the last kernel upload for etch r0.
That leaves this as
On Mon, Mar 12, 2007 at 11:25:13PM -0700, Steve Langasek wrote:
> So regrettably, this bug went more or less unnoticed on the 'kernel'
> pseudopackage until now, and it does appear (based on the upstream
> discussion) to affect the etch kernels. And in addition to it being noticed
> after the uplo
So regrettably, this bug went more or less unnoticed on the 'kernel'
pseudopackage until now, and it does appear (based on the upstream
discussion) to affect the etch kernels. And in addition to it being noticed
after the upload of 2.6.18.dfsg.1-11, there also doesn't seem to be a real
upstream fi
Package: kernel
Severity: critical
Justification: causes serious data loss
Hi everybody.
I'm currently (together with others) investigating in a severe data
corruption problem that at least many users might suffer from.
A short description, when you validate lots of GBs over and over with
md5sum
16 matches
Mail list logo