Re: [Bug 1895137] Re: [MIR] rpi-eeprom
> > - Please consider updating to a newer version before you SRU things to > >=Focal > > Is it best at this point to fix the existing 7.8 upload, or reject that > and fix all this in a new 9.0 upload? Happy to do whichever is easier > from the MIR/security team's perspective. IMHO cancel what is there, get it right in Groovy or later and then SRU the correct thing. The usual reason is this, right now nothing is in Focal, so you can (under constraints) backport anything. But if you have 7.8+fixes there first and then plan to update to 9.0 this update would have to follow SRU rules. Which means you'd need to retain any behavior of the former version making it much harder for you. TL;DR: "Get it right first, SRU once afterwards" usually is the right approach -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895137 Title: [MIR] rpi-eeprom To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1895137] Re: [MIR] rpi-eeprom
> > - You refer to an empty VCS, having the changes commit-by-commit in this or > > another one (depending where you push) woud be great. Please fix the VCS > > entry to point at such a valid repo. > > Ah, I was under the misapprehension that the launchpad repo would be > populated by the git-ubuntu import (in other words the Vcs-Browser entry > was "pre-emptive"). As I'm not an uploader for this (or any) package, > would it be more correct to just remove that for now? Well, you'll maintain it somewhere atm - point there. It will be imported once it is in main (or could be whitelisted now) - then you could leave the current VCS entry. The problem is that in any case we will miss all the history as it never was in Debian to import from. Gladly you know racb to talk about options from here. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895137 Title: [MIR] rpi-eeprom To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1895137] Re: [MIR] rpi-eeprom
> Just to clarify, is this suggesting it should install cleanly on non-pi > arm hardware, but *then* refuse to work (with some appropriate error > message) or should it refuse to install at all e.g. at dependency > resolution time. I'd love to implement the latter but I've no idea how > (is there such a thing as a package that's only available to pi > images?). The former is rather more complex as it means fixing how > linux-firmware-raspi2 installs its boot firmware (which is something > that's been sat on my TODO list for yonks, but it means some rather > invasive flash-kernel changes where we're already carrying a huge > delta). Either way works, but I'm not aware of any differentiation beyond architecture that you can use. And since arm64/armhf can be so many different things I'd ask to get something into e.g. postinst that detects if it runs on the right HW and if it doesn't skips the rest. That way the binaries are available for evaluation but have no function. If there are other active bits/hooks, then yes you'd want to disable them as well in that case. We've had similar cases where a package makes no sense in a container context. But making it fail gracefully avoided people getting stuck with broken packages which can be a big problem especially for less experienced users. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895137 Title: [MIR] rpi-eeprom To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/1895137/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
