Re: Bringing the 2.6.13 (and beyond) kernel to sid, solving ramdisk generations issues and stuff.
On Sat, Oct 15, 2005 at 01:13:31PM +0200, Sven Luther wrote:
> On Sat, Oct 15, 2005 at 01:07:38PM +0200, Bastian Blank wrote:
> > On Sat, Oct 15, 2005 at 12:19:04PM +0200, Sven Luther wrote:
> > > the plan for solving the ramdisk issues is done in three stages, current svn
> > > 2.6.13 packages implement stage 1, i have patches for both initrd-tools and
> > > initramfs-tools in svn, and the yaird folk adapted it for yaird, so we may go
> > > ahead and upload those nextly (if it could be in by monday, that would be
> > > nice). I will work on the last stage, the kernel-package patch, this WE, and
> > > do an NMU since Manoj is unavailable for the next times and asked us to do so.
> >
> > initramfs-tools waits for mklibs.
>
> Well, we can go ahead with yaird for now, what is the mklibs issue ? Or can
> mklibs be disabled for now ?
>
> > > Broken but being worked on : s390
> >
> > Broken gcc or inline assembly, the IBM people expect the later. Hope
> > that I get a fix from them at monday.
>
> Ok, as said, if not, it can wait for -3.
>
> > > The other issue is that 2.6.14 is scheduled for release in the not so distant
> > > future, so we may skip uploading .13-3 to unstable and go for .14-1 directly,
> > > depending on status of newly introduced breakage in .14 and such.
> >
> > I vote for the later.
>
> Hehe, but this does suppose we create now another branch and start porting the
> patches and configs, i see nobody volunteering to do that.
I vote for not creating another breach. I vote for moving to .14
(or some -rc variant thereof). Its unlikelty to make much difference
on the initrd front and saves duplication of effort that is inherent
in the more branches approach.
--
Horms
Reply to: