> This one is hard to decide as it has binary blobs in the form of
> the RPI firmware. Usually for normal package that would be a denial
> reason, but other microcode delivering packages work the same way.

Just a quick note on this one, in case it changes anything: as rpi-eeprom is currently intended to migrate to multiverse I assumed it would be MIR'd to restricted rather than main (as you note: it primarily consists of the binary blobs for the second stage bootloader).

In contrast, libraspberrypi{-bin,0} contains no binary blobs and should indeed be targetted to main.

> - Get Foundations-bug subscribed to the package(s)

Now done for both rpi-eeprom and raspberrypi-userland

> - Even not being used there avoid packages to totally fail on install
>  and breaking apt thereby. Please get it to be gracefully-unusable there.
>  Raspbian only publishes for Pi, we do have more arm* models to support.
>  On non Pi arm* HW this is on install:
[snip]

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).

> - The Diff from 7.5-1 to our 7.8-0 can't be explained by the changelog.
>   It seems we have much more than just the new version.
>   Could you please ensure that the changelog clearly indicates what our Delta
>   over Raspbian is?

Will do (as you've probably guessed this all started out with 7.5 and I must've bungled the migration of the changelog while dealing with 7.7 then 7.8 (3 days later!).

> - 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?

> - Please investigate if it makes sense to be arch:all since it depends on
>  arm only packages:

Yup, that's definitely an issue - in fact that's the reason rpi-eeprom's stuck in proposed because the dependency (libraspberrypi-bin) is armhf/arm64 only. I've already fixed that in an upload for 8.0 to my PPA (https://launchpad.net/~waveform/+archive/ubuntu/eeprom), but of course that's now been superseded by 9.0!

> - Please clarify the Focal situation, the same version is stuck in proposed
>  there as well.

rpi-eeprom on Focal is currently awaiting the SRU of libraspberrypi{-bin,0} to Focal (LP: #1883111), but as mentioned above there's also the Arch: all issue. Still the intention is indeed to have this in the current LTS and Groovy (possibly Bionic as well given the Pi 4 is supported there, but additional bumps to the linux-firmware-raspi2 package may be needed there).

> - Any chance to add some tests verifying the functional integrity of the package
>  to run at build or autopkgtest time?

It should be possible to add their test script for autopkgtest usage (although it only exercises rpi-eeprom-config that's about as much as we could safely do). I'll get on with that.

> - 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.

> [Dependencies]
> OK:
> - no other Dependencies to MIR due to this
>   Only libraspberrypi-bin out of raspberrypi-userland which is part of this MIR

I think libraspberrypi0 is needed from raspberrypi-userland too as that's a dependency of libraspberrypi-bin