[Bug 2046250] Re: [FFe][needs-packaging] raspi-utils (replacement for raspberrypi-userland)

[Dave Jones]

Review for the current version in ppa:r41k0u/raspi-utils:

TL;DR mostly good, I'm going to make some changes and sponsor, but most
are extremely nit-picky!

The upgrades are fixed, great! Standards, and architectures also fixed,
all good. All the lintian warnings are fixed, which is fantastic but I'm
going to make one major change here:

The warning about eepflash.sh is fixed by renaming it to eepflash.
There's two ways of doing this, and unfortunately the wrong one is
picked here which is to add a patch that removes the old binary and
inserts a new one. The reason this is a bad idea is that if the script
changes upstream the patch is now broken, and it's hard to verify that
the script being added by the patch matches the script removed. The
"right" way of doing this is to let the install phase happen as usual,
but override the filename afterwards. For example, in d/rules:

override_dh_auto_install:
        dh_auto_install
        mv debian/raspi-utils-eeprom/usr/bin/eepflash.sh debian/raspi-utils-eeprom/usr/bin/eepflash

However, in this case I'd rather "not" fix it and just override the
lintian warning. While it's a bit ugly to have this one binary with a
.sh extension, it is upstream's choice and any guides covering the usage
of this tool on the internet will be referring to eepflash.sh (as will
any installed docs and manpages). So from that perspective I'd rather we
just override the warnings.

On the subject of lintian warning overrides, and this is entirely a nit-
pick of my own, I'm going to add a brief comment in the files covering
*why* the override is in place. Sometimes this is just to note a false-
positive, or just to document that we're actively following something
upstream are doing, but I like to have something next to an override so
future maintainers will know the reason we're suppressing a warning
instead of doing something else about it.

Other trivial nit-picks: no need to ship gbp.conf when it's not going to
point at anything useful for us, and I'm going to tweak the d/watch file
to use some of the substitutions like @PACKAGE@ and @ANY_VERSION@
because there's no need to hard-code that stuff.

Uploading with version adjusted to -0ubuntu1 suffix as this isn't
upstream in Debian so we need to ensure a version there can override
ours. Subscribing ubuntu-archive as this will hit the new queue.
Removing [FFe] prefix as that was left over from earlier cycles.

** Summary changed:

- [FFe][needs-packaging] raspi-utils (replacement for raspberrypi-userland)
+ [needs-packaging] raspi-utils (replacement for raspberrypi-userland)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to raspberrypi-userland in Ubuntu.
https://bugs.launchpad.net/bugs/2046250

Title:
  [needs-packaging] raspi-utils (replacement for raspberrypi-userland)

Status in raspberrypi-userland package in Ubuntu:
  Confirmed

Bug description:
  [ Impact ]

  URL: https://github.com/raspberrypi/utils
  License: GPL-2 or BSD-3-Clause
  Notes:

  The raspberrypi-userland package was deprecated upstream some time ago
  (prior to noble in fact), with the majority of the utilities
  (dtoverlay, dtmerge, vcgencmd, vclog, etc.) moving to the raspi-utils
  package. Recent versions of rpi-eeprom-update (which we need to pull
  in to fix other issues, e.g. LP: #2078806) now include functionality
  introduced since the move to raspi-utils.

  We should include raspi-utils in oracular with all the appropriate
  Breaks + Replaces bits to handle replacing the existing package.

  [ Test Plan ]

  * With EEPROM boot firmware from current Ubuntu:

  * Build the package in ppa:waveform/raspi-utils
  * Test the function of the package on supported models. Specifically, on Pi 5, Pi 4, CM4, and at least one of the 2/3/3+ generation
  * Especially: check vcgencmd, dtoverlay, dtparam still operate as expected as these are the major components used by other utilities

  * Update EEPROM boot firmware to current RaspiOS version and repeat
  above tests.

  [ Regression Potential ]

  Given the nature of some of the utilities (e.g. low-level mailbox
  communication in vcmailbox, device-tree overlay manipulation in
  dtoverlay and dtparam), there is a reasonable risk that we may break
  functionality by upgrading. However, these utilities tend to move in
  step with the RPi firmware, and if we are updating that firmware,
  these utilities should be updated too in order to minimize the risk of
  regression.

  Nonetheless, the test plan should be followed on a wide variety of
  models, and as much functionality should be tested as possible, with
  old and new firmware to spot potential regressions.

  [ Addendum ]

  Note to self: don't forget to update the seeds

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/raspberrypi-userland/+bug/2046250/+subscriptions