Ian Campbell <i...@debian.org> (2015-03-05): > On Thu, 2015-03-05 at 12:25 +0100, Cyril Brulebois wrote: > > > OK. Assuming amd64 is working OK, I should check the rsync has not > > > broken - that seems to be the most likely cause right now. Thinking: > > > it would also be lovely to verify the versions of vmlinuz and the > > > kernel udebs in debian-cd at build time, and (optionally?) abort the > > > build if we know we're going to be making broken images. What do you > > > think? > > > > There's no way for us to know a breakage is going to happen. In this > > particular case the ABI is the same, say 3.16.0-4-amd64; the ABI is > > embedded in kernel udeb package names, so if the ABI matches, udebs are > > supposed to be compatible with the kernel. I'm not sure why that is not > > the case here (maybe the ABI doesn't cover or not completely udebs?). We > > really shouldn't enforce using the very same revision for kernel and > > module udebs, IMHO. > > Caveat: I might be talking out my a**e here... > > I think the ABI only guarantees you can load old modules into a newer > vmlinuz. In particular I think it doesn't guarantee that you can load > newer modules into an older vmlinuz (even if the ABI is the same). > > The ABI is there to stop your existing modules from breaking when you > update the kernel. > > IOW it is permissible for a module to gain a dependency on a new symbol > provided by a newer vmlinuz. > > This is why local netboot pxe infra sometimes breaks -- they have a > vmlinuz downloaded locally but are pulling udebs off the network, which > might therefore be newer. > > Please reread my caveat now though ;-)
Why do I forget about this all the time? :( Thinking a bit more about this: I think having weekly testing with everything from testing makes the most sense. We could have a separate, not-labelled-testing but rather “daily” or bleeding-edge or something in that spirit (but neither experimental nor sid) that picks d-i on d-i.d.o and udebs from sid. I'm not sure it would be reasonable to expect such a build on a daily basis (maybe by reducing the generated images to the bare minimum?), but then we would have a clear winner as far as the name goes… Mraw, KiBi.
signature.asc
Description: Digital signature
