The quality of modern software, AKA the #Flatpak generation.
1. I bump a package in #Gentoo in the morning.
2. When I get home, the package doesn't install anymore — it turns out that upstream removed it before Gentoo mirrors managed to fetch it.
3. I remove the new version from Gentoo, only to discover that the previous version was removed as well, at some point — silently, with no trace.
Jakość nowoczesnego oprogramowania, czyli generacja #Flatpak.
1. Rano wrzucam nową wersję paczki do #Gentoo.
2. Po powrocie okazuje się, że nowej wersji nie idzie zainstalować, bo autor ją wywalił, zanim nasze serwery lustrzane ją złapały.
3. Usuwam więc nową wersję z Gentoo, i odkrywam, że poprzednią wersję też kiedyś usunięto — cichaczem, bez jakiegokolwiek śladu.
Kurtyna opada.
@dwarf@borg.social It seems to work fine on #Gentoo for me!
Sometimes it's just old cruft in the config files: Screensharing with #Firefox on #kdeplasma was not working on #Gentoo. Turned out it was just an old USE=-screencast left over from the pre-wayland days… 
Anyone get #StumpWM working on #Gentoo #Linux?
It seems there is an issue in CLX or maybe SBCL that causes StumpWM to exit with an error at start. Supposedly fixed in updated CLX package, but that isn't in portage yet.
I'd like to try putting the newer version in /usr/local/ and having StumpWM use that. Not sure the best way to go about that, though.
Or, maybe a local package (portage overlay) would be better? Haven't done that before - maybe a good spring break project, though.
I love #Gentoo #Linux so much. I can run one command on my terminal and watch as for 36 hours my old #Thinkpad T420 compiles every program on my entire system down to the compilers themselves and the system utils one by one, in a sensical order, with no errors or any further user input required.
It's truly magical.
No więc skończyłem walkę z segfaultem w #mitmproxy-linux. Okazuje się, że segfault miał miejsce w #Gentoo #Sandbox. Nadebugowałem się, ale znalazłem przyczynę. Otóż, okazuje się, że z jakiegoś powodu, aya_ebpf nadpisuje systemową implementację memcpy() własną, napisaną w Ruście, która zwraca niepoprawną wartość.
#RustLang jest naprawdę wspaniałym tworem.
So finished debugging #mitmproxy-linux segfault. It turned out it was a segfault in #Gentoo #Sandbox. After dire debugging, it turns out that, for some reason, aya_ebpf crate overrides the system memcpy() function with a #RustLang implementation that has incorrect return value.
Rust is truly impressive.
Of course I wouldn't update my host and my vm's when I'm going to be busy for a few days.
When I'm about to do updates/upgrades, I prepare myself mentally ; patience set to infinite and common sense turned on. I'm also prepared to program when it becomes necessary to get through the job.
When the time comes, I'll come for you, Gentoo. I'm just gathering the energy & willpower to try you out for reals on my bear metal, albeit lazily.
Aktualizacja w temacie #mitmproxy, czyli jak nie zamierzałem spędzać soboty.
Poprzednio: https://pol.social/@mgorny/114364801169118580
Tak więc:
1. Z pomocą osoby nickiem vadorovsky, dowiedziałem się, że jak dam --no-default-features, to bpf-linker użyje systemowego LLVM, i w ten sposób pozbyłem się problemów nr. 2 i 4.
2. #LLVM 20 nadal się sypie, ale jakimś cudem wtorkowy snapshot LLVM 21 działa.
3. Musiałem wrzucić btfdump na potrzeby testów, ale teraz wszystkie przechodzą.
4. Zmarnowałem godziny na budowanie mitmproxy-linux, ale w końcu znalazłem sposób. Otóż, okazuje się, że muszę wywalić logikę budowania binarek w formacie bpf z tej paczki, zbudować je ręcznie z poprawną wartością RUSTFLAGS, a potem połączyć to w całość. https://github.com/mitmproxy/mitmproxy/issues/7663
5. Problem z rustc-build-sysroot jest jeszcze gorszy w mitmproxy-linux.
6. Testy mitmproxy-linux segfaulcą (jak to #RustLang).
7. Ale jak już wszystko poinstaluję, to testy mitmproxy przechodzą.
Więc zostaje mi wymyślić, co zrobić z tymi segfaulcącymi testami, i myślę, że nowa wersja mitmproxy może wylądować w #Gentoo. Przypięta do pojedynczej wersji kompilatora Rusta, ale zawsze coś.
#mitmproxy update AKA not how I imagined spending my Saturday.
Previous post: https://social.treehouse.systems/@mgorny/114364774872404427
So:
1. With help of vadorovsky, I've learned that I need to pass --no-default-features, and then it uses system LLVM which resolves problems 2. and 4.
2. #LLVM 20 still fails on that assertion, but Tuesday's LLVM 21 snapshot works fine.
3. I also needed to package btfdump for bpf-linker's tests but I was finally able to get them to pass.
4. After spending hours trying to figure out mitmproxy-linux build failures, I've finally found a way to build it: I need to remove upstream's logic for building bpf binaries, build them manually with correct RUSTFLAGS, and then build the whole thing. https://github.com/mitmproxy/mitmproxy/issues/7663
5. rustc-build-sysroot crate problem is even worse in mitmproxy-linux.
6. mitmproxy-linux's tests segfault (yeah, #RustLang).
7. But still, with the packages built, I can get tests to pass on mitmproxy itself.
So yeah, if I can only figure out what to do about these segfaulting tests, I think we can get new mitmproxy version into #Gentoo. Pinned to one Rust version, but that's better than nothing, I guess.
Zmarnowałem kolejną godzinę na użeranie się z próbą dodania bpf-linker / nowej wersji #mitmproxy do #Gentoo. Podsumowując:
1. Wymaga funkcji, dostępnych wyłącznie w eksperymentalnych wersjach kompilatora #RustLang. Można to obejść, ustawiając RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250
2. Wymaga innych wersji kilku bibliotek poprzez zależność aya-rustc-llvm-proxy, jakimś cudem. Można to albo rozwiązać dodając do ebuilda owe wersje, albo usuwając z wypakowanego archiwum plik `Cargo.lock`.
3. Wymaga `compiler_builts` poprzez zależność rustc-build-sysroot. Co ciekawe, konkretna wersja jest przypięta wewnątrz biblioteki standardowej Rusta, więc musiałbym dodać odpowiednią wersję zależności dla każdej obsługiwanej wersji kompilatora!
4. Ma własną logikę wyszukiwania biblioteki #LLVM, która porusza się po PATH i podmienia `bin` na `lib`. Tak, na katalog z 32-bitowymi bibliotekami. Da się to obejść, ustawiając LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270
5. Nawet jak obejdę wszystkie inne problemy, to koniec konców się sypie na użyciu LLVM. Zgaduję, że nikomu nie przyszło do głowy użyć do testów LLVM z kontrolą poprawności użycia API. https://github.com/aya-rs/bpf-linker/issues/271
No cóż, taka jakość programów pisanych w Ruście. Co gorsza, te wszystkie problemy dotyczą nie budowania, a uruchamiania bpf-linkera — więc tak czy siak, instalowalibyśmy program, który w ogóle nie działa bez dodatkowych obejść.
Spent another hour on trying to get bpf-linker / new #mitmproxy into #Gentoo. To summarize:
1. It needs features from nightly #RustLang compiler at runtime. This can be worked around via setting RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250
2. It needs different pinned versions of some libraries via aya-rustc-llvm-proxy somehow. This can be solved via manually adding more crates to the ebuild (sigh) or just removing the extra `Cargo.lock` from the crate.
3. It needs `compiler_builtins` crate via rustc-build-sysroot crate. Funny enough, the version is pinned by Rust standard library itself, so I need to add a specific crate for every supported Rust compiler version!
4. It uses a homemade logic to find #LLVM library, which iterates over PATH and replaces `bin` with `lib`. Yes, with 32-bit libdir. It can be worked around via setting LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270
5. Even after working around all these issues, it crashes by triggering an assertion in LLVM. I guess nobody bothered testing with assertions enabled, as usual. https://github.com/aya-rs/bpf-linker/issues/271
So yeah, that's your Rust quality. On top of that, let's not forget that this is all runtime issues — like we would be installed a bpf-linker executable that's nonfunctional unless you apply workarounds.
Я много раз встречал в интернете мысль, что, мол, бинарная совместимость в #linux уже не та, мол нельзя скопировать бинарник с одного линукса на другой -- обязательно ругнётся на версию GLIBC или не найдёт libcups.so.2
Однако я только что скопировал /usr/bin/kissat из #Gentoo внутрь #qemu с #ubuntu #Plucky #Puffin и там #kissat сразу же работает как надо.
Просто свежее должно всё быть 
Am I crazy for considering modifying the #Mozilla #Firefox code and recompiling just to get #emacs -like shortcuts? Even just ctrl-s for search and ctrl-w for cut (or at least turning off ctrl-w = close the window) would be huge time savers and "oops" removers.
Supposedly there are ways to add some #javascript to dirs to make these changes, but honestly, it seems more difficult than tweaking & recompiling.
Seems that extensions can't get deep enough to change some shortcuts.
#HDF5 jest super. W skrócie:
1. Oryginalnie, projekt używał systemu budowania autotools. Instalował binarkę h5cc, która — obok bycia nakładką na kompilator — miała dodatkowe opcje do uzyskiwania informacji o instalacji HDF5.
2. Później dodano alternatywny system budowania #CMake. W ramach tego systemu budowania instalowana jest uproszczona binarka h5cc, bez tych dodatkowych funkcji.
3. Każdy, kto próbował budować przez CMake, szybko odkrywał, że ta nowa binarka psuje większość paczek używających HDF5, więc wracano do autotools i zgłoszono problem do HDF5.
4. Autorzy zamknęli zgłoszenie, stwierdzając (tłum. moje): "Zmiany w h5cc przy użyciu CMake zostały udokumentowane w Release.txt, kiedy ich dokonano - kopia archiwalna powinna być dostępna w plikach z historią."
5. Autorzy ogłosili zamiar usunięcia wsparcia autotools.
Co stawia nas w następującej sytuacji:
1. Praktycznie wszyscy (przynajmniej #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) używa autotools, bo budowanie przy pomocy CMake psuje zbyt wiele.
2. Oryginalnie uznano to za problem w HDF5, więc nie zgłaszano problemu innym paczkom. Podejrzewam, że wiele dystrybucji nawet nie wie, że HDF5 odrzuciło zgłoszenie.
3. Paczki nadal są "zepsute", i zgaduję, że ich autorzy nawet nie wiedzą o problemie, bo — cóż, jak wspominałem — praktycznie wszystkie dystrybucje nadal używają autotools, a przy testowaniu budowania CMake nikt nie zgłaszał problemów do innych paczek.
4. Nawet nie mam pewności, czy ten problem da się "dobrze" naprawić. Nie znam tej paczki, ale wygląda to, jakby funkcjonalność usunięto bez alternatywy, i tym samym ludzie mogą co najwyżej samemu zacząć używać CMake (wzdych) — tym samym oczywiście psując swoje paczki na wszystkich dystrybucjach, które budują HDF5 przez autotools, o ile nie dodadzą dodatkowo kodu dla wsparcia tego drugiego wariantu.
5. Wszystko wskazuje na to, że HDF5 jest biblioteką, której autorów nie obchodzą ich własni użytkownicy.
#HDF5 is doing great. So basically:
1. Originally, upstream used autotools. The build system installed a h5cc wrapper which — besides being a compiler wrapper — had a few config-tool style options.
2. Then, upstream added #CMake build system as an alternative. It installed a different h5cc wrapper that did not have the config-tool style options anymore.
3. Downstreams that tried CMake quickly discovered that the new wrapper broke a lot of packages, so they reverted to autotools and reported a bug.
4. Upstream closed the bug, handwaving it as "CMake h5cc changes have been noted in the Release.txt at the time of change - archived copy should exist in the history files."
5. Upstream announced the plans to remove autotools support.
So, to summarize the current situation:
1. Pretty much everyone (at least #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) is building using autotools, because CMake builds cause too much breakage.
2. Downstreams originally judged this to be a HDF5 issue, so they didn't report bugs to affected packages. Not sure if they're even aware that HDF5 upstream rejected the report.
3. All packages remain "broken", and I'm guessing their authors may not even be aware of the problem, because, well, as I pointed out, everyone is still using autotools, and nobody reported the issues during initial CMake testing.
4. I'm not even sure if there is a good "fix" here. I honestly don't know the package, but it really sounds like the config-tool was removed with no replacement, so the only way forward might be for people to switch over to CMake (sigh) — which would of course break the packages almost everywhere, unless people also add fallbacks for compatibility with autotools builds.
5. The upstream's attitude suggests that HDF5 is pretty much a project unto itself, and doesn't care about its actual users.
