Skip to content

Bump Kernel to 6.12.85#4216

Open
ChrisIgel wants to merge 2 commits into
linuxkit:masterfrom
ChrisIgel:kernel-6.12.85
Open

Bump Kernel to 6.12.85#4216
ChrisIgel wants to merge 2 commits into
linuxkit:masterfrom
ChrisIgel:kernel-6.12.85

Conversation

@ChrisIgel
Copy link
Copy Markdown
Contributor

- What I did
Bump the kernel version to 6.12.85

- How I did it
Follow the docs/kernels.md guide

- Description for the changelog
Bump the kernel version to 6.12.85
fixes #4215

ChrisIgel added 2 commits May 3, 2026 11:49
Signed-off-by: Chris Irrgang <chris.irrgang@gmx.de>
Signed-off-by: Chris Irrgang <chris.irrgang@gmx.de>
@danrzs
Copy link
Copy Markdown
Contributor

danrzs commented May 14, 2026

If (big if) I were to undertake some CI automation work to auto bump kernels to latest would this PR serve as a good template for what has to be done?

I note you are only updating the 6.12 line, presumably because that’s the latest major.minor version supported? I assume all tests etc point at the latest major.minor?

@deitch
Copy link
Copy Markdown
Collaborator

deitch commented May 14, 2026

If (big if) I were to undertake some CI automation work to auto bump kernels to latest would this PR serve as a good template for what has to be done?

That is a "big if" because it is a big lift. I did a lot of work a few years back to make updating the kernels much easier, which should help a lot, but it still requires a chunk of work.

The whole process is listed in docs/kernels.md, both for a new patch version (6.12.z) and a new series (6.y); major version is the same as new series, from the perspective of linuxkit.

If you can do that, by all means.

Keep in mind that building a new kernel version can be slow, especially when cross-building for architectures. That may or may not hit up against GHA job time limits.

@deitch
Copy link
Copy Markdown
Collaborator

deitch commented May 14, 2026

@ChrisIgel looks like the "build packages" job failed.

@danrzs
Copy link
Copy Markdown
Contributor

danrzs commented May 14, 2026

That is a "big if" because it is a big lift.

yeah i understand its a lot (i mean, look at this pr) but its also very close to something I've recently done in $company with renovate+github actions. i have to wonder if an 80% solution would at least make the process easier. if its not wanted (or im missing a hilarious amount of complexity here) thats reasonable

Keep in mind that building a new kernel version can be slow, especially when cross-building for architectures.

i was consider i could bypass that as its own check and instead simply open a pr with the latest, allowing the normal pr workflow to work normally. it appears i may need to do more reading though

@deitch
Copy link
Copy Markdown
Collaborator

deitch commented May 14, 2026

yeah i understand its a lot (i mean, look at this pr) but its also very close to something I've recently done in $company with renovate+github actions

That is something I would like to see. Funny how many of us have worked for that same place, $company 😆

i have to wonder if an 80% solution would at least make the process easier.

It absolutely would. I am in favour!

@ChrisIgel
Copy link
Copy Markdown
Contributor Author

@ChrisIgel looks like the "build packages" job failed.

But only because the new kernel version wasn't built and published yet, which is a manual step currently, or am I mistaken?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mitigation for copy fail CVE

3 participants