Karsten Merker <merker@debian.org> (2016-06-29): > I have in the meantime run further tests with u-boot > 2016.03+dfsg1-6 (including going through a full installation > process with a locally-built d-i) on an Olimex A20-Lime1 and on > an Olimex A20-SOM-EVB - none of them shows any freezes, > so I think we are clear to proceed with the release. Great, thanks. > If the release is built in a sid environment, from a purely technical > point of view it should be enough if u-boot 2016.03+dfsg1-6 is in sid. > The various platform-specific u-boot binary packages (e.g. > u-boot-omap, u-boot-sunxi) are a build-dependeny of d-i as the d-i > buildscripts use files under /usr/lib/u-boot to create the various > target-specifc images. ACK. > The only u-boot binary package that is used at d-i runtime (and called > by flash-kernel during kernel updates) is u-boot-tools, which hasn't > changed it contents between 2016.03+dfsg1-5 (in testing) and > 2016.03+dfsg1-6 (in unstable). OK, the u-boot-tools being used during installation part I had understood from some git grep, the contents (non-)change I didn't know about, thanks. > Nonetheless I would find it a cleaner solution to urgent > 2016.03+dfsg1-6 into testing. If somebody should try to re-install > u-boot from the package in testing on one of the affected systems, he > ends up with an unbootable system. This can of course be fixed by > putting the SD card into another computer and installing the u-boot > from unstable there, but IMHO we shouldn't ship known-broken > bootloader files in testing if we can avoid it. OK, I've just urgented the package, so it should migrate tomorrow morning. (Saw your mail a few minutes late for the 2200Z run.) KiBi.
Attachment:
signature.asc
Description: Digital signature