2026-07-23 11:45:48
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
I've proposed that we reconsider the fully "open" access to #Gentoo GURU project, and instead requiring people to get at least one PR/patch merged before requesting push access.
https://archives.gentoo.org/gentoo-dev/e3ac4768e2ada7e58855eeb841fb0e25c1d45094.camel@gentoo.org/T/
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
PSA: after another major policy violation by user who clearly never cared about #Gentoo and joined only to ignore the rules, I've suspended processing access requests to GURU. We're already working on a new policy, and we'll go from there.
Zero days since 83 #Gentoo developers effectively lost push access over revoked PGP key signatures because of random #LDAP hiccup.
Yes, we have error handling. And yes, we have a safety check in case error handling didn't work and LDAP returned empty list of developers. Yet apparently that's not enough either, so now we also check if the diff between old and new lists isn't too large; you know, in case ldapsearch randomly returned a subset of developers and considered it a success.
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).
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
And the next big blocker for #Python 3.15 in #Gentoo is time-machine. Which is obviously broken. There's a patch but it's #slop and complex, and it's sitting for 3 months already with no reply. Because obviously patching CPython internals is so much a better idea than freezegun ever were. All these time-based tests need all the ricing you can get; portability doesn't matter.
https://github.com/adamchainz/time-machine/pull/618
#Python Hypothesis package now requires #RustLang. This is a scale of reverse dependencies I can't handle. I guess this means it's the end of WD40 profiles on #Gentoo, and therefore the end of support for Alpha, ARM<v6, HPPA, M68k, i486 and some other random subsets of architectures and profiles. Thanks for all the fish, etc.
https://github.com/HypothesisWorks/hypothesis/issues/4740
I have a #Python favor to ask. Could someone look at Python 3.15 test failures in itsdangerous? It's blocking quite a large part of package dependency graph in #Gentoo, and the failure looks, errr, dangerous.
https://github.com/pallets/itsdangerous/issues/420
Binary distributions give you eggs. You never value the goose. #Gentoo is all about the goose.
Zero days since #CPython broke the extension ABI at the very last minute after asking everyone repeatedly to test prereleases. And of course they don't bother tracking ABI changes in any way, so they could at least give people heads up that important pieces of their system will start segfaulting after the upgrade. All they can offer is a knee-jerk response of "we never promised ABI stability".
And yes, this is a huge PITA for #Gentoo users who opted in to helping out.
https://github.com/python/cpython/pull/152448#issuecomment-5016129511
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.
So I wanted to unbundle #uChardet from #cChardet #Python package.
It didn't build against system uchardet 0.0.8. So I've checked, and it turns out cchardet is using some old patched fork of uchardet. Ugh.
Fortunately, upstream added the "missing" function too, with a different API (that's not really a problem), but they didn't make a release in 4 years. Ugh.
I could at least replace the old patched uchardet with upstream uchardet, right? Except now I'm getting test failures over misdetected encodings. 0.0.8 works fine there. Though the particular test doesn't look very realistic (note all the repetitions):
#Gentoo
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.
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
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
#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
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
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…
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
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
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?
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.