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

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

🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym Oprogramowaniem

Nowości w #Gentoo:
• #Gemato wspiera #FreePG i w większości #SequoiaPGP chameleon.
• Przygotowałem wsparcie FreePG i SequoiaPGP chameleon jako dostawców "gpg".
• #FlexiBLAS jest teraz używany domyślnie w ~arch.
• W końcu dokończyłem sprawdzanie nieużywanych podpisów paczek #PyPI w #PkgCheck.
• gpy-list-pkg-impls teraz uwzględnia "czy ta paczka ma testy?", może opcjonalnie włączać wyniki PythonCompatUpdate z PkgCheck i stosować kolorki mIRC-a. Innymi słowy, nasz bot IRC-owy będzie podpowiadał nam, kiedy zależności będą umożliwiać portowanie kolejnych paczek na Pythona 3.14, i czy te paczki mają testy.

Wspominałem już może, że pracuję nad przejściem #Gentoo z na wpół zepsutego eselect-ldso dla #BLAS / #LAPACK, na #FlexiBLAS. Oznacza to również, że czeka nas okres przejściowy, w czasie którego obydwa rozwiązania będą wspierane.

Plus jest taki, że stan "po" jest kompatybilny pod względem ABI ze stanem "przed" (a przynajmniej powinien być — pracujemy z autorami, by poprawić ostatnie niedociągnięcia). Zastępujemy libblas.so, liblapack.so i inne biblitoteki dowiązaniami symbolicznymi, więc programy skompilowane przed zmianą po prostu zaczną używać FlexiBLAS.

Minus jest taki, że w drugą stronę nie jest tak łatwo. Po zastąpieniu biblitotek dowiązaniami, nowoskompilowane programy będą odczytywać SONAME z biblioteki docelowej, a więc zaczną się wiązać bezpośrednio z FlexiBLAS. Co za tym idzie, powrót do stanu poprzedniego będzie wymagał ich ponownej kompilacji.

Aby tego uniknąć, musielibyśmy zamiast dowiązań symbolicznych zastosować jakieś biblioteki pośredniczące, które miałyby "stare" SONAME, a korzystąły z funkcji FlexiBLAS. Niestety, nic prostego tu nie zadziała — musiałbym jakoś "wyeksportować" symbole z FlexiBLAS, i najlepiej podzielić je na odpowiednie biblioteki, żeby `-Wl,--as-needed` nic nie wycięło. Tylko jak to zrobić?

Cóż, eselect-ldso tworzy jakieś biblioteki, więc może uda się coś wykorzystać. No i szukam w źródłach, i nic nie mogę znaleźć. W końcu do mnie dociera, że cała logika dodana jest przez łatki Gentoo. A te łatki są po prostu paskudne. W OpenBLAS tworzymy dodatkowe biblioteki libblas.so, itp., które zawierają kopie obiektów z OpenBLAS i wiążą się z libopenblas, żeby pobrać brakujące zależności. Nawet nie wiążą się jedna z drugą, więc każda duplikuje sporo kodu niezależnie. Łatki dla BLIS są jeszcze gorsze — tu libblas.so i libcblas.so to praktycznie kopie libblis.so, z poszczególnymi "niepotrzebnymi" symbolami ukrytymi przy pomocy "visibility".

No cóż, można się było tego spodziewać po projekcie z #GSoC.

I've probably mentioned that I'm working on switching #Gentoo from our half-broken eselect-ldso logic to #FlexiBLAS. This also involves a transition period where both setups would be supported.

A good thing is that the switch is ABI-compatible with the previous state (or at least it's supposed to be — we're working with upstream on fixing function coverage). Since libblas.so, liblapack.so and the rest are replaced by symlinks, programs that link to them will simply start using FlexiBLAS. So far, so good.

Unfortunately, switching the other way doesn't work as well. Stuff newly built against our libblas.so & co. symlinks naturally reads FlexiBLAS's SONAME from them, and links to libflexiblas directly. So should you decide to switch back, some packages will stay linked to FlexiBLAS and will need to rebuilt.

In order to avoid this, I would have to replace the symlinks with wrapper libraries, having libblas.so.3 and so on SONAMEs, and linking to libflexiblas. Unfortunately, a dummy wrapper isn't going to work — the linker will complain about using indirect symbols from libflexiblas.so. So I would probably have to "reexport" their symbols somehow, and ideally split into appropriate libraries, so that `-Wl,--as-needed` wouldn't drop some of them. But how to do that?

Well, let's look at the existing logic for eselect-ldso — clearly both BLIS and OpenBLAS create some wrappers. So I've spent some time investigating upstream Makefiles, and literally couldn't find the respective targets. I mean, these are quite complex Makefiles, but I'm grepping hard and can't find even a partial match.

As it turns out, these Makefile targets are added by Gentoo-specific patches. And these patches are just horrible. In case of OpenBLAS, they create the wrapper libraries by linking all the relevant .o files from OpenBLAS build, plus the shared OpenBLAS library. So the OpenBLAS symbols relevant to each interface end up duplicated in libblas.so, liblapack.so, etc., and apparently the symbols needed by them are taken from libopenblas.so. The individual interface libraries aren't even linked to one another, so they expose their own duplicate symbols, but use the implementation from OpenBLAS instead.

BLIS is even worse — the patch is simply creating libblas.so and libcblas.so, using all BLIS objects directly, plus symbol visibility to hide symbols irrelevant to the library. So yes, libblis.so, libblas.so and libcblas.so are roughly three separate copies of the same library, differing only in symbol visibility. And of course libcblas.so doesn't use libblas.so.

Truly #GSoC quality.

1. Zdobądź trochę wiedzy o paczkach #BLAS / #LAPACK w ramach bejmopracy.
2. Odkryj, że paczki #MKL w #Gentoo są mocno nieaktualne i ciut zepsute. Przejmij je, zaktualizuj, ulepsz.
3. Zainteresuj się #FlexiBLAS. Zacznij eksperymentować. Wrzuć paczkę do Gentoo.
4. Odkryj, że mechanizm dynamicznego przełączania BLAS / LAPACK niezbyt dobrze działa. Zaproponuj migrację do FlexiBLAS i przygotuj próbne zmiany.
5. Zauważ niespójności we wsparciu ILP64. Zaproponuj poprawki.
6. Odkryj, że wszystkie paczki BLAS / LAPACK w Gentoo są praktycznie bez opiekuna.

No więc wygląda na to, że jestem nowym opiekunem całego kompletu. Pracuję nad poprawkamj dla ILP64, a następnie będę musiał zaktualizować łatki dla migracji do FlexiBLAS.

1. Learn a bit about #BLAS / #LAPACK packaging for dayjob.
2. Learn that #MKL in #Gentoo is quite outdated. Take it over, bump it and improve the packaging.
3. Get curious about #FlexiBLAS. Start playing with it. Package it for #Gentoo.
4. Learn that runtime BLAS / LAPACK switching is quite broken. Come up with a FlexiBLAS transition plan and a proof-of-concept.
5. Notice inconsistency in ILP64 support flags. Propose unifying the behavior.
6. Learn that BLAS / LAPACK packages in Gentoo are pretty much unmaintained.

Well, looks like I'm the new maintainer of the whole stack, I'm working on consistent ILP64 support now, and then I'll have to rebase the FlexiBLAS transition bits.

Próbowałem dodać #FlexiBLAS do #Gentoo, i szczerze mówiąc, nie wygląda to dobrze.

Na dobry początek niepokoi brak otwartego systemu zgłaszania błędów. Jest GitLab, ale ograniczony do "członków ich grupy i wybranych osób z zewnątrz", ale nie wygląda na to, żeby go za bardzo używano. Jest tylko "wyślij nam maila", a potem zastanów się, ile osób zgłosiło wcześniej ten sam problem.

Repozytorium git jest aktualnie na wersji oznaczonej jako 3.4.80, która wydaje się wczesną wersją testową, i jej system budowania jest całkiem spieprzony. Nie ułatwia to weryfikacji, czy problemy, z którymi dziś mam do czynienia, są nadal aktualne.

Wygląda na to, że autorzy wspierają wyłącznie albo użycie #LAPACK-a włączonego w swoją paczkę, albo statycznie wiązanie z biblioteką systemową (nie instalujemy jej w Gentoo). Mogę niby podać ścieżkę do biblioteki dynamicznej, ale nie działa — i nie wiem, czy nie działa, bo używam biblioteki dynamicznej, czy może dlatego, że FlexiBLAS nie wspiera mojej wersji LAPACK-a. Jeżeli LAPACK-a mam zbudowanego bez przestarzałych symboli, FlexiBLAS odmawia załadowania go ze względu na brakującego symbole. Jeżeli załączę przestarzałe symbole, to wtedy FlexiBLAS sypie się już na poziomie konfiguracji, z powodu innych brakujących symboli.

Mam wrażenie, że już zmarnowałem zbyt dużo czasu na ten projekt, zwłaszcza, że jego przyszłość jest niejasna. Aktualna wersja z git jest zepsuta, nie wiem, ile już problemów zgłoszono, i czy w ogóle otrzymam jakąś odpowiedź na moje zgłoszenia. Nie świadczy to dobrze o paczce, która może stać się istotna dla dystrybucji. Nie chcemy tu katedry.

https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release

I was trying to package #FlexiBLAS for #Gentoo, and to be honest, it doesn't look that good.

The first red flag is lack of an open bug tracker. Apparently, there is the tracker on GitLab that's limited to "members of their group and selected external contributors", but it doesn't seem to be used much. So it's "send us an email", and wonder how many people sent us the same bug report before.

The git repository is currently at something tagged 3.4.80 that seems to be prerelease, and its build system is quite broken. Not exactly the best path to verify that the bugs you are hitting are still there.

Now, upstream seems to insist on either using vendored netlib #LAPACK, or statically linking to the system library (we don't install the static libraries). Apparently I can specify the shared libraries instead, but it doesn't work — and it's unclear to me whether it doesn't work because I'm using the shared libraries, or because it doesn't support my LAPACK version. If I build LAPACK without deprecated symbols, it refuses to load it at runtime because of missing symbols. And if I build it with deprecated symbols, it fails to find some symbols at CMake time.

Honestly, I feel like I've spent too much time on this project already, especially given that its future is entirely unclear to me — the current git is quite broken, I have no clue how many issues were reported already and whether my bug reports will receive any reply. It definitely doesn't fare well for a package that we might start to rely heavily on. We don't want a cathedral there.

https://www.mpi-magdeburg.mpg.de/projects/flexiblas
https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release