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

Re: 2.6.12 upload

On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote:
> Thiemo Seufer <ths@networkno.de> writes:
> > Andres Salomon wrote:
> > [snip]
> >> >   It is IMHO not realistic to expect the rest of the world to wait for
> >> >   some obscure subarchitecture.
> >> 
> >> Who said we're going to wait for some obscure subarchitecture?  We're
> >> going to keep working on kernels until we freeze for etch, at which point
> >> the subarchitectures have a limit amount of time to catch up.
> >
> > The problem is the ongoing development in unstable. It is e.g. not
> > possible to build debian-installer for that subarch and upload it
> > if its kernel isn't already/still in unstable.
> >
> >
> > Thiemo
> Actualy there are 2 problems:
> 1. Slow archs will keep the kernel-source from migrating to
> testing. That is if those archs are still testing blockers.
> I think this can seriously harm the amount of testing the kernel gets.

Suelry this is a broader problem realating to buildds in general,
if they aren't fast enough, they need more resources. We can help
this to some extent by trying to cut down on the number of flavours
floating around, especially on slower arches. However, the kernel
is by no means the largest package in Debian (I believe OpenOffice.Org
builds in arm take a full week) and this doesn't seem to be a major
problem in Debian at large.

> 2. Each kernel-image-di-<arch> source needs the right kernel-image
> version and source for its architecture to be present in the archive
> to be GPL compliant.
> This is only a problem for the archive software to keep track
> of. Someone has to write code for this.
> The D-I build should be using only the linux-kernel-di udebs if I'm
> not mistaken. As long as they are available D-I should keep building.
> Or did I miss something and the linux-kernel-di packages will
> disapear into the main kernel-source package?

Firstly, I don't agree that this is neccessary for GPL compliance
in any way whatsoever, however I do accept that some people believe that
it is. To keep those people happy, kernel-images should depend on
kernel-tree-X.Y.Z-N and everything works just fine - that is, the
kernel-image can be reproduced verbatim ecen if the kernel source
package increases N.


Reply to: