Michael Stone <mst...@debian.org> wrote: >On Mon, Sep 12, 2022 at 10:10:33AM -0500, David Wright wrote: >>Well, my focus would be on two things: (a) the change in compatibility >>level in debhelper in the middle of stable's lifetime > >That would not have ordinarily happened, and probably shouldn't have >happened in this case. Other non-minimal-security changes were backed >out for bullseye (namely the change to os-prober behavior) but this was >either overlooked or not realized to be a significant change. Usually a >stable update package would be modified from the version in stable >rather than backported from unstable, but in this case there were no >intermediate versions in unstable and it was probably thought safer to >use the package which had been tested in unstable rather than starting >over and potentially introducing a new bug. That probably was even true, >as the problem was identified during the test period on unstable -- but, >unfortunately, the priority of the bug didn't bubble up. I think this is >just one of those cases where mistakes happen (in this case, several >that aligned in an unfortunate way) and regardless of how hard we >(humans) try to avoid them sometimes we don't.
Yup, you've nailed it. We've had a stack of security bugs that needed fixing in grub, and I chose to move both buster and bullseye forwards to 2.06 rather than try and backport all the fixes to older releases and hope/pray that they applied sensibly. Grub is very much a moving target and a *huge* codebase with a lot of patches, for historical reasons. I didn't pick up on the packaging bug here, and unfortunately it made it into the bullseye stable release. I tested my grub build on a number of platforms and architectures, but that didn't include Xen. We *really* have a dearth of Xen experience among the maintainers, and that's not helping here. I'm building a new unstable package (2.06-4) right now with Valentin's patch applied, and once I've uploaded that I'll do a new bullseye package too. -- Steve McIntyre, Cambridge, UK. st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews