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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
