(Creating a new thread for this subject) On Friday 04 November 2005 12:46, Sven Luther wrote: > On Fri, Nov 04, 2005 at 12:21:29PM +0100, Frans Pop wrote: > The proposal was only to do automated builds when new kernel packages > are there, to avoid the disparate uploads for different arches, since > .udeb builds are nothing but repackaging, there is nothing arch-dep in > there, or could be removed as needed. I think Colin already builds them > all together on the same box, since he mentioned it was not needed to > have the kernels installed in the past. This sounds like a very useful goal. > The issues where with building all the .udebs from all the arches from > the same package, or including them in the upstream kernel source > package, or doing one .udeb per module. Yes, that is what I've been assuming you were talking about, not knowing about this proposal. Sorry about the misunderstanding. > What i am proposing here is only the minimal semi-automated rebuild of > all the kernel .udeb packages by the same person, so nothing ground > breaking, but avoiding the need of 12 different person to get involved. OK. Some questions/comments. I guess you mean one person doing all architectures? I suppose mipsen and m68k would be excluded from this and keep the current method? How would this actually work? Download the kernel image package, unpack it somewhere and take the modules from there? We currently see there are delays for some architectures in getting the kernels onto the mirrors (like sparc still not being uploaded despite it being built). You also could have an FTBS for one or more arches. Would this mean that building the udebs would have to be delayed until the latest version is available for all architectures? On minor kernel updates I can see this working as it is unlikely module selections have to be made. On major updates (like 2.6.12 to 2.6.14), I would expect porters still have to go over changes in available modules. I'd think this would need to be done before a first new kernel udeb build could take place? So to summarize, IMO we will still need the individual porters to work on kernel udeb packaging in the future. Does this new setup allow for enough flexibility so that not all arches suffer if one arch is delayed? > > I would be very interested in seeing a proposal that does deal with > > the issues that were raised in the past. Hope to see this proposal > > posted to the list soon so we can comment. > > Yep, a recapitulation of all the older posted issues on some wiki page > would be a good first step, i think. Ack.
Attachment:
pgpw2FwPpDUqv.pgp
Description: PGP signature