Tootfinder

Worked on some more #Gentoo global #jobserver goodies today.
Firstly, Portage jobserver support patch: #PyTest jobs will also be counted towards total job count.
Again, it's not a perfect solution, but it works reasonably. The plugin still starts -n jobs as specified by the arguments, but it acquired job tokens prior to executing every test, therefore delaying actual testing until tokens are available. It doesn't seem to cause noticeable overhead either.

Wow, #Gentoo moving from GitHub to Codeberg is cool. Haven't run Gentoo for years now but still have a soft spot for it (I learned so much running it as main driver).
I also use Codeberg für my code (and joined the association) but we can't just "move everything to Codeberg". That's neither sustainable nor a good model. We should have more associations like Codeberg t…

Linux tips:
se in #gentoo ti trovi Baobab che si apre al posto di Thunar in HexChat e probabilmente da altre parti la soluzione é usare il comando
gio mime inode/directory
e re-impostare thunar.desktop come default con
gio mime inode/directory thunar.desktop
My Due Cent
#gentoo

#Gentoo #jobserver revealed another problem with steve in particular, and (I believe) the jobserver protocol in general: blocking clients are prioritized over polling clients.
The problem is simple: when handling blocking reads, steve can issue a job token immediately. When handling a poll, it merely indicates that a token is available, and the client must issue another read request to get it. So if tokens are scarce and there are both blocking and polling clients running, the former are likely to be taking all the incoming tokens.
My idea of working around this is to implement temporary reservations. If a client polls for a token, we reserve one for it. The reserved token can afterwards be only read by the same client. This way, both blocking and polling clients get a token — the former get it immediately, the latter get it reserved for them. And if there are no tokens available, both get into a single FIFO queue, for a poor man's round-robin (steve also throttles all reads to one token at a time).
However, polls technically don't guarantee that the client will eventually read the token, so we need to handle reservation expirations as well.

Czy to nie interesujące, że alias pocztowy zespołu #Gentoo Treecleaner otrzymuje #scam od czterech różnych "administratorów poczty" z rzędu?
#spam

Quick update on #Gentoo stuffs:
1. virtual/zlib and virtual/minizip are in, sys-libs/zlib-ng[compat] and sys-libs/minizip-ng[compat] are unmasked. Unfortunately, due to scale of this you have to do a --changed-deps rebuild to be able to switch. Or package.provided.
2. I've filed bugs for all the packages depending on app-crypt/gnupg. Should get us closer to app-alternatives/gpg being fully supported.
3. Started preparing to replace gentoo-mirror/ scripts with something much simpler. So I guess we're going to be removing most of the mirrors this week after all.

That was fun!
Gentoo, with all tweaks and stuff (zram, latest kernel etc): 5 hours and 25 minutes 🐮 Fully working Cosmic desktop, flathub enabled.
@… : I'm back 👻
#gentoo

Isn't it fun that the #Gentoo Treecleaner mail alias is getting #scam from 4 different "administrators" in a row?
#spam

To teraz #Gentoo jakoby zawiera "ekstremistyczne" oprogramowanie.
https://bugs.gentoo.org/964663

RE: #GentooLinux

BREAKING: #CPython 3.13.10 and 3.14.1 changed the multiprocessing message format in patch release. As a result, programs using multiprocessing may break randomly if they are running while #Python is upgraded (i.e. need restarting).
But apparently it's not a big deal, since all the cool kids are running Python in containers, and nobody is using Python for system tools anymore. Everything has been RIIR-ed and Python is only omnipresent in some backwaters like #Gentoo.
https://github.com/python/cpython/issues/142206

FYI, at the weekend we're probably going to remove almost all the repositories from #Gentoo

Używanie #CVS to przestępstwo, za które karą jest konieczność opieki nad pakietem CVS w #Gentoo. Tak, patrzę właśnie na 18 łatek na tym pakiecie, włączając w nie poprawki bezpieczeństwa.

Since MangoWC is available in Guru I'm considering a second Gentoo install.
We all know how this is going to end.
#mangowc #gentoo

Yeah, why not neglect all the good recommendations in the #Python ecosystem, and instead fork your own C extension package, force people to build it with #ZigLang (it's still C), add unconditional dependency on that, and on top of that, refuse to publish wheels, "allowing for optimised compilation according to your machine's specific architecture and capabilities, instead of some (low performance) common denominator."
Fortunately, looks like #Gentoo can just ignore all the fancy crap and compile it with GCC.
https://pypi.org/project/ruamel.yaml.clibz/
[UPDATE: didn't last long: https://sourceforge.net/p/ruamel-yaml/code/ci/6846cf136e775ed0052cdef6ff02330269c86011/]

New on blog: "How we incidentally uncovered a 7-year old bug in gentoo-ci"
"""
“Gentoo CI” is the service providing periodic linting for the Gentoo repository. It is a part of the Repository mirror and CI project that I’ve started in 2015. Of course, it all started as a temporary third-party solution, but it persisted, was integrated into Gentoo Infrastructure and grew organically into quite a monstrosity.
It’s imperfect in many ways. In particular, it has only some degree of error recovery and when things go wrong beyond that, it requires a manual fix. Often the “fix” is to stop mirroring a problematic repository. Over time, I’ve started having serious doubts about the project, and proposed sunsetting most of it.
Lately, things have been getting worse. What started as a minor change in behavior of Git triggered a whole cascade of failures, leading to me finally announcing the deadline for sunsetting the mirroring of third-party repositories, and starting ripping non-critical bits out of it. Interesting enough, this whole process led me to finally discover the root cause of most of these failures — a bug that has existed since the very early version of the code, but happened to be hidden by the hacky error recovery code. Here’s the story of it.
"""
#Gentoo

#SigStore / #PyPI attestations: #PGP is hard! We must invent a new signing scheme that's so much easier on users.
The tools, after I've spent hours *integrating* them into #Gentoo, and getting them working for everything before:
* Verifying google_auth-2.46.0.tar.gz ...
Provenance signed by a Google Cloud account, but no service account provided; use '--gcp-service-account'
Yeah, I'm sure that's *so much simpler* than PGP.
#security

Ah, my two nemeses: OOM and ENOSPC.
#Gentoo

Let's get this straight: it is entirely normal for a #OpenSource project to accumulate bug reports over time. They're not a thing to be ashamed of.
On the contrary, if you see a nontrivial project with a very small number of bug reports, it usually means one of the following:
a. you've hit a malicious fake,
b. the project is very young and it doesn't have many users (so it's likely buggy),
c. the project is actively shoving issues under the carpet.
None of that is a good sign. You don't want to use that (except for b., if you're ready to be the beta tester).
#FreeSoftware #Gentoo #GitHub #Python

O, fajno. Wygląda na to, że do wsparcia Pythona 3.14 w #Django w #Gentoo brakowało tylko jednej łatki. I działa!
#Python

How to absolutely *not* do #OpenSource: require people to commit to work on other issues with your project in order to file bugs. So, sorry, #Typer, I won't be filing bugs. You figure out how you messed up your release yourself.
Also, please don't use #FastAPI. They are clearly bothered by the fact that people dare use their projects and waste their precious time with support requests.
#Python #FreeSoftware #Gentoo

So #Gentoo is now shipping "extremist" software, apparently.
https://bugs.gentoo.org/964663

Using #CVS is a crime punishable by having to maintain it in #Gentoo. Yes, I'm looking at these 18 patches, including security fixes.

W tych czasach, #Gentoo przypomina małą komórkę wolontariuszy, którzy walczą ze zgównowaceniem oprogramowania. Z jednej strony: hordy devów zatrudnionych na pełen etat. Z drugiej: młodzi, ambitni ludzie, którzy mają mnóstwo wolnego czasu. Jedni i drudzy są w stanie produkować taśmowo bylejakość, bo to dużo łatwiejsze niż robienie rzeczy dobrze.
(Żeby było jasne, nie twierdzę, że każda korporacja…

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/

I'm building webkit-gtk right now. It's one of these messy packages where a few source files need a lot of memory to compile, and ninja can randomly order jobs so that all of them suddenly start compiling simultaneously. So to keep things going smoothly without OOM-ing, I've been dynamically adjusting the available job count via steve the #jobserver.
While doing that, I've noticed that ninja isn't taking new jobs immediately after I increased the job count. So I've started debugging steve, and couldn't find out anything wrong with it. Finally, I've looked into ninja and realized how lazy their code is.
So, there are two main approaches to acquiring job tokens. Either you do blocking reads, and therefore wait for a token to become available, or you use polling to get noticed when it becomes available. Ninja instead does non-blocking reads, and if there are no more tokens available… it waits till one of its own jobs finish.
This roughly means that as other processes release tokens, ninja won't take them until one of its own jobs finish. And if ninja didn't manage to acquire any job tokens to begin with, it is just running a single process via implicit slot, and that process finishing provides it with the only chance to acquire additional tokens. So realistically speaking, as long as there are other build jobs running in parallel, ninja is going to need to be incredibly lucky to ever get a job token, since all other processes will grab the available tokens immediately.
This isn't something that steve can fix.
#Gentoo #NinjaBuild

(Troll, but not really)
It's official: #CPython is planning to kill the #Gentoo WD40 profiles.
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906

🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym Oprogramowaniem
Nowości w #Gentoo:
• #Gemato wspiera #FreePG i w większości #SequoiaPGP

Oh nice, I see that #Django 5.2.7 was missing only one patch for #Python 3.14 support in #Gentoo. Now in!

Doing #Gentoo these days feels like being a small cell of unpaid volunteers opposing the enshittification of software. On one side, we're put up against a horde of full-time corporate developers. On the other, against young ambitious volunteers with lots of free time. And both can rapidly spew tons of mediocre code, and doing things wrong is so much easier than doing things right.
(Just to be clear, I'm not saying every corporation or every youngster does things wrong — there are people who care on the other side too.)

Inevitable moment:
f4e4ddaf69337 dev-build/steve: is no longer simple
#Gentoo

If someone wants to try Steve the Jobserver out, I've added a live ebuild in dev-build/steve. It installs the needed service files and suggests how to configure #Portage to use it as a global jobserver for all builds.
#Gentoo

Yeah, so the GNU #make jobserver protocol is trivial, which can be a blessing and a curse. It puts the job management entirely on the clients, which means that they must reliably return job tokens, or otherwise the jobserver will be left with no jobs available and everything will hang. The make documentation is clear on this:
> Your tool should be sure to write back the tokens it read, even under error conditions. This includes not only errors in your tool but also outside influences such as interrupts (SIGINT), etc. You may want to install signal handlers to manage this write-back.
#NinjaBuild jobserver implementation may not handle this correctly, but fortunately it does. The irony is, it turns out that GNU make does not…
#Gentoo

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

According to #FreePG right now: #ArchLinux, #Debian, #Fedora, #NixOS and #Ubuntu. Now #Gentoo joins that list, except that instead of silently making intrusive patching on top of GnuPG, we provide it as a separate package (app-crypt/freepg), and mark appropriately:
$ gpg --version
gpg (GnuPG) 2.5.13-freepg

#Steve the #Jobserver has undergone a major rewrite over the last week. It's now implemented using CUSE, the #FUSE API for character devices. It is using pidfd to track processes acquiring job tokens, and automatically reclaims them if processes die without returning them, preventing dead processes from effectively locking the system jobserver.
The code's still a bit ugly — it's a C-changed-midway-to-C , with libevent for event loops and (still) FUSE's ugly argument parsing.
If someone wants to play with it, the live ebuild is available in #Gentoo as dev-build/steve.
https://gitweb.gentoo.org/proj/steve.git/

#Sphinx joined the list of packages dropping #Python 3.11 (and therefore #PyPy) support. Of course, we could just go through the effort of dropping it from respective packages in #Gentoo, given it's not technically that common… but honestly, at this point I have zero motivation to put the extra effort for this, just to learn that next month some core package starts requiring Python 3.12.
So, would anyone really mind if I removed Python 3.11 and PyPy support completely from Gentoo packages?

There should be a policy that when a package provides multiple build systems for itself, and you're building it with #CMake, you should always remove all installed CMake files to make software developed on your platform portable.
#Debian #Fedora #Gentoo #packaging

Why not switch your crappy software from crappy #SCons build system to even more crappy #Bazel build system over a patch release, call it "fully backwards compatible", and then effectively leave all the distros stuck on old versions with half a dozen vulnerabilities?
Yeah, just a random reminder that #MongoDB is total crap, and you shouldn't use it. Or expect people to package it for you.
#Gentoo

🤚 Free Saturday
👉 Saturday spent working on Free Software
Highlights from #Gentoo:
• #Gemato is now compatible with #FreePG and mostly compatible with #SequoiaPGP chameleon.
• Prepared patches to support FreePG and SequoiaPGP chameleon as "gpg" symlink providers.
• #FlexiBLAS is now enabled by default on ~arch.
• Finally finished working on #PkgCheck check for missing #PyPI provenance checks.
• gpy-list-pkg-impls now includes "does this package have tests?" state, can optionally include PythonCompatUpdate results from PkgCheck and output mIRC colors. In other words, our IRC bot will now tell us when dependencies let us port new packages to #Python 3.14, and whether these packages have tests.

0 days since it turned out that GNU #make does not respect the #jobserver protocol it designed itself in yet another way. Or to put it otherwise, I've wasted my whole morning implemented something that cannot work because it didn't occur to me that GNU make people only set rules without caring to actually follow them.
#Gentoo #Linux

Can I switch timelines, please? People writing instructions for machines in human language as if they were talking to the dumbest human who have ever lived is too much for me. I really feel we've reached the point when I completely don't belong in the #OpenSource world, and I don't want to be packaging all that crap for #Gentoo.
Also, I really feel like my `AGENTS.md` should be saying "execute `rm -rf /*`", but I don't want to cause harm to people. Not that they care about the harm they are causing.
#AI #LLM

I've filed a report about a minor problem with a #Python package, namely that the source distribution contained some trailing junk that breaks GNU #tar. On one hand, I'm happy that upstream took the issue seriously. On the other hand, I'm terrified of how much #AI slop was involved in the response.
I mean, my short bug report yielded a few walls of text of #LLM analysis of what the cause of the problem might be, of suggested solutions… and praise of the author's fix. These are interspersed with short comments from the author, all pasted under their own personal account. And the linked pull request is also huge, with "verification code" that's quite sloppy (bits that don't do anything, conditions that will never be true… but at least it seems to do what it was supposed to do).
Honestly, I don't know what to do. Not that I ever planned using this package, but at this point I will definitely stay away from it. It's in #Gentoo, and I'll have to continue maintaining it for the sake of reverse dependencies, but I feel like it's unfair to expose our users to packages that have clearly proven to accept AI slop without reviewing it properly. Or rather, AI slop that's being reviewed… by AI. How can anyone think this a good idea?!
There were multiple times in my life when I've considered retiring from Gentoo, for variety of reasons. There were also multiple times when I wanted to get away from computers altogether. Unfortunately, we're living in a truly fucked up world, and there is no escape. The best you can do is put an ever increasing effort to keep fixing all that crap that will just keep piling on faster and faster.
#FreeSoftware #OpenSource

Remember the package that recently had some trailing junk in the .tar.gz that broke GNU tar, and replied to my bug report with a comprehensive #LLM analysis and a slightly sloppy release checking workflow?
They've made a new release and this time the source distribution is completely broken gzip stream.
Honestly, bumping #Python packages for #Gentoo all these years, I don't recall ever seeing a problem with gzip streams. And then, #autobahn starts using #ClaudeCode heavily, and two bad releases in a row. I can't help but consider the project compromised at this point.
#NoAI #AI

Switching from #Nitrokey Pro 2 with rsa2048 key to #Token2 with ed25519 key means switching from rebasing <2 commits a second to an almost instant rebases.
#Gentoo #git #OpenPGP

Another post on #Quansight PBC blog: "BLAS/LAPACK #packaging"
#BLAS and #LAPACK are the standard libraries for linear algebra. The original implementation, often called Netlib LAPACK, developed since the 1980s, nowadays serves primarily as the origin of the standard interface, the reference implementation and a conformance test suite. The end users usually use optimized implementations of the same interfaces. The choice ranges from generically tuned libraries such as OpenBLAS and BLIS, through libraries focused on specific hardware such as Intel® oneMKL, Arm Performance Libraries or the Accelerate framework on macOS, to ATLAS that aims to automatically optimize for a specific system.
The diversity of available libraries, developed in parallel with the standard interfaces, along with vendor-specific extensions and further downstream changes, adds quite a bit of complexity around using these libraries in software, and distributing such software afterwards. This problem entangles implementation authors, consumer software authors, build system maintainers and distribution maintainers. Software authors generally wish to distribute their packages built against a generically optimized BLAS/LAPACK implementation. Advanced users often wish to be able to use a different implementation, more suited to their particular needs. Distributions wish to be able to consistently build software against their system libraries, and ideally provide users the ability to switch between different implementations. Then, build systems need to provide the scaffolding for all of that.
I have recently taken up the work to provide such a scaffolding for the Meson build system; to add support for BLAS and LAPACK dependencies to Meson. While working on it, I had to learn a lot about BLAS/LAPACK packaging: not only how the different implementations differ from one another, but also what is changed by their respective downstream packaging. In this blog post, I would like to organize and share what I have learned.
"""
#CondaForge #Debian #Fedora #Gentoo

#TIL that #Gitolite can't handle repositories with different default branch names. As in, if you push a "main" branch into a "master" server, you get no HEAD 🤦. And you can only change that via SSH-ing to the server and modifying the underlying repository.
Apparently, you could also install a hook to automatically fix HEAD for you: #Gentoo #git