Steve McIntyre <st...@einval.com> (2015-03-05): > [ Writing this off-line again while travelling so I can't check things > directly on pettersson etc. ]
ACK. > On Tue, Mar 03, 2015 at 03:47:12PM +0100, Cyril Brulebois wrote: > >Steve McIntyre <st...@einval.com> (2015-03-03): > >> Hmmm. That's very odd. The weekly builds are currently set up to use > >> daily d-i builds rather than what's in the archive, and they've been > >> that way for a long time. > > > >I don't think that's a good idea. For one thing, there's no trust chain > >here (from d-i.d.o because http; and from git, because #746967). > > 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. > >> We've been using the daily d-i builds for a long time, to guard > >> against exactly this kind of breakage with kernel version > >> mismatches. Has something changed? > > > >Some archs are missing daily builds, because autobuilding in jessie is > >broken, but AFAICT missing builds are only: > > - arm64 > > - ppc64el > > - sparc > > > >(See http://d-i.debian.org/daily-images/daily-build-overview.html) > > 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. > >We probably should start by figuring out what d-i we want to embed (see > >first paragraph). Having (some, maybe not the whole set of) images with > >a daily d-i (if we can fix the trust chain) would be nice. But that > >really shouldn't be labelled “official testing images” as currently > >done. > > I'm definitely open to suggestions on what else we should be > providing. I'm not 100% sure the best way to go, though... > > 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… > >Being able to spin some weekly build (possibly manually) with what's in > >*sid* (i.e. not dailies) is nice to figure out whether we're going to > >end up with breakages if/when d-i/sid migrates to testing, before we > >build official release images. Not sure it gains us much compared to > >first migrating d-i/sid to testing and building images, though. > > Yeah :-/ We've done that in the past, and it's not that difficult to > configure debian-cd to do this. But IIRC it never really gave us much. OK… Mraw, KiBi.
signature.asc
Description: Digital signature
