New set of #Gentoo #Linux Distribution Kernels (6.1.143, 6.6.96, 6.12.36, 6.15.5) is out. This set brings some major changes:

• I've backported a bunch of changes from sys-kernel/gentoo-kernel to sys-kernel/vanilla-kernel that were missing — notably wider architecture support.
• I've added default #RISCV configs to 6.12 (in addition to 6.15), since Fedora had them.
• All three packages are based off the baseline kernel tarball + upstream patch (vanilla-kernel used to fetch patch-level tarball every time, and gentoo-kernel* used genpatches for patch versions). This should reduce disk space and bandwidth use.
• All three packages now support verify-sig. Rather than verifying the uncompressed tarball signature, we now use upstream `sha256sums.asc` file to verify the compressed tarball and patch.
• sys-kernel/gentoo-kernel* now repackages genpatches. This means patchset that's much leaner and faster to apply (since we just fetch and use the combined upstream patch rather than including point patches). This also means that we are able to release Distribution Kernels before gentoo-sources are done.

The changes still need to be done to 5.15 and 5.10 branches — we're going to do for the next upstream releases of these.

A while ago, I've followed the example given by #Fedora and unbundled ensurepip wheels from #Python in #Gentoo (just checked — "a while ago" was 3 years ago). This had the important advantage that it enabled us to update these wheels along with the actual pip and setuptools packages, meaning new virtual environments would get fresh versions rather than whatever CPython happened to bundle at the time of release.

I had considered using our system packages to prepare these wheels, but since we were already unbundling dependencies back then, that couldn't work. So I just went with fetching upstream wheels from PyPI. Why not build them from source instead? Well, besides feeling unnecessary (it's not like the PyPI wheels are actually binary packages), we probably didn't have the right kind of eclass support for that at the time.

Inspired by @hroncok, today I've tried preparing new revisions of ensurepip packages that actually do build everything from source. So what changed, and why should building from source matter now? Firstly, as part of the wheel reuse patches, we do have a reasonably clean architecture to grab the wheels created as part of the PEP517 build. Secondly, since we're unbundling dependencies from pip and setuptools, we're effectively testing different packages than these installed as ensurepip wheels — and so it would be meaningful to test both variants. Thirdly, building from source is going to make patching easier, and at the very least enable user patching.

While at it, I've refreshed the test suite runs in all three regular packages (pip, setuptools and wheel — we need an "ensurepip" wheel for the last because of test suites). And of course, I hit some test failures in testing the versions with bundled dependencies, and I've discovered a random bug in #PyPy.

https://github.com/gentoo/gentoo/pull/42882 (yes, we haven't moved yet)
https://github.com/pypy/pypy/issues/5306

Like other large #FreeSoftware projects, #Gentoo developers have varying degrees of activity. There are some people who dedicate a lot of their free time to Gentoo, maintain hundreds of packages, participate in multiple areas. Then, there are people with narrower interests, lower commit counts, but they are still putting an effort and making Gentoo a better distribution — and that matters. But then, there is the tail.

There is a few of developers whose main talents seem to be 1) finding packages that require absolutely minimal maintenance effort, and 2) justifying their developer status with long essays. I mean, this is getting beyond absurd. It is not just "my packages are all up-to-date". It is not even "my packages require very low maintenance, that's why I'm not doing much". It is literally "I deliberately choose low-maintenance packages, so I don't have to do anything". But of course, all these people definitely need commit access to Gentoo, and show off their Gentoo developer badges, and it's *so damn unfair*.

And in the meantime, other developers are overburdened, and getting burned out. And they step down from more things. And who takes these things over? Of course, not the developers who just admitted to not having much to do…

One of the goals I've set for further development of #Python eclasses in #Gentoo was to avoid needless complexity. Unfortunately, the subject matter sometimes requires them. However, many of the functions added lately were already manually done in ebuilds for years.

We've started disabling plugin autoloading years ago. First we just did that for individual packages that caused issues. Then, for these where tests ended up being really slow. Finally, pretty much anywhere `python_test()` was declared. Doing it all manually was particularly cumbersome — all I needed for `EPYTEST_PLUGINS` is a good idea how to generalize it.

Similarly, `EPYTEST_XDIST` was added after we have been adding manually `epytest -p xdist -n "$(makeopts_jobs)" --dist=worksteal` — and while at it, I've added `EPYTEST_JOBS` to override the job count.

Perhaps `EPYTEST_TIMEOUT` wasn't that common. However, it was meant to help CI systems that could otherwise get stuck on hanging test.

Similarly, "standard library" version (like `3.9`) matching to `python_gen_cond_dep` was added after a long period of explicitly stating `python3_9 pypy3`. As an extra benefit, this also resolved the problem that at the time `pypy3` could mean different Python versions.

Here's the customary #introduction: i'm into #C and tolerate C++ on a daily basis at work, i've also used others like java, kotlin, python, PHP, etc and am curious about #COBOL, #AdaLanguage and #erlang.

My dislike of jenkins is only surpassed by my hate of githubactions and everything MS-related. AI is not I, only A. I'm interested in #selfhosted stuff but atm that's a VPS with some sites, which doesn't really count. For now #syncthing is quite useful and #wireguard is on the horizon once i reformat/reinstall my current #gentoo (i'll keep the root #ZFS aproach and am on the fence regarding #XFCE or #KDE), would be interesting to have a barebones #KVM/#QEMU running all the stuff and i digress.

kthxbai\0

So #Gentoo #Python eclasses are pretty modern, in the sense that they tend to follow the best practices and standards, and eventually deal with deprecations. Nevertheless, they have a long history and carry quite some historical burden, particularly regarding to naming.

The key point is that the eclasses were conceived as a replacement for the old eclasses: "distutils" and "python". Hence, much like we revision ebuilds, I've named the matching eclasses "distutils-r1" and "python-r1". For consistency, I've also used the "-r1" suffix for the remaining eclasses introduced at the time: "python-any-r1", "python-single-r1" and "python-utils-r1" — even though there were never "r0"s.

It didn't take long to realize my first mistake. I've made the multi-impl eclass effectively the "main" eclass, probably largely inspired by the previous Gentoo recommendations. However, in the end I've found out that for the most use cases (i.e. where "distutils-r1" is not involved), there is no real need for multi-impl, and it makes things much harder. So if I were naming them today, I would have named it "python-multi", to indicate the specific use case — and either avoid designating a default at all, or made "python-single" the default.

What aged even worse is the "distutils-r1" eclass. Admittedly, back when it was conceived, distutils was still largely a thing — and there were people (like me) who avoided unnecessary dependency on setuptools. Of course, nowadays it has been entirely devoured by setuptools, and with #PEP517 even "setuptools" wouldn't be a good name anymore. Nowadays, people are getting confused why they are supposed to use "distutils-r1" for, say, Hatchling.

Admittedly, this is something I could have done differently — PEP517 support was a major migration, and involved an explicit switch. Instead of adding DISTUTILS_USE_PEP517 (what a self-contradictory name) variable, I could have forked the eclass. Why didn't I do that? Because there used to be a lot of code shared between the two paths. Of course, over time they diverged more, and eventually I've dropped the legacy support — but the opportunity to rename was lost.

In fact, as a semi-related fact, I've recognized another design problem with the eclass earlier — I should have gone for two eclasses rather than one: a "python-phase" eclass with generic sub-phase support, and a "distutils" (or later "python-pep517") implementing default sub-phases for the common backends. And again, this is precisely how I could have solved the code reuse problem when I introduced PEP517 support.

But then, I didn't anticipate how the eclasses would end up looking like in the end — and I can't really predict what new challenges the Python ecosystem is going to bring us. And I think it's too late to rename or split stuff — too much busywork on everyone.

Ich habe irgendwie Lust, #Gentoo Linux auszuprobieren, weil ich auf dem kleinen Homeserver eh einiges selbst kompilieren möchte.

WIrd das große Probleme geben oder ist das gangbar?

#RustLang in #Gentoo brings you a new meme: "it's always [patch.crates-io]".

Zdradzę wam sekret: nazwa "portage" pochodzi od pora — tego warzywa.

*sighs*

The other day #PolKit updated or something related to it did on our #Gentoo installation and now our backlight asks for the root password whenever we want to lower or increase the brightness with the keyboard keys when it didn't before.

To be clear we can find nothing of use on the wiki etc, we have looked.

Can any of y'all help please?

In other news, I've sent a few fun patches to improve epytest in #Gentoo.

This includes forcing short summaries, creating junit .xml for machine processing, and most importantly, EPYTEST_PLUGINS to handle specifying the plugins to load. The goal is to eventually move away from plugin autoloading by default.

https://archives.gentoo.org/gentoo-dev/20250623184523.226345-1-mgorny@gentoo.org/T/#t

The time has come for me to propose that #Gentoo leaves #GitHub.

#Microsoft has been purveying #enshittification of this platform for years now. Pushing #Copilot everywhere was the last straw.

https://public-inbox.gentoo.org/gentoo-project/1c0b6be5cb24d51deecaed2ccf99593d0fac185e.camel@gentoo.org/T/#t

Nadejszła wiekopomna chwila. Zaproponowałem, by #Gentoo opuściło GitHuba.

Niestety, obsranie tej platformy postępuje już od lat. A wciskanie na siłę Copilota przetentegowało miarkę.

https://public-inbox.gentoo.org/gentoo-project/1c0b6be5cb24d51deecaed2ccf99593d0fac185e.camel@gentoo.org/T/#t

Modern programmers: "oh, let's hijack all #Python package managers in your bashrc without asking for consent, what could possibly go wrong."

And the best joke is, I didn't even really install the package — I was just making a random bugfix and running its test suite in a virtual environment.

https://github.com/pyupio/safety/issues/766

Nowadays in quality #Python: #Gentoo is running #ProtoBuf-related test suite via #PyTest-forked to workaround protobuf segfaulting during GC.

Of course, it implies random programs can segfault on exit too.

https://github.com/protocolbuffers/protobuf/issues/22067
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/protobuf/protobuf-6.31.1.ebuild?id=54e20d4bb0ec99ab868695a2980c4307d179cb10#n150

Windows nervt dich? Zeit für was Besseres!
Kennst du das? Zwangsupdates, mysteriöse Abstürze und dein PC, der plötzlich sein Eigenleben führt...

"Von Windows zu Linux in 12 Kapiteln" ist dein Ausweg – OHNE Nerd-Abschluss! (Link unten)

Was dich erwartet:

• Ein Schritt-für-Schritt-Guide, der dich WIRKLICH an die Hand nimmt
• Keine Technik-Fachsprache, die nur Experten verstehen
• Sicherheits-Tipps, mit denen Windows nicht mithalten kann
• Praktische Lösungen für all deine "Ja, aber..."-Fragen
• Zero Drama: Mit Snapshots & Backups geht nichts schief!
• Und für GAMER: Linux rockt mittlerweile richtig hart! Deine Windows-Spiele laufen meist nicht nur problemlos – sie performen meistens sogar BESSER! Das Buch zeigt dir genau, wie du als Gamer umsteigst, ohne auf deine Lieblingsspiele verzichten zu müssen.

Linux ist längst nicht mehr nur was für Nerds!

Christin Löhner zeigt dir, wie auch DU dich von Windows-Problemen verabschiedest. Ein Betriebssystem, das DIR gehört statt umgekehrt? Das gibt's wirklich! Und es fühlt sich verdammt gut an. Du bekommst nicht nur eine technische Anleitung, sondern einen echten Begleiter für deinen Umstieg. Von den ersten Zweifeln bis zur stolzen "Ich nutze jetzt Linux"-Aussage. Die beste Nachricht? Du kannst es. Wirklich. Trau dich! Dein Windows-freies Leben wartet schon.

https://www.christin-loehner.de/blog/von-windows-zu-linux-in-12-kapiteln