Tootfinder

As if you didn't know this would happen...
#gentoo

One of the better weekend pleasures is the scrolling emerge of 232 KDE 6.7.5 packages. As long as all is successful 😁
#gentoo

Now that everyone is panicking about having to update all the bundled certificate stores, I would like to remind you that unbundling is actually a good #security practice. That's why we do it so often in #Gentoo.

It's still worth those 2h17min.
#gentoo #kde

Well, I wanted to regret using #bash for ebuilds, but I guess that's not really the problem in this case.
#TIL that bash has this default of `shopt -s checkwinsize` that means it automatically sets COLUMNS and ROWS to the terminal size. If you start a new shell, it inherits these variables from the parent, along with the export bit, but as soon as the first external command is executed, it resets the value to the actual terminal size.
So if an ebuild does:
src_test() {
local -x COLUMNS=80
emake check
}
Then each shell started by make(1) will have "COLUMNS=80" exported at first, but as soon as another command is executed, it will magically start exporting a different value. What's really absurd about it, if we didn't export COLUMNS override, these shells won't be exporting the variable in the first place.
This is just batshit insane.
#Gentoo

For the initiated:
prt-get sysup feels a lot like the first emerge -agqv --update --deep --newuse atworld. LLVM itself takes an hour 😜
Should you understand anything from this, please do consult a certified GP. Things could get worse!
#crux #gentoo

#Gentoo lovers, is anyone up to the challenge of making sys-kernel/gentoo-kernel and related eclasses cross-compile friendly? Ideally with https://gitweb.gentoo.org/proj/binpkg-docker.git updates to actually make cross-builds possible.

It's kinda funny that the certificate compromise comes just after another round of upstreams bashing at distro packaging.
Let me get this straight for the people in the back. In a perfect world, you'd just upgrade a single package on your system and be good. Unfortunately, we're far removed from even a reasonably good world.
Pretty much everything that matters in #Python uses certifi. dev-python/certifi in #Gentoo is a fork that uses system certs, so our system install is good. But in every virtual environment (venv, conda, etc.), you need to upgrade certifi.
certifi is also bundled in a bunch of packages, including pip. dev-python/pip in Gentoo has certifi unbundled, but you need to upgrade pip in your virtual environments (using vulnerable pip!). On Gentoo systems, you also need to upgrade dev-python/ensurepip-pip, which is the upstream wheel which we couldn't figure out how to unbundle.
pip is also bundled in Python to bootstrap venvs. In Gentoo, we're configuring Python to use our system dev-python/ensurepip-pip package, so as soon as you upgrade it, you're good. But where this isn't the case, you need to wait for new Python releases and upgrade, because otherwise venvs will start with vulnerable pip. On the plus side, you can remember to upgrade it after creating a new venv.
Lock files are particularly popular in the Python world, and a dependency cooldown is the new fad. You will need to update certifi in them, and exclude it from dependency cooldown.
Many #RustLang packages (think uv) also use a bundled certificate store. All these packages need a lockfile update and rebuilding, meaning downstream patching or new upstream release. So yes, everyone (including Gentoo users, because Rust doesn't really support dynamic linking, great design for #security) need to update uv, and possibly wait to discover more random Rust packages that are vulnerable.
I'm also going to guess that all flatpakers are affected, all popular browsers, and possibly everyone else who knows better than to use distro packaging. All containers are affected, and will need to be rebuilt, with new system certificate stores and all the packages that bundle their own stores…
And the best part is, most of these upstream package distribution systems have no other security layer except for TLS certificates. You can update Gentoo packages safely, because we are using our own key infrastructure. But pip, uv and so on are subject to a MITM risk while upgrading the vulnerable packages.
This is the true definition of clusterfuck.

I always said i understood Slackware a bit after I understood Gentoo better. For my KDE I'm running Larry again for the last 10 days. Man, what a nice return it is. And yes, I know it has some flaws, but the Gentoo Wiki is excellent.
#gentoo

In other totally meaningless disruptive changes, #tmux now defaults to capturing mouse events. I haven't found a single useful thing it does with them yet, however it managed to break my habits when copying things from terminal (now I need to hold shift) and to break mouse wheel scrolling in less. But I'm sure it's a feature!
So now I need to add:
set -g mouse off
to ~/.tmux.conf on every single server and container I use.
Solution via #Gentoo #UX

With my new excitement over FreeBSD, my lasting friendship with Chimera and my Flintmobile that's called Slackware I do miss a good ole lengthy portage session with Larry 🐮
#gentoo

So now that #awscli 1.x is pretty much dead, I've finally gotten around to packaging 2.x properly for #Gentoo. You know, the one where other developers claimed it was impossible to build from source because (checks notes) upstream said so. So we instead must use their horrible 70M binary package that bundles its own Python interpreter along with all the random libraries and dependencies.
And guess what? Sure, they don't publish it to PyPI anymore, but it still is a regular #Python package branched out from 1.x. It has regular Python package dependencies, a regular Python build backend and when you build it with it, you get a regular Python wheel that can be installed and just works with the system Python and system dependencies.
Sure, it's crap, but it's no worse than the 1.x crap. It bundles a modified fork of the unreleased 2.x branch of botocore (now dead for 5 years, apparently) and a fork of s3transfer. It has some random meaningless dependency pins that we patch out. It has a horrible test suite that can eat tons of memory if run via xdist, but with some hackery, I've gotten it to work reasonably.
Honestly, I feel like Gentoo developers these days just don't care to even try.

Fun #Gentoo / steve trick:
echo "$(( $(stevie -j) - $(stevie -t) ))j"
gives you the current number of jobs running via the system jobserver. You can put it e.g. in the "generic monitor" plugin of Xfce next to CPU graph, to see how the CPU utilization maps to jobs.

Now I really want to create a #Gentoo project called "The Butlerian Inquisition".
#NoAI #NoLLM

I've been reminded today that a while ago I've made this #Gentoo Family thing; a graph of developers joined by their mentors:
https://dev.gentoo.org/~mgorny/gentoo-family.svg
That said, it's just a dumb graph made via GraphViz. The source is here:
https://dev.gentoo.org/~mgorny/gentoo-family.dot
That said, I'd appreciate if some of you have ideas how to make a better graph from this. Particularly I'd like to account for the actual dates somehow. If you find grabbing the data from .dot too hard, I can produce a stripped down export from LDAP on request.

Did I just hack up an abomination using xmllint (from libxml2) and jq to query the latest #PyPI version of a package? Perhaps.
Do you no longer have to specify the target version when using pkgbump on PyPI packages? Absolutely.
#Gentoo

I was surprised that my latest blog post didn't bring any nasty comments (or any comments at all). But then, I've learned that people these days don't talk *to* you as the author, but apparently engage in threads at random cesspits. And honestly, the quality of public discourse today… a bunch of people talking past one another, apparently everyone an expert in how #Gentoo works and what Gentoo developers do and why.

Thanks, #Portage! That's definitely the solution I was looking for.
#Gentoo #RustLang

In my private projects and in #Gentoo, I have a strict #NoAI policy. Any LLM-assisted contributions are closed immediately and considered tainted. Use for messaging, bug reporting, etc. also gets you a warning and a request to write yourself. And I dare say I have a heavy ban finger on this; you get one warning only. Well, unless it's clearly an automated submission, in which case you get an immediate ban.
In my dayjob and non-Gentoo work, I also follow a strict policy for my own work. I don't use any of these tools. However, I can't really stop others from doing so, even though I cringe whenever I see someone needing to use an overengineered statistical model to make a trivial change. I can't really reject bug reports, reviews, etc.
The really hard part of it is that I'm starting to have doubts. I truly hate slop in all forms, and what these tools have done to the Internet in general, and to #FreeSoftware in particular. However, I've also gotten some good reports. Like, the kind of tricky logic issues in the specification I am developing that I would have never figured out myself, and that may have never came up during the review otherwise. In other words, someone running an LLM on the specification triggered real bugs that would likely slipped through and required a post-approval specification change when someone noticed that we've introduced incompatible constraints in two different parts of the specification, that would eventually be hit in real use.
All the ethical problems are still there. All the harm is still there. However, I can't really claim that these tools vomit pure useless slop anymore. I feel that it's really time for me to retire.

Once again I regret starting, but I'm done: stripped down the #Gentoo "py" package to the bare essentials that are required for pytest-forked (and the stable version of cffi).
Does anyone happen to know if there's a properly maintained alternative to pytest-forked, so we could get rid of py entirely?
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ea613a5e9380b46b20517f03b1ef2c813ee2f78

#Gentoo took the next step and disabled creating new pull requests for GURU on #GitHub. The existing pull requests will be left open and hopefully eventually merged; new pull requests must go to #Codeberg.
https://github.com/gentoo/guru/pull/551

Zero days since #pip added a random new functionality that depends on pip being entirely standalone and breaks when you unbundle the dependencies. And I'm unable to figure out why a bunch of tests are still failing.
EDIT: I'd appreciate some help with that. My WIP is at #Gentoo #Python

Okay, it's still rough around the edges, needs documentation, tests and other stuff I'll slowly be adding but here it is: gagit, or #Gentoo #AGit workflow tool.
#NamingIsMyPassion

In other news, the #Python semver package has now #RustLang speedups. I'm sure they will come in handy in its reverse dependencies, which are (checks notes) net-analyzer/pontos. I'm sure that package needs to efficiently handle millions of semantic versions a second.
#Gentoo

I've added a "contributing" file to #Gemato:
#Gentoo infrastructure and mirrored to GitHub or Codeberg.

Did I ever announce gentoo-kernel-modprep? It's the newest variation on #Gentoo Distribution Kernels: the absolute minimum kernel tree necessary for building modules. Ideal for package-building containers where a full kernel is unnecessary, yet you need to be able to build kernel modules.

I feel that #Gentoo #GURU is getting much less interest since the change of rules.
Not sure if that's a bad thing, given how much of the interest we're getting are people who just made a slopware and now are aggressively pushing it to all the distributions they can find. Some just do an automated submission without bothering to follow the rules. Other claim that they have read and agree to the rules, even though the rules explicitly forbid doing that.
Then, there are all these people who asked for access but apparently never committed anything.
#slop

Zero days since the #Linux #kernel made a security release of all branches, containing exactly one patch, except for 6.12 which was skipped for no clear reason, and there doesn't seem to be anything about that on the ml. And now I'm scratching my head if I should do a backport for #Gentoo, or wait for the release, or perhaps there was a good reason why the patch was added to every other LTS branch but not 6.12…

PSA: I've just removed 344 #Gentoo #GURU committers who haven't connected to the git server in the last 6 months. This is specifically related to the change of rules. We have 205 regular committers now, plus 6 trusted contributors.

Me after laboriously backporting #Python 3.15 fixes to #Django 6.0.x in #Gentoo: "oh, nice, the patchset applies cleanly to 5.2.x as well."
And today, I have to laboriously backport another patch to 6.0.x, and it turns out the backport doesn't apply cleanly to 5.2.x, so I have to laboriously backport it there as well.
I honestly *hate* Django Python version support policy. Shifting all the burden downstream.

And this "entitled prospective user" attitude. "I was planning on moving my projects to #Codeberg, but now I won't". Oh, how sad that you won't give them the benefit of using their free services (okay, I'm sure you were going to donate).
Reminds me of the "entitled prospective contributor" attitude in #Gentoo. "You never heard from me before, but I don't like this new policy. There are dozens of new contributors with me, just around the corner, and now we won't be able to contribute." (This was about the copyright policy, so they could have contributed noncontroversially for a long time, yet they never did.)
#NoAI #NoLLM

Today's #blog post is short but important: "A plea not to use uv-build"
"""
After seeing yet another dozen packages lose keywords on Gentoo because of a single key dependency switching to uv-build, I would like to plea on behalf of Gentoo users: please don’t use uv-build as a build backend. Just to be clear, this is not about uv itself or any other Astral tools; these are good tools with a nice and responsive upstream. The uv-build backend is one thing we have to disagree on. I’m not saying it’s bad; I’m saying that its benefits don’t outweigh the drawbacks.
"""
#Gentoo #Python #uv #PEP517 #packaging

Zero days since the #Python feedparser library switched to yet another #SGMLlib fork.
Yes, #Gentoo has only packaged the previous SGMLlib fork because of them.

FYI, you don't want to get banned on the #Gentoo org on #Microsoft #GitHub right now, because vibe-hub is broken and I can only ban people but "something goes wrong" when I'm trying to see who's banned (and therefore I can't unban anyone).

#Python in a nutshell:
1. Let's use this new fancy #TOML thing for everything, it's so cool!
2. Everyone starts depending on third-party TOML libraries.
3. TOML library is finally added to the standard library, so people are moving to conditionally using it.
4. As old versions of Python become irrelevant, people are finally dropping fallbacks to the third-party library.
5. TOML 1.1 is introduced, and everyone has to start using a third-party library again… (at least until Python 3.15)
That's in case anyone is wondering why dev-python/tomli is suddenly getting installed on #Gentoo systems again.

There could be different signs that projects are becoming #slopware. Some are more obvious, like having agent instructions that are more detailed than anything they ever wrote to humans. Some are less clear but perhaps even more ominous, like largely mature projects suddenly starting to churn out two releases a day, often with regressions that I don't even care to report anymore.
I used to think that my work as a #Gentoo packager was important. Now I feel that a large part of it resembles sitting at the end of a sewage pipe and trying to scrape something meaningful out of it all.
#NoAI

#RustLang folks, could someone do me a favor and make a PR to fix #Gentoo work.

Too many days working on #FLOSS feel like: "I'm not paid for this shit. I'm paid to do other shit and I have to focus on that shit, but I can't when I have to spend so much time fixing shit that apparently others are being paid to break all the time."
#Gentoo #LLVM #FreeSoftware #OpenSource

#Gentoo has a strict #NoAI policy, so our projects are slop-free. Unfortunately, these days you cannot run an up-to-date system without tons of random slop packages, because everyone insists on using that crap.
Gentoo supports a whole bunch of architectures that probably every other distribution dumped so far. Unfortunately, these days the available software list is shrinking, as everyone insists on adding some random meaningless dependencies on #RustLang (like using uv-build, which is the single most harmful meaningless #Python project ever created).
Gentoo has a strong upstream cooperation policy. However, these days I'm afraid to file issues, because just too often they just trigger more slop. I miss the "good" old days where the worst you could expect is some toxic asshole.
The state of #FreeSoftware is truly depressing. There is little joy in distribution work these days. You're overwhelmed with shit, burned out and end up doing a shitty job. And it's bad for your health.
#FLOSS

I see that #Docker, Inc. is now sending #slop #spam to distributions: #Gentoo

#TIL that #Gentoo Linux is a successor to #Ubuntu Breezy (5.10).
#WTF

New on #blog: "How hard is it to get a jobserver client right?"
"""
In November 2025, I’ve started working on #steve, the #jobserver for #Gentoo. I wrote about it already, in the “One jobserver to rule them all” post. Back then, my main focus was on the motivation for a system-wide jobserver, and the technical details of getting it working. I have also mentioned a few client bugs we’ve discovered along the way.
Since then, we’ve found a few more bugs, as well as problematic design patterns. I think they’re kind of interesting, so I’ve decided to dedicate this post specifically to them. As a disclaimer, my aim is not to pick on specific projects; I’m bringing them up as real examples of what we’ve hit, and how that impacts jobserver operation.
"""
https://blogs.gentoo.org/mgorny/2026/09/02/how-hard-is-it-to-get-a-jobserver-client-right/

Isn't it great that #Quart removed support for #Python 3.12 while it's only needed for #dnspython and #urllib3 tests, and we definitely can't remove 3.12 in urllib3? Gotta love the maturity of the Python ecosystem.
#Gentoo

I've taken #Gentoo Bugzilla down, because it was unusable anyway. No point in feeding the #LLM scrapers that are using thousands of different IPv4 addresses, with no obvious patterns I can see.
EDIT: I'm not looking for hints. I'm not a sysadmin, and I don't have time to deal with this shit. I'm just trying to get some useful job done. I'm not supposed to have to be dealing with this.
#AI #NoAI #NoLLM

So I'm getting fed up with #spam on #Gentoo #Bugzilla.
A while ago we've introduced a timed block on new accounts posting URLs. It helped for a while. But now someone actually bothered implementing a dedicated tool, and we're getting a daily create-wait-post loop. I can't think of a really good way of getting rid of this.
So far I was thinking of:
• blocking new accounts based on the predictable e-mail pattern (they're just going to switch patterns, also may hit real users)
• limiting URLs pasted to an allowlist (this is going to suck hard)
• requiring manual request for every account via IRC (this is going to be pain for us, for users, and a lot of people just won't bother)
It really feels like whatever we do, it's going just to cause pain to us, to our legitimate users, and the spammers will just slop their way around it.
And on top of that, every comment posted is fucking #slop. Totally meaningless sentences added to random bugs, in the hope that we're too stupid to see that they've just spammed us.
I hate this timeline. Can we do Butlerian Jihad now, please?

Zero days since it turned out that #GnuPG has arbitrarily changed behavior between versions in the name of "safe default", and required you to pass an additional option to make it behave properly in the rare cases it matters. Of course we still need to support old versions and alternative implementations without that option. And of course there is no clean way of checking whether it's available or not.
#OpenPGP #GPG #Gentoo

I'm thinking of creating a small (they always start small) tool to help submitting pull requests via #AGit to the #Codeberg mirrors of #Gentoo repositories.
Guess how I'm going to call it.
(I'm sorry for spoiling it on IRC already.)
#NamingIsMyPassion

Oh, right, in case I thought I'm going to have time to do useful things, I just realized I still need to deal with the humongous #Gentoo fallout from #Hypothesis #Python package requiring #RustLang now.

Yeah, so #PyPy 3.12 support won't enter #Gentoo for a while, because it needs support in #PyO3 first (because of the brilliant idea that #Hypothesis should require it), so we're blocked on the whole #RustLang / #Cargo "implement, release and wait for everyone to update their pins" nonsense.