[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Scheduling 2.6.17-1



On Mon, Jun 19, 2006 at 12:06:25AM +0200, Sven Luther wrote:
> On Sun, Jun 18, 2006 at 11:58:26PM +0200, Frederik Schueler wrote:
> > Hi,
> > 
> > On Sun, Jun 18, 2006 at 11:47:49PM +0200, Sven Luther wrote:
> > > What about :
> > > 
> > >   We upload linux-2.6 2.6.17 ASAP, and if 2.6.16 is finally the way to go, we
> > >   upload linux-2.6.16 or linux-2.6.etch, and propagate this one to testing.
> > 
> > The problem is: we need a kernel >> 2.6.15 in testing ASAP (2.6.15 is
> > really old, and d-i needs a new kernel for the next release candidate).
> > 
> > 2.6.17 is likely to need 3-4 weeks before it can be considered as a 
> > testing candidate. 2.6.16 should already be in testing, but it did not 
> > migrate due to various reasons. Thus, we should just try and have a good
> > version of it added to testing, without the pressure to beating 2.6.17 into 
> > shape within a week.
> 
> BTW, do we already have code to chose the gcc version ? I rebuilt 2.6.16-5
> yesterday, with gcc 4.1, and it is apparently not ok to use it with the .udeb
> already in testing or something, or at least i keep getting strange md5sum
> errors on .udeb downloads on a p505 box.

Yeah, istr having an issue like that as well.  We should probably keep the
2.6.16 compiler hardcoded to whatever is the default in etch when we
upload (its still gcc-4.0 today, right)?  This way we won't
unintentionally break module loading with updates to
stable/stable-security when rebuilding in a pristine etch environment.
-- 
dann frazier



Reply to: