Please provide tagged firmware releases as you used to do

[gwolf]

This project used to tag its releases, which was very good for OS distributors other than Raspberry Pi OS. No newer releases have been tagged since April last year.

We (for Debian) prefer, if possible, not to take the firmware from arbitrary points, but to have you as the software providers tag us stability points. Do you think it is possible to continue providing "official" tags?

Thanks!

[timg236]

@gwolf Do you just use this for kernel binaries or just the firmware binaries?

The kernel binaries in our APT packages don't line up exactly with what would be the commit tag for the firmware release because they are built separately.

[popcornmix]

The current apt firmware is:

pi@pi5:~ $ apt policy raspi-firmware 
raspi-firmware:
  Installed: 1:1.20240306+ds-1+rpt1
  Candidate: 1:1.20240306+ds-1+rpt1
  Version table:
 *** 1:1.20240306+ds-1+rpt1 500
        500 http://buildbot.pitowers.org:3143 bookworm/main arm64 Packages
        500 http://buildbot.pitowers.org:3143 bookworm/main armhf Packages
        100 /var/lib/dpkg/status
     1.20220830+ds-1 500
        500 http://deb.debian.org/debian bookworm/non-free-firmware arm64 Packages
        500 http://deb.debian.org/debian bookworm/non-free-firmware armhf Packages

That corresponds with top commit on stable branch here.
I've pushed a tag (1.20240306) for that commit.

We can do that for future apt releases.

[gutoandreollo]

Thanks for the tags, and I see an actual "release" for the latest one.

Extra note, this is also useful for Arch Linux (either AUR packages, or ArchLinuxARM packages).

[popcornmix]

So the plan is stable branch of raspberrypi/firmware gets tagged.
The github action builds a release tarball that gets used by the raspi-firmware apt package in RPiOS (and can be used by other distributions).

@gwolf does this resolve this issue?

[gwolf]

@popcornmix, Thanks for the heads up! Yes, this is great, I am in the process of preparing a new upload to Debian.
@timg236, sorry for the long delay. I use this only for the firmware binaries, as we use mainline Linux kernel for systems running official Debian releases.

[XECDesign]

@gwolf Heads up that the release also has a tarball attached with the non-firmware files stripped out. You might not need your own +ds version. I'm using the following watch file for it:

version=4
opts="searchmode=plain,\
uversionmangle=s/%2B/+/g" \
https://api.github.com/repos/raspberrypi/firmware/releases?per_page=50 \
https://github\.com/[^/]+/[^/]+/releases/download/[^/]+/@PACKAGE@_([^"]+)\.orig\.tar\.xz

[gwolf]

XECDesign dijo [Mon, Apr 29, 2024 at 02:11:17AM -0700]:

@gwolf Heads up that the release also has a tarball attached with the non-firmware files stripped out. You might not need your own `+ds` version. I'm using the following `watch` file for it: ``` version=4 opts="searchmode=plain,\ uversionmangle=s/%2B/+/g" \ https://api.github.com/repos/raspberrypi/firmware/releases?per_page=50 \ ***@***.***@_([^"]+)\.orig\.tar\.xz ```

Thanks a lot! I will definitively look into this for our next release.