stable_* tags missing for 6.6.y kernels

[peat-psuwit]

Describe the bug

I'm integrating RPi Linux into NixOS. I've seen the announcement that RPi OS is receiving Linux 6.6, and I've seen that the default branch of this repository is now rpi-6.6.y. However, I don't see a tag corresponding with this update. The last tag available is stable_20240124 and that corresponds to 6.1.73-based kernel.

Currently a workaround is to download the latest RPi OS image one from raspberrypi.com and mount the image to inspect usr/share/doc/linux-image-6.6.20+rpt-rpi-v8/changelog.Debian.gz which specifies the commit. However, this is inconvenient.

This is probably related to https://github.com/RPi-Distro/repo/issues/368

Steps to reproduce the behaviour

Go to https://github.com/raspberrypi/linux and select "Release > \<n> tags". Select the latest tag, then commit, then "Browse Files". Open "Makefile" and notice that it's still 6.1.y kernel.

Device (s)

Raspberry Pi 4 Mod. B

System

N/A

Logs

No response

Additional context

No response

[HinTak]

I am having a similar issue - RPi-Distro/firmware doesn't have the stable_* tags and still showing last kernel as 20230405, v6.1.

[popcornmix]

@XECDesign should this be getting tagged when creating a new apt kernel?

[XECDesign]

I'm all for that, but the kernel is not always built from this repo, so we need to come up with a consistent workflow.

[HinTak]

It would be nice to know/document when " ...is not always built from this repo", too.

One possibility is to have unrelated branches in a repo I.e. some branches are simply something else with no shared ancestry.

[XECDesign]

It would be nice to know/document when " ...is not always built from this repo", too.

Sometimes development for new hardware happens in an internal repo or on a different branch and we may need to build a kernel package for internal testing before it gets shipped. Then commit histories diverge and we need to make a decision about what we ship and how we make it public.

One possibility is to have unrelated branches in a repo I.e. some branches are simply something else with no shared ancestry.

I think some of the tags may be commits which are not actually on a branch, so they're partially serving this purpose.

[iluminat23]

For us this is a big deal. We provide a custom kernel (with RT and some customization). We try to use a released RaspberryPi kernel as base. And this gives us a real hard time. When rpi-6.6.y is a development playground, we have even more risk of shipping a buggy kernel.

[febus982]

I have wrapped the logic to rebuild the deb packages using the kernel sources downloaded via apt here: https://github.com/febus982/rpi-kernel

It's still pretty basic:

• builds only the v8 kernel, but it should be easy to make this more reusable
• it doesn't override yet the kernel LOCALVERSION (so it has to overwrite the official image and packages)

I don't know how much time I can dedicate to it but maybe it will help someone. (contributions are welcome 😃 )

[XECDesign]

@popcornmix There's currently no tag for last week's release. I was about to add one, but I'm not sure about the date. Should it match the firmware tag, the date of the commit or something else?

[popcornmix]

I think the tag commit in linux repo should match the file extra/git_hash in stable tree for firmware repo. Whether we use the date from 1.20240424 or 1.20240423 is somewhat arbitrary (the kernel was unchanged between the two firmware tags - the extra commit was just from firmware tree for creating the release tarball).

I think I prefer using the date that the stable kernel was built. I'm not sure a 1:1 mapping between linux tree and firmware tree makes sense (as there may be a firmware bump without a kernel bump, as in this case).

I've pushed stable_20240423 tag.