Hi, Steve McIntyre <steve@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). > As such, we also use sid udebs for debian-installer, as that should > match what we'll be getting from the daily d-i builds which are built > using sid. Are you sure that the kernel there is old? If so, that's > the bug I think. It's difficult for me to check exactly right now what > that kernel version is. I extracted the kernel from the iso, and looked at its version string. The guy who reported that issue to me also mentioned that (even if non publicly, and I still haven't seen him open a proper bug report). > 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) I certainly didn't touch anything on pettersson, or anything remotely involving debian-cd as far as I can remember. > >I find the doc in the parent directory[3] quite confusing anyway: > >| These images are produced every week, normally on a Monday, but this may > >| vary. They include: > >| * The latest debian-installer build (currently the "sid" daily builds of the installer) > > > > 3. http://cdimage.debian.org/cdimage/weekly-builds/ > > > >It's either a daily build (from d-i.debian.org), or d-i from sid. > > ACK. That's old wording, and has always been confusing. Given we don't > tend to upload to the archive like normal packages anyway, it's best > to just remove the "sid" mention altogether I think. Ditto the > mentions of sid etc. in the daily-builds area coule do with fixing up > I think? 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. 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. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature