Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
On Thu, Mar 05, 2015 at 12:25:50PM +0100, Cyril Brulebois wrote: Steve McIntyre st...@einval.com (2015-03-05): We've had this discussion befire, surely? On pettersson we rsync things (over ssh) directly from d-i.d.o (dillon), so we don't depend on http or git. Or am I missing something new? (I can't see #746967 atm...) There's also an explicit warning in debian-cd if you grab things via plain http or ftp: echo WARNING WARNING WARNING WARNING WARNING WARNING echo $0: insecure download for d-i build: $DI_WWW_HOME echo WARNING WARNING WARNING WARNING WARNING WARNING The rsync part covers the former, but there's still a broken trust chain because of the latter. Right, I've just had a chance to look at that now. Ugh... :-( 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. ACK, I see your logic. In the past, we had the two different sets of daily images: * use the most recent testing version of d-i in tha archive * use the daily d-i builds from d-i.d.o (and other hosts before that) and then we'd switch the weekly images from one source to the other depending on how working/broken we thought each source was likely to be. Since the kernel team got much more active a few years back and kernel ABI changes have been much more common during the life of testing, using the most recent d-i release from the archive has had a much shorter working life than we used to have. Hence, we switched over to using the daily d-i builds as a base. This can be YA argument for more regular d-i uploads to the archive to fix that problem, of course. But we know how much work that involves. At the moment I feel what we have is just about the best thing we can get without that massive additional effort. It normally works for people, modulo the odd breakage from time to time like we've seen here. I guess we could stick to this once the trust issue is resolved. Daily builds will have to be changed one way or another anyway since it can't be implemented as done previously starting with jessie hosts… Right, yes. Anyone have any bright ideas yet on how to do that? -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308134848.go6...@einval.com
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
On Fri, Mar 06, 2015 at 06:51:46PM +0100, Cyril Brulebois wrote: Ian Campbell i...@debian.org (2015-03-05): 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. Right, that helps explain. Thanks Ian! 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. OK... Are we going to do more frequent d-i uploads to make sure that works, though? It looks like the changes for (daily) builds are going to force quite a lot of work on us here. I'm quite prepared to help with that when I'm back (and have more time!) in a week or so... 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… Right. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308135605.gp6...@einval.com
Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
Steve McIntyre st...@einval.com (2015-03-08): On Fri, Mar 06, 2015 at 06:51:46PM +0100, Cyril Brulebois wrote: Thinking a bit more about this: I think having weekly testing with everything from testing makes the most sense. OK... Are we going to do more frequent d-i uploads to make sure that works, though? I can't promise anything. Mraw, KiBi. signature.asc Description: Digital signature
Re: Providing (armhf) u-boot images together with d-i images?
Ian Campbell i...@debian.org (2015-01-07): On Fri, 2015-01-02 at 16:40 +0100, Cyril Brulebois wrote: Karsten Merker mer...@debian.org (2015-01-02): (Do your patches end up adding the correct Built-Using on u-boot?) No, they don't, but d-i does not do that for similar components on other platforms (syslinux/isolinux/grub) as well. Probably we should do that, but then it would have to be done for all platforms. Kibi? ISTR having proposed a patch to #700026 / #696418, but that wasn't commented upon. FWIW the patch in #700026 looks good to me as a starting point... OK, thanks. Pushed now: http://anonscm.debian.org/cgit/d-i/debian-installer.git/diff/?id=b4411bf Mraw, KiBi. signature.asc Description: Digital signature
