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 <steve@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. steve@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss
Reply to: