Re: 2.6.12 upload
Horms <horms@debian.org> writes:
> 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.
No. I don't mean that m68k will take so long to compile. Well, it
does, but it will get there in time for medium or low
uploads. Critical uploads might stress it though. But an extra day
delay isn't too bad.
But what if the kernel FTBFS on mips? It needs to be looked into, the
mips patch needs to be updated, tested, merged and a new source needs
to be uploaded. If the looking into and fixing takes 3 month then that
will be 3 month without a new kernel in etch.
>> 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.
You've got the wrong packages.
The DI kernel udebs (linux-kernel-di-<arch> source) takes the
kernel-image deb, splits it up into kernel and several groups of
modules and builds udebs. There is no Depends there and can't be to
keep the kernel-image debs available.
kernel-image-di-arch ---source---> linux-kernel-di
|
magic
|
\/
kernel-tree-X.Y.Z-N <---depends--- kernel-image
|
\/
kernel sources
The 'magic' part is the problem.
MfG
Goswin
Reply to: