Open peat-psuwit opened 5 months ago
I am having a similar issue - RPi-Distro/firmware doesn't have the stable_*
tags and still showing last kernel as 20230405, v6.1.
@XECDesign should this be getting tagged when creating a new apt kernel?
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.
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.
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.
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.
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:
v8
kernel, but it should be easy to make this more reusableI don't know how much time I can dedicate to it but maybe it will help someone. (contributions are welcome 😃 )
@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?
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.
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 isstable_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