#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/

Według https://freepg.org/, 5 dystrybucji używa teraz #FreePG: #ArchLinux, #Debian, #Fedora, #NixOS i #Ubuntu. #Gentoo dołącza do tej listy, ale miast cichaczem wprowadzać istotne zmiany w GnuPG, dostarczamy odrębną paczkę (app-crypt/freepg), i oznaczamy ją odpowiednio:

$ gpg --version
gpg (GnuPG) 2.5.13-freepg

Ah, my two nemeses: OOM and ENOSPC.

#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

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.

Powinna obowiązywać zasada, że jeżeli dana paczka ma wiele systemów budowania do wyboru, a dana dystrybucja buduje ją przy pomocy #CMake, to powinna usuwać wszystkie zainstalowane pliki CMake, żeby oprogramowanie tworzone na tej dystrybucji było przenośne.

#Debian #Fedora #Gentoo

Another post on #Quansight PBC blog: "BLAS/LAPACK #packaging"

https://labs.quansight.org/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

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.

https://github.com/crossbario/autobahn-python/issues/1716
https://github.com/crossbario/autobahn-python/issues/1735

#NoAI #AI

Pamiętacie, jak wspominałem o paczce, która miała trochę śmieci w pliku .tar.gz, przez co GNU tar rzucał błędami, a autor odpowiadział na moje zgłoszenie rozbudowaną analizą z #LLM-a i zaimplementował nieco zabełkocony kod do sprawdzania poprawności archiwum?

Wyszła nowa wersja, i tym razem archiwum to całkiem zepsuty gzip.

Szczerze mówiąc, przez te wszystkie lata opieki nad paczkami Pythona w #Gentoo, chyba nigdy nie spotkałem się z problemem z gzipami. A teraz #autibahn zaczyna intensywnie korzystać z #ClaudeCode i mamy dwa wydania z rzędu z dziwnymi problemami. Cóż, dla mnie ten projekt jest już spalony.

https://github.com/crossbario/autobahn-python/issues/1716
https://github.com/crossbario/autobahn-python/issues/1735

#Python #AI

So #Gentoo is now shipping "extremist" software, apparently.

https://bugs.gentoo.org/964663

To teraz #Gentoo jakoby zawiera "ekstremistyczne" oprogramowanie.

https://bugs.gentoo.org/964663

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

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-

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.
"""

https://blogs.gentoo.org/mgorny/2025/10/12/how-we-incidentally-uncovered-a-7-year-old-bug-in-gentoo-ci/

#Gentoo