[Summary]
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.
I'll need to discuss and co-ack with other MIR Team members and
also need security to have a word.
For now call it "ok enough to get security review", but there are
enough todos listed for you to start right away - for that I'll also
mark it incomplete. Set it back to new once the mentioned TODOs are
done for re-evaluation.
This does need a security review, so I'll assign ubuntu-security
List specific binary packages to be promoted to main: rpi-eeprom
Required TODOs:
- Get Foundations-bug subscribed to the package(s)
- 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:
Unpacking rpi-eeprom (7.8-0ubuntu2) ...
Setting up linux-firmware-raspi2 (1.20200601+arm64-0ubuntu3) ...
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package linux-firmware-raspi2 (--configure):
installed linux-firmware-raspi2 package post-installation script
subprocess returned error exit status 1
Setting up binutils-common:arm64 (2.35-3ubuntu1) ...
Setting up libctf-nobfd0:arm64 (2.35-3ubuntu1) ...
Setting up libraspberrypi0 (0~20200520+git2fe4ca3-0ubuntu2) ...
dpkg: dependency problems prevent configuration of rpi-eeprom:
rpi-eeprom depends on linux-firmware-raspi2 (>= 1.20190819); however:
Package linux-firmware-raspi2 is not configured yet.
dpkg: error processing package rpi-eeprom (--configure):
- 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?
- 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.
Recommended TODOs:
- Please investigate if it makes sense to be arch:all since it depends on
arm only packages:
rpi-eeprom : Depends: libraspberrypi-bin but it is not installable
Depends: linux-firmware-raspi2 (>= 1.20190819) but it is not installable
- Please clarify the Focal situation, the same version is stuck in proposed
there as well.
- Any chance to add some tests verifying the functional integrity of the package
to run at build or autopkgtest time?
- Please consider updating to a newer version before you SRU things to >=Focal
[Duplication]
OK:
We don't have this package or a similar function. Also The Internet is full
of people asking for it - so it is important nad not otherwise available.
There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
Only libraspberrypi-bin out of raspberrypi-userland which is part of this MIR
- no -dev/-debug/-doc packages that need exclusion
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking (well roms, but nothing that this rule tried to avoid)
Problems:
- The ROMs are all prebuilt. Usually this is a "hard no" as Debian packages
shall be servicable and buildable from source so one knows what is in there.
OTOH packges of similar scope like intel-microcode behave no different :-/
Functional maintenance will be your job so you only can make your own job
harder by not having sources, but this needs a security review to make sure
they consider this serviceable.
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
Problems:
- changes SW stacks below the control of the latter Linux system.
This needs a security evaluation.
[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
These are common issues with such low level things, but how would a drive
by contributor test anything. Is there a chance to get the file
test/test-rpi-eeprom-config working in a virtual environment and add some
guidance (or even an autopkgtest) to do that?
[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok
- Debian update history is non existant, since it is only in raspian - but ok there.
- Ubuntu update history is too new to decide
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean (for a rom build)
- Does not have Built-Using
Problems:
- the current release is not packaged, recently they bumped from 7.8 (what
we have to 7.14 and from there quickly to 9.0). It seems ok to stabilize
it at the current stage and update afterwards.
- 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?
Examples: drop rpi-eeprom-images dependency, add flashrom suggest,
debian/patches/python3.patch, ... and add reasons for those things please.
- The VCS is unpopulated, please update and push changes there
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
Problems:
- no incautious use of malloc/sprintf, well I can't know
Since these are blobs to me :-/
- no embedded source copies (but embedded binaries)
[Summary]
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.
I'll need to discuss and co-ack with other MIR Team members and
also need security to have a word.
For now call it "ok enough to get security review", but there are
enough todos listed for you to start right away - for that I'll also
mark it incomplete. Set it back to new once the mentioned TODOs are
done for re-evaluation.
This does need a security review, so I'll assign ubuntu-security
List specific binary packages to be promoted to main: rpi-eeprom
Info: /github. com/raspberrypi /rpi-eeprom
In this cases this isn't from Debian but from Raspbian and the upstream
is https:/
Required TODOs: raspi2 (1.20200601+ arm64-0ubuntu3) ... raspi2 (--configure): raspi2 package post-installation script common: arm64 (2.35-3ubuntu1) ... git2fe4ca3- 0ubuntu2) ... raspi2 (>= 1.20190819); however: raspi2 is not configured yet.
- Get Foundations-bug subscribed to the package(s)
- 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:
Unpacking rpi-eeprom (7.8-0ubuntu2) ...
Setting up linux-firmware-
Error: missing /boot/firmware, did you forget to mount it?
dpkg: error processing package linux-firmware-
installed linux-firmware-
subprocess returned error exit status 1
Setting up binutils-
Setting up libctf-nobfd0:arm64 (2.35-3ubuntu1) ...
Setting up libraspberrypi0 (0~20200520+
dpkg: dependency problems prevent configuration of rpi-eeprom:
rpi-eeprom depends on linux-firmware-
Package linux-firmware-
dpkg: error processing package rpi-eeprom (--configure):
- 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?
- 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.
Recommended TODOs: raspi2 (>= 1.20190819) but it is not installable
- Please investigate if it makes sense to be arch:all since it depends on
arm only packages:
rpi-eeprom : Depends: libraspberrypi-bin but it is not installable
Depends: linux-firmware-
- Please clarify the Focal situation, the same version is stuck in proposed
there as well.
- Any chance to add some tests verifying the functional integrity of the package
to run at build or autopkgtest time?
- Please consider updating to a newer version before you SRU things to >=Focal
[Duplication]
OK:
We don't have this package or a similar function. Also The Internet is full
of people asking for it - so it is important nad not otherwise available.
There is no other package in main providing the same functionality.
[Dependencies] userland which is part of this MIR
OK:
- no other Dependencies to MIR due to this
Only libraspberrypi-bin out of raspberrypi-
- no -dev/-debug/-doc packages that need exclusion
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking (well roms, but nothing that this rule tried to avoid)
Problems:
- The ROMs are all prebuilt. Usually this is a "hard no" as Debian packages
shall be servicable and buildable from source so one knows what is in there.
OTOH packges of similar scope like intel-microcode behave no different :-/
Functional maintenance will be your job so you only can make your own job
harder by not having sources, but this needs a security review to make sure
they consider this serviceable.
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
Problems:
- changes SW stacks below the control of the latter Linux system.
This needs a security evaluation.
[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
These are common issues with such low level things, but how would a drive rpi-eeprom- config working in a virtual environment and add some
by contributor test anything. Is there a chance to get the file
test/test-
guidance (or even an autopkgtest) to do that?
[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok
- Debian update history is non existant, since it is only in raspian - but ok there.
- Ubuntu update history is too new to decide
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean (for a rom build)
- Does not have Built-Using
Problems: patches/ python3. patch, ... and add reasons for those things please.
- the current release is not packaged, recently they bumped from 7.8 (what
we have to 7.14 and from there quickly to 9.0). It seems ok to stabilize
it at the current stage and update afterwards.
- 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?
Examples: drop rpi-eeprom-images dependency, add flashrom suggest,
debian/
- The VCS is unpopulated, please update and push changes there
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
Problems:
- no incautious use of malloc/sprintf, well I can't know
Since these are blobs to me :-/
- no embedded source copies (but embedded binaries)