Re: Automated udeb build [was: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)]
On Sun, Nov 06, 2005 at 06:02:56PM +0100, Frans Pop wrote:
> (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.
Indeed.
> > 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.
Ok.
> > 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.
Thanks.
> I guess you mean one person doing all architectures? I suppose mipsen and
> m68k would be excluded from this and keep the current method?
Not necessarily, the packages would remain as they are (for now at least), and
are built and uploaded together. If one of those packages fail to build or
something, then it doesn't get uploaded. mips/mipsel is problematic because
Thiemo did not yet merge them into the common kernel, but m68k should be
rather ok. What made you pick those 2/3 arches for exclusion ?
Also, i think the proposal only affects 2.6 kernels for now, as the 2.4/2.2
kernels are still not using a common tree, and we want them to go away for
etch anyway, if possible.
> How would this actually work? Download the kernel image package, unpack it
> somewhere and take the modules from there?
Indeed, we are just repackaging these modules, nothing arch-specific there. I
would like to have Colin's comment, since he told me he already did that.
> 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?
Not necessarily, i don't think this would be wanted behavior, you upload only
the packages which are ok, and retry later for the others or something. The
main thing is to eliminate human intervention as much as possible for
automated things, since not only human intervention is error prone, but it may
cause delays when said human is doing something else, or could be doing
something better.
> 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?
Yes, but then on the other hand, this is something where a better interaction
between the kernel team and the d-i team would help, after all, before you
even notice the modules did change or is missing, or whatever, we first had to
add the configuration options, which is something which has to be done for
each new kernel option anyway. This can also be error checked just before the
upload generation or something. Also, we will build -rc kernels in
experimental, and a experimental build of those .udebs may also help. Lot of
things are possible here.
> 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 hope so, but the aim would also be to avoid the double work of said porters,
having to do it once to port the kernel configs, and twice to update the
.udebs.
Friendly,
Sven Luther
Reply to: