On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote: > Horms <[EMAIL PROTECTED]> writes: > > > On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote: > >> Thiemo Seufer <[EMAIL PROTECTED]> 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.
Yes, that is a problematic scenario. But if such a problem occurs, and it really is holding up the kernel for all arches, surely some time can be found to fix patch at the time. > >> 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. I don't follow why there is a problem with linux-kernel-di depending on kernel-tree-X.Y.Z-N. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
