Typical me:

1. You're waiting for something at dayjob, so you start doing some TODOs from #Gentoo.
2. In the meantime, new kernels are releases, so you do them instead.
3. Back to dayjob, busy for the whole day.
4. Near evening, you recall that you've started a bunch of things for Gentoo, so you take a break and start doing them instead.
5. You are so tired you defer the rest of dayjob to tomorrow.
6. You recall it's #BandcampFriday, and you were supposed to buy something.

But duty fulfilled!

I just now need to remember to unpack them when they're finally done downloading, because of course I'm fetching to /tmp.

#Matplotlib has a lot of "image comparison tests" that are horrible fragile. Technically, most of them permit some deviation from the reference images, but quite often I've been getting higher RMS than that. So for a long time, we've been maintaining patches that increased the tolerance in tests, and regularly either had to be rebased and updated for new tests.

At some point upstream started adding conditions permitting higher tolerance on non-x86_64 platforms. Of course, these changes forced me to rebase our patches. Curious enough, my previous overrides often happened to be close to the tolerance given for non-x86_64 platforms.

Today, it finally occurred to me that instead of updating the patch once again, I can try dropping it entirely and just sed-ing all `platform.machine() == 'x86_64'` with `False`. And guess what — down to 3 failures (related to TeΧ). And I don't have to spend 15 minutes manually doing what effectively accounted to the same thing.

#RUNBSD! But BoxyBSD now also starts to support #Linux! We're starting soon with the Linux support for already present users, offering free boxes:

* #AlmaLinux
* #Alpine
* #Debian
* #Devuan
* #CentOS
* #Fedora
* #Gentoo
* #OpenSuse
* #OpenEuler
* #RockyLinux

Just next to our core OS like #FreeBSD, #OpenBSD, #NetBSD, #MidnightBSD and #DragonflyBSD (and #illumos). This should also make the step easier to compare and test different scenarios where BSD provides a different behavior compared to Linux systems.

Thanks to @gyptazy for the implementation!

#Gentoo
#DistributionKernel

I have been trying to find this for a bit. Finally someone in a Reddit thread linked it.

For people using the Gentoo Distribution Kernel, this can be used to more easily handle your config.

https://codeberg.org/ranguli/gentoo-popcorn-kernel

When you use #RustLang to write safe code, but what you get is a data corruption #heisenbug instead.

https://github.com/milesgranger/cramjam/issues/201

#SecureBoot
#Gentoo

So I am trying to ensure the setups on my laptops are secureboot setup this time. I figure its a decent idea to keep with some kind of standard there.

I rebuilt the HP because my full disk encryption setup was just too irritating. Gonna have to just keep encryption to external drives I suppose.

What I've planned to be doing: adding CPU_FLAGS_* support to #NumPy package in #Gentoo.

What I am doing instead: digging through #ARM documentation, kernel sources, NumPy sources to figure out what's missing from CPU_FLAGS_ARM and how to detect it.

New on blog: "EPYTEST_PLUGINS and other goodies now in #Gentoo"

"""
If you are following the gentoo-dev mailing list, you may have noticed that there’s been a fair number of patches sent for the #Python eclasses recently. Most of them have been centered on #pytest support. Long story short, I’ve came up with what I believed to be a reasonably good design, and decided it’s time to stop manually repeating all the good practices in every ebuild separately.

In this post, I am going to shortly summarize all the recently added options. As always, they are all also documented in the Gentoo Python Guide.
"""

https://blogs.gentoo.org/mgorny/2025/07/26/epytest_plugins-and-other-goodies-now-in-gentoo/

All #Gentoo users should know about PORTAGE_SCHEDULING_POLICY="idle", which keeps your system responsive during updates, even with cranked up MAKEOPTS.

https://wiki.gentoo.org/wiki/Portage_niceness#Scheduling_policy
https://wiki.gentoo.org/wiki/MAKEOPTS

If someone wants to investigate a curious issue:

https://github.com/nedbat/coveragepy/issues/2008

Long story short, for some reason #Python 's subprocess module reports the exit status for a signaled process as (128 + signal) for upstream (similarly to how bash's `$?` works), but -signal (as documented) for me.

Perl Versioning Scheme and Gentoo

https://wiki.gentoo.org/wiki/Project:Perl/Version-Scheme

In 2010 I went to #FOSDEM on behalf of the #Sabayon #Linux distro I was working on back then. It was a great inspiring experience! Meeting up with upstream #Gentoo developers. Talking with people working on #FOSS projects. Best talk IMHO was this one.

https://www.youtube.com/watch?v=bx3KuE7UjGA

Been around since early Sabayon as a repository maintainer/developer and stayed in close contact with folks across these projects. This video gets it right. Agree?

https://www.youtube.com/watch?v=Fde_MkKipUc

Always nice when upstream accepts a trivial fix even though the obvious bug doesn't affect them right now.

https://github.com/lmfit/lmfit-py/pull/1011

How you don't want to spend your Saturday: figuring out how many regressions #LLVM developers managed to sneak in just before the 21.x branching, and then bisecting them.

The answer: 2 serious regressions breaking libclc build and install, 2 test regressions in clang and compiler-rt respectively (the former quickly reverted on main, for the second time, but nobody thought of backporting), and 1 assertion failure in experimental backend.

Now I really hope I'll manage a clean run for 21.1.0-rc1 with the biggest zero-day LLVM patchset in the history of #Gentoo.

LLVM downstream maintenance is a nightmare.

Your package has 60 thousand tests. You're thinking: "I have good test coverage."

I'm thinking: "half an hour later, a single test will fail. Then I'll spend another half an hour retesting…"