Did every single damned Haskell package get masked on Gentoo?
#gentoo
22 posts20 participants2 posts today
Until #Gentoo portage catches up with the packages needed for #StumpWM to run without crashing, I think I'll give #QTile a go. Can't do the keyboard shortcut things I want, but neither can most other WM or DEs.
Should be very helpful with the new 3440x1440 monitor arriving tomorrow. Large fonts AND two windows next to each other. Sounds great; I can't wait to experience it. (Upgrading from 1920x1080.)
#KWin compilations are killing my PC again…
AHHHHNNGGGHHH!!!
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.
Replied in thread
@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.
GitHubaya_ebpf overrides C library `memcpy()` function with an implementation with incorrect return value · Issue #1254 · aya-rs/aya
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.
GitHubaya_ebpf overrides C library `memcpy()` function with an implementation with incorrect return value · Issue #1254 · aya-rs/aya
Continued thread
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ś.
Pol.socialmgorny-nyan (on) :autism:🙀🚂🐧 (@mgorny@pol.social)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ść.
#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.
Treehouse Mastodonmgorny-nyan (he) :autism:🙀🚂🐧 (@mgorny@treehouse.systems)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.
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ść.
GitHub`compile_test` fails with non-nightly compiler · Issue #250 · aya-rs/bpf-linker
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.
GitHub`compile_test` fails with non-nightly compiler · Issue #250 · aya-rs/bpf-linker
Replied in thread
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.