Notices by Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org), page 2

2/ Side note for users of #Fedora #Linux:

#LinuxKernel 6.12 is now available for all Fedora releases in the "stable" #copr of my #kernel vanilla repositories.

For install instructions, see https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/stable/ and https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

In addition to the regular kernel package that copr as of today started shipping a dedicated #realtime kernel which has #PREEMPT_RT enabled. Install it by running:

$ sudo dnf install kernel-rt

#Linux 6.12 is out. For a list of new features see:

* This short LWN story: https://lwn.net/Articles/997958/ (screenshotted)

* Two detailed stories from LWN: https://lwn.net/Articles/990750/ & https://lwn.net/Articles/991301/

* The kernelnewbies page: https://kernelnewbies.org/Linux_6.12

See also the announcement from @torvalds:

https://lore.kernel.org/lkml/CAHk-=wgtGkHshfvaAe_O2ntnFBH3EprNk1juieLmjcF2HBwBgQ@mail.gmail.com/

'"No strange surprises this last week, so we're sticking to the regular release schedule, and that obviously means that the merge window opens tomorrow."'

#kernel #LinuxKernel

5/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers *reverted* Uwe's changes that made the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro "until the legal stuff is sorted out":

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427

Wondering why that happened – did they only notice now that the drivers do not compile any more because they use GPL-onlyed symbols, which are inaccessible for any non-GPLv2-compatible module?

CC: @waldi

4/ TWIMC and for the record:

Werner Sembach from @tuxedocomputers now merged Uwe's proposed changes that make the drivers provide the right license to the #Linux #kernel's MODULE_LICENSE()[1] macro. 👏

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21#note_0294911d6ab1408f96fa73e062851920e16b4460

(side note: I suspect the kernel will now taint itself as "proprietary" when loading these drivers, but haven't tried)

CC: @waldi

6/ To follow up:

There are now patches under discussion upstream to '"teach the [#Linux #Kernel's] module loader that these modules [from @tuxedocomputers ] are proprietary despite their declaration to be GPLv2 compatible "until the legal stuff is sorted out". "'

https://lore.kernel.org/all/20241114103133.547032-4-ukleinek@kernel.org/t/#u

CC: @waldi #LinuxKernel

@gregkh @mxk

many thx for the insights! 👍

I sometimes wish I could follow what happens in the Android world more closely, but there are only so many hours in a week… 😟

@mxk are you sure?

I mean, sure, Google will ensure kernel <-> Android Userland will work.

But how hard is it for Android vendors that have huge kernel patches applied to support the hardware? Patches never upstreamed? Patches from a BSP that the chip vendor maybe never forward ported to support newer kernels and/or android versions?

Argh. 🥴

I (and @torvalds iirc as well) tell everybody "a revert to fix a #LinuxKernel #regression is nothing bad, it's often done to provide more time to fix the problem; once you did so, just resubmit the change."

And now I just found this in the #Linux #Kernel's documentation[1]:

'"[…] having a patch pulled as the result of a failure to fix a regression could well make it harder for you to get work merged in the future. […]"'

Argh. 🥴

[1] https://docs.kernel.org/process/6.Followthrough.html

@jann 6.12 is the next Longterm kernel, as it's highly unusual these days when a devel cycle is not 63 or 70 days long[1]. 6.13 thus will be out on January 20th or 27th – or one week later each, if we for some reason get a 6.12-rc8.

[1] see screeshot of https://docs.google.com/spreadsheets/d/1_yH7lFmZxAoSWrtsd8tGu3befG4zIcMnytB1ml4pQQM/edit?gid=1170907286#gid=1170907286&range=A130 below

3/ It got even stranger: it seems @tuxedocomputers provided the wrong license to the #LinuxKernel's MODULE_LICENSE()[1] macro either by accident or on purpose. 🧐

@waldi pointed that out earlier today elsewhere in this thread; PWM maintainer Uwe Kleine-König a little later submitted a bug report asking this to be fixed:

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/merge_requests/21

[1] they proclaim it's GPL, which according to the #Linux #kernel's docs means "GPLv2" (either -only or -or-later), when in fact the code is GPLv3

2/ side note: wondering if they require a CLA that allows re-licensing for any meaningful contributions, otherwise they can not upstream contributed code (and wouldn't be allowed to ship the drivers pre-compiled themselves).

@thibaultmol @tuxedocomputers

Yeah, it's well known that Open Source has always works so well, because it allows authors to control their code.

Ohh, wait, no! It was the other way around: Open Source works so well because people do not have control and thus are able to bring it to levels that seemed unreachable earlier! 😬

TIL: @tuxedocomputers released #Linux #kernel drivers for their machines under the #GPLv3, which makes it impossible for competitors and distros to ship them pre-compiled, as that license is incompatible with the #LinuxKernel's #GPLv2 only license.

They did this purposely, allegedly to "keep control of the upstream pacing" – and want to re-license the code while upstreaming.

https://github.com/tuxedocomputers/tuxedo-keyboard/issues/61

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/issues/137

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#regarding-upstreaming-of-tuxedo-drivers

https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#regarding-upstreaming-of-tuxedo-drivers

@torvalds on the removal of some [russian] entries from the MAINTAINERS file:

https://lore.kernel.org/all/CAHk-%3DwhNGNVnYHHSXUAsWds_MoZ-iEgRMQMxZZ0z-jY4uHT%2BGg@mail.gmail.com/

"'It's entirely clear why the change was done, it's not getting reverted [...]

[…] the "various compliance requirements" are not just a US thing.

If you haven't heard of Russian sanctions yet, you should try to read the news some day. […]

[…] I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too."

2/ Ohh, and if you haven't seen this related post from @monsieuricon, you might want to go and check it out, too:

https://social.kernel.org/objects/860ef93c-229b-4070-8ee6-cb80d1f51337

'"[…] I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore […]"'

2/ @kees replied to the "linus-next" proposal from Sasha and raised a few points I fully agree with, as that proposal felt a bit off for me.

https://lore.kernel.org/all/792F4759-EA33-48B8-9AD0-FA14FA69E86E@kernel.org/

"'Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

[…]

Why not just use linux-next? […]

[…] have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good. […]"

#Linux #kernel #LinuxKernel

linus-next: improving functional testing for to-be-merged [#linux #kernel] pull requests

https://lore.kernel.org/all/ZxZ8MStt4e8JXeJb@sashalap/

"'[…] Linus Torvalds expressed concerns about the quality of testing that code receives before he pulls it. The subsequent discussion side-tracked to the testability of linux-next, but we didn't directly address Linus's original concern about pre-pull testing quality.

In an attempt to address the concerns, we're trying out a new "linus-next"
tree […]"

#LinuxKernel

@ljs @kees @vbabka

Well, good points, but fwiw, afaiui only patches that *were* reviewed by one of the official maintainers are supposed to be included in -next. To quote Stephen from https://lore.kernel.org/linux-next/20240716083116.27f179bd@canb.auug.org.au/

"'You will need to ensure that the patches/commits in your tree/series have
been:
[…]
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window."'

@vbabka and @ljs, that "Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem." from @kees reminded me of a question you might be able to help out with:

From a quick look it seems to me that the "mm-unstable" branch is in -next (via "mm-everything"). Does that contain stuff for the next merge window only, or more experimental stuff as well? It looks like the latter to me.

@ljs @kees @vbabka

eating data is always a risk spectrum (even in stable release there is a risk that it happens) -- and depending on how risky something looks people then decide what they use/test: stable, stable-rc, mainline outside the merge window (that's me currently), mainline all the time, -next.

The less likely the "might eat data" risk is perceived in -next, the more likely people will be willing to help with testing it.