For users of stable #Fedora#Linux releases out there that might encounter a regression with #LinuxKernel 6.8-* (now or once it becomes stable):
My #kernel vanilla mainline #copr now keeps all daily snapshots around that were build during the merge window. That way you won't have to bisect over the whole range of the merge window to find the culprit , as you can narrow down the bisection range easily with these really available packages.
Side note: yes, you can do the same with the rawhide builds found in koji as well. But those are not vanilla, which sometimes makes a difference (but in the Fedora case often does not).
2/ …kernel vanilla repos for Fedora finally started shipping the kernel-tools stuff recently (e.g. bpftool, perf, ...).
Furthermore, new mainline releases from now on are shipped in the stable repo again: it seems that's what people want/expect. It was like that until two or three years ago, but then I stopped doing that because the Linux stable team sometimes was slow to pick up maintenance for new mainline releases; but that situation improved a lot, so I'm rolling back.
There is just a problem: it doesn't really work well currently.
If you for example try to enable the mainline copr it will fail; if you do that on Fedora workstation, you will get the latest package from the mainline-wo-merge copr, as intended. With stable-rc it works, but you get an outdated kernel.
@siosm, if you have a minute, do you maybe have an idea how to work around the problem the toot above briefly mentions?
The problem happens because "rpm-ostree overlay replace --experimental --from repo=…" afaics does not handle copr runtime dependencies. Those are needed to properly support the kernel vanilla repositories, as the right packages for users of some of the coprs are sometimes found in coprs that are a runtime dependency.
I used that as base for some tests and the instruction linked in the initial toot, just omitted the "--freeze".
And for mainline-wo-mergew this will work correctly for round about 9 our of 10 weeks (e.g. when a new mainline release is out before the first stable release comes out, which then should be installed from the stable-rc and stable repos.
if you have a minute, maybe you can help me with one of my annoying problems:
some local services I run send mail to thl@{localhost,localhost-localdomain,foobar.fritz.box,foobar}, which obviously will cause trouble if that mail is forwarded to an external box without address rewriting.
How to I fix this without listing all the possible domain names manually, as I might not know them in advance?
A simple
thl baz@example.com
in /etc/postfix/generic afaics doesn't to the tick.
remind me again: smart host is a relayhost in the local network that that then delivers mail locally or forwards it to another relayhost at my ISP?
Yeah, that how I ideally would things to work as well and even had them at some point, but for good or bad reasons (some trouble?) I started to struggle with it again. Maybe it was due to the problems outlined here:
and Ansible: yeah, that at one point was the plan and I even got there to a certain degree, but then something more important came up.
It's always the "time spend on learning a new tool and staying on top of it" vs "time saved by the tool". And for my case I doubt that the ratio is good.
That won't work with dhcp based hostnames I fail to anticipate; and it also feels kinda tedious/stupid to do so for "(all users) * (all hostnames I can anticipate)"
Things many #Linux guides on the net forget to mention:
In which way the given instructions impact how the system behaves differently from then on – both in general and especially wrt to security fixes.
Hence a quick heads-up:
If you followed the guide linked below to install #LinuxKernel 6.6 on #Fedora, you might want to disable the #kernel vanilla repos' "mainline-wo-mergew" copr and activate the "stable" copr[1].