FYI, looks like #Migadu doesn't accept e-mail from gentoo.org (their server disconnects us after EHLO). One of their users contacted them, and they've basically replied with blanket response without doing anything to resolve the problem.

#Gentoo

I've just learned that #ReiserFS was mur… I mean, removed from the newest kernels.

In other news, one of anongit machines in #Gentoo Infra rotation is now suffering lack of data.

If #Python package releases continue at this rate, I'm going to start getting up earlier.

Or just stop doing all of them in the morning.

#Gentoo

The ebuild: I need a openapi-schema-validator newer than 0.8 and older than 0.9.

#Gentoo #Portage: okay, how about we try to simultaneously install 0.7.2 and 0.9.0?

We've also posted about our #CopyFail, #DirtyFrag, #Fragnesia handling on the #Gentoo website:

https://www.gentoo.org/news/2026/05/19/copy-fail-fragnesia-vulnerabilities.html

…and yes, another secfix round coming.

CC @wariat

I've finally finished pushing the latest update for #Gentoo Distribution Kernels, and requested their stabilization. This includes upstream releases 7.0.9, 6.18.32, 6.12.90 and 6.6.140; and Gentoo patch bumps 6.1.173_p1, 5.15.207_p1 and 5.10.256_p1.

All of these contain the v5 #Fragnesia patch. And yes, while the exploit is in the wild, upstream still hasn't merged a fix to the mainline kernel, let alone all the LTS branches.

They also include a few reverts in 6.18 and 6.6 for broken PowerPC backports that upstream didn't apparently test. 🤷

We're doing our best, but I'd still recommend running the latest 7.0.x kernel, or LTS 6.18.x, because upstream is far from reliable with the backports.

#Linux

If it wasn't enough that we have to keep building new kernels every day and backport vulnerability fixes to older LTS branches, now we also have to deal with upstream doing random backports that are completely broken and never bothering actually even checking if they build.

#Gentoo #Linux

I've done the right thing and it's going to cause pain.

#Gentoo Distribution Kernel configs are now hosted entirely on git.gentoo.org rather than GItHub. If you don't use Gentoo mirrors, you may be hitting 502s thanks to our LLM overlords now. If you use Gentoo mirrors, you may be hitting 404s if they hit 502s while trying to fetch from our Infra 🤷.

Guess what I'm doing right now.

Yes, it's now my shift to bump dist-kernels in #Gentoo.

Good news is that 6.12+ with Gentoo patches are good, and I've managed to stabilize them even. Only 6.6 and older are getting an extra upstream patches.

These days new vulnerabilities are found faster in kernels than I can manage to build patched kernels for #Gentoo.

https://lore.kernel.org/netdev/20260513041635.1289541-1-vakzz@zellic.io/
https://lore.kernel.org/netdev/agRfuVOeMI5pbHhY@v4bel/

Kudos to @thesamesam for staying on top of things.

One of my strong suites in all the packaging work is the knowledge in my head.

"Why don't you write it down for others to benefit from, then?", you'd ask.

The thing is, this knowledge is basically "hot cache". I'm bumping hundreds of #Python packages in #Gentoo, so I remember stuff. And because of that, I can quickly notice some things or answer some questions.

If that were written down, the effort needed to find it would diminish all the gain. I mean, technically *it is* already written down, and the whole point is that I have it "cached".

Did I just switch from hardcoding the #Gentoo patchset version in Distribution Kernel ebuilds (because we needed to rebase/update them so rarely) to using `${PV}`? Perhaps.

Remember how #Opera browser used not to be one huge scam?

Now they're mailing #Gentoo over dead Opera-related links on the Wiki, with random #SEO crap.

How to get a package removed from #Gentoo?

1. Add a new #NIH dependency.
2. The dependency turns out to use coherent.build. Nightmare! Oh, wait, apparently coherent.build generates source distributions that use flit.core (understandable; coherent.build is unusable).
3. The dependency depends on chardet (the project famous for GPL copywashing). Okay, technically it works with the older version, and the dependency is optional with poor person's fallback, so I guess it would be fine.
4. But hey, this package is not used by anything, and the last package using it in Gentoo was removed in 2020, after not being touched for 4 years already. Also, it is unmaintained upstream since 2017, so I guess there's negligible risk of it ever coming back.

#Python

Fun oneliner:

gpy-impl -@dead -3.11 -pypy3_11 *.ebuild && copybump $(git diff --relative --name-only .) && { check-revdep && pkgcommit -sS . -m 'Remove py3.11 (per scipy)' || git restore -WS .; }

#Gentoo

Kinda related to https://social.treehouse.systems/@ariadne/116418712432034431

People are sometimes like "${BigCompany} uses #Gentoo, so cool" or "they stopped using it, so sad". And I'm like, "why should we care?"

Do they donate money to Gentoo? They don't. And if they did, it would probably come with obligations making this not worth it.

Do they contribute back? Rarely, and if they do, they are unreliable. They benefit more than we do. They just want to dump the packages they need, quickly duct taped together, so that we would maintain them going forward. Their employees rarely reveal that they're paid to do this, and if they do, it's not so they'd be held to higher standards, but to emphasize their importance: "you must placate us."

Well, sometimes they hire Gentoo developers. It's nice that these developers get some gratification for their work, especially if they're able to continue contributing on work time. But in the end, company priorities win. We are either left with loads of new packages with no maintainer and unclear significance, or a Google employee who appeared every once in a while to dump a bunch of ChromeOS patches and never bothered handling the fallout.

So, sorry, but I'd rather care for volunteers who want to make Gentoo better, than companies who see some profit incentive in it.

PS. I'm probably focusing too much on the negative aspects, and we likely had some positive interactions that are far less known and usually don't meet with such fanfare.

PSA: The yearly #Gentoo #Python switch planned for 2026-06-01. CPython 3.14 becomes the default, 3.11 and #PyPy 3.11 go out. The latter fills me with sadness but keeping it is unrealistic now that projects are aggressively pushing for 3.12+.

Of course, we'll continue shipping the interpreters, so you can use venvs if you like. However, that's going to become harder to use since many projects either don't ship PyPy wheels or don't work on PyPy at all without patching.

We will revisit PyPy support if a version compatible with Python 3.12 appears in reasonable time.

https://public-inbox.gentoo.org/gentoo-dev/20260412164104.429630-1-mgorny@gentoo.org/T/#u
https://public-inbox.gentoo.org/gentoo-dev/58cefccb3d0758671537715f4ddb34d59c938461.camel@gentoo.org/T/#u

It's really great that #Gentoo no longer has to rely on such uncultured solutions as using scp / rsync to push a bunch of distfiles to a public_html directory that's then exposed on a HTTP server. Now I just have to… [checks notes]

1. Use 'kup putraw' to put the kernel patchset on distfiles mirror.
2. Wait an hour for mirrors to sync.
3. Start building new kernels.
4. Rsync kernels from build hosts to the local machine.
5. Use a complex script involving 'kup ls ... | grep' and `kup putraw ...` to upload the built kernels.
6. Wait an hour for mirrors to sync.
7. Check if all kernels were uploaded correctly.
8. Push new kernels.

#gentoo #portage feature I learned about today by accident:

emerge --pretend --fetchonly (shortened as emerge -pf) will print all the URLs it'd use to download the various distfiles, instead of listing the results of the dependency resolution (as --pretend would usually do).

Caught me off-guard, I don't think this is documented anywhere. Glad to know portage still hits me with surprises after using it for 7 years 😅

If you're wondering what I'm doing on this fine morning: I'm recursively wgetting ~140G of old #Gentoo dist-kernel binary packages (that nobody really cares about) just to re-kup-load it to the same hypervisor after renaming and PGP-signing them. At roughly 14 MiB/s.

Praise be overengineered solutions.

Yes, I could be instead spending hours trying to figure out PGP agent forwarding.

Gentoo Linux Begins Codeberg Migration In Moving Away From GitHub, Avoiding Copilot
https://www.phoronix.com/news/Gentoo-Starts-Codeberg-Use

#ai #copilot #github #gentoo #opensource

Inevitable moment:

f4e4ddaf69337 dev-build/steve: is no longer simple

#Gentoo

New on my #Gentoo blog: One #jobserver to rule them all

"""
A common problem with running Gentoo builds is concurrency. Many packages include extensive build steps that are either fully serial, or cannot fully utilize the available CPU threads throughout. This problem becomes less pronounced when running building multiple packages in parallel, but then we are risking overscheduling for packages that do take advantage of parallel builds.

Fortunately, there are a few tools at our disposal that can improve the situation. Most recently, they were joined by two experimental system-wide jobservers: #guildmaster and #steve. In this post, I’d like to provide the background on them, and discuss the problems they are facing.
"""

https://blogs.gentoo.org/mgorny/2025/11/30/one-jobserver-to-rule-them-all/

If you think #Gentoo was boring recently, I've been doing some stuff to make it more interesting. No need to thank me.

#FlexiBLAS: now default in order to break more ~arch systems
#FreePG: available as an alternative on ~arch, but dependencies need to be updated still to allow it more
#ZlibNG: started experimenting with it locally, flag still masked

I have the—perhaps incorrect—impression that the Gentoo project depends on a lot of custom (an sometimes legacy) software, and is suffering from decisions made decades ago...
Well, that and the fact that some components of it are incredibly complex (sob Portage <3 sob).

But maybe I'm missing the point here... -c-