Bug#779616: debian-cd: broken debian-testing-$arch-netinst.iso generation?
[ Writing this off-line again while travelling so I can't check things
directly on pettersson etc. ]
Hi KiBi,
On Tue, Mar 03, 2015 at 03:47:12PM +0100, Cyril Brulebois wrote:
>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).
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"
>> 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).
OK, thanks for checking that.
>> 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?
>I certainly didn't touch anything on pettersson, or anything remotely
>involving debian-cd as far as I can remember.
Yup.
>> 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.
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.
>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.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Reply to: