Search
1000 results for “Gentoo_eV”
-
🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym OprogramowaniemNowoś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. -
🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym OprogramowaniemNowoś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. -
🤚 Wolna sobota
👉 Sobota z pracą nad Wolnym OprogramowaniemNowoś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. -
ぶち上げ完了🎀
gentoo-sources-6.17.5 配信！
変更点ハイライト：
・TCP_TX_DELAY×大RTT時のtso判断を調整＝スループット停滞を緩和
・USBnetでのsmp_processor_id警告を抑止＝再開やMTU変更時の安定度UP
・ksmbdの名前付きパイプopenでのロック噛み合いを修正＝固まり回避
・Intel Xe：BARリサイズの順序見直し＋VRAM領域初期化を整理＝初期化の足並み安定化
・Cadence D-PHYのキャリブ待機値是正＝一部DSIパネルのPLLタイムアウト抑制
日常運用での“じわ不調”をまとめてケア🛡️✨
#Gentoo #Linux #Kernel #TCP #USB #SMB #IntelXe -
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.
""" -
Gentoo was trying to download rust-bin 1.74.1 to compile rust 1.74.1 to compile rust 1.75.0 to compile rust 1.76.0 to compile rust 1.77.1 to compile rust 1.78.0 to compile rust 1.79.0 to compile rust 1.80.1 to compile rust 1.81.0 to compile rust 1.82.0 to compile rust 1.83.0 to compile rust 1.84.1 to compile rust 1.85.1 to compile rust 1.86.0 to compile rust 1.87.0 to compile rust 1.88.0 to compile rust 1.89.0 🫠
-
No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.
Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.
Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.
Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.
-
Wow. All the big packages updating on my #Gentoo #Linux box. Been about 20 hours, 165 of 201 completed.
That's what I get for not updating for about 10 days.
Oh, and encfs is depreciated and going bye-bye. Luckily I have next weekend off and will have some time to switch all my local backups to #GoCryptFS.
I need to submit my workbook to the print shop for next #AdultESOL term.
#CyberSecurity class starts tomorrow.
International dinner at school in two weeks.
I'll sleep when I'm dead.
-
Wow. All the big packages updating on my #Gentoo #Linux box. Been about 20 hours, 165 of 201 completed.
That's what I get for not updating for about 10 days.
Oh, and encfs is depreciated and going bye-bye. Luckily I have next weekend off and will have some time to switch all my local backups to #GoCryptFS.
I need to submit my workbook to the print shop for next #AdultESOL term.
#CyberSecurity class starts tomorrow.
International dinner at school in two weeks.
I'll sleep when I'm dead.
-
Wow. All the big packages updating on my #Gentoo #Linux box. Been about 20 hours, 165 of 201 completed.
That's what I get for not updating for about 10 days.
Oh, and encfs is depreciated and going bye-bye. Luckily I have next weekend off and will have some time to switch all my local backups to #GoCryptFS.
I need to submit my workbook to the print shop for next #AdultESOL term.
#CyberSecurity class starts tomorrow.
International dinner at school in two weeks.
I'll sleep when I'm dead.
-
Wow. All the big packages updating on my #Gentoo #Linux box. Been about 20 hours, 165 of 201 completed.
That's what I get for not updating for about 10 days.
Oh, and encfs is depreciated and going bye-bye. Luckily I have next weekend off and will have some time to switch all my local backups to #GoCryptFS.
I need to submit my workbook to the print shop for next #AdultESOL term.
#CyberSecurity class starts tomorrow.
International dinner at school in two weeks.
I'll sleep when I'm dead.
-
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.
-
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.
-
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.
-
Szybka synchronizacja z anglojęzycznym kontem:
1.
Mój laptop parę lat temu: mocniejsza maszyna z mojego duetu w distcc.
Mój laptop dziś: nie wyrabia ze wstępnym przemieleniem kodu C++, żeby przekazywać go na bieżąco stacjonarnemu do kompilacji.
2.
No więc rzekomo kończą się adresy IPv4, nie?
W międzyczasie jakieś boty z fikcyjnym UA (pozdrawiamu użytkowników Safari na Windows) uśmiercają Bugzillę #Gentoo, przeszukując ją z 600 tys. unikalnych adresów IPv4.
Przypominam: jeżeli używacie "#AI", to wspieracie proceder, który zabija #WolneOprogramowanie.
-
That Gentoo feel, and that Mint one... The install of Calculate Linux Cinnamon took exactly 14 minutes, partitioning, pipewire and update included. Nifty distro, had some previous looks at it but now for a longer test. And it stays very close to Gentoo, but improves some generic processes for the end user (updating, cleaning cruft etc). Nice! 🐮
#calculatelinux #gentoo -
Just in case others have problems connecting their JBL Charge 6 or Flip 7 bluetooth speaker to their computer, failing with "SET_CONFIGURATION request rejected: Unknown error (216)" – Today I learned that this is fixed with >=media-video/pipewire-1.4.7:
https://discussion.fedoraproject.org/t/jbl-flip-7-a2dp-connection-failure-on-fedora-42-bluez-pipewire/155958/8
https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2451I added it to my /etc/portage/package.accept.keywords and now the speaker works like a charm. Nice! 🙂
-
Gdyby ktoś potrzebował takich danych, to budowanie Flanga (przy pomocy Clanga, na AArch64) z -j96 powoduje maksymalne użycie RAM-u na poziomie 102G.
-
@wonderfox_dev
Чтоб начать понимать #Gentoo, ставьте сперва #Calculate и переводите её в режим сборки всех пакетов. Потом посидите годик-два, изучите вику, включая гентушную. -
Jak bywa to w innych dużych projektach Wolnego Oprogramowania, twórcy #Gentoo miewają różny stopień aktywności. Jedni poświęcają sporą część swojego wolnego czasu, opiekują się setkami paczek, udzielają się w wielu obszarach. Inni mają węższe zainteresowania, produkują się mniej, ale wciąż wkładają wysiłek, by Gentoo było lepsze — i to się liczy. No i jest też ogon.
Mamy więc kilku takich, których głównymi talentami zdają się być 1) wyszukiwanie paczek, które nie wymagają praktycznie żadnego wysiłku, i 2) uzasadnianie swojego statusu długimi esejami. I to już przekracza granice absurdu. Nie mówimy tu o "wszystkie moje paczki są aktualne". Ani o "moje paczki nie wymagają wiele wysiłku, dlatego też nie widać wiele z mojej strony". Ci ludzie mówią wprost "celowo wybrałem paczki, które nie wymagają wysiłku, żebym nie musiał nic robić". No ale oczywiście tacy ludzie koniecznie muszą zachować dostęp do repozytorium, i wykorzystywać swój status — i jest to *cholernie nieuczciwe*.
A w międzyczasie inni mają tyle na głowie, że ulegają wypaleniu. A wówczas rezygnują z opieki nad kolejną częścią dystrybucji. I kto wtedy musi tę pracę przejąć? Oczywiście, nie ci, którzy właśnie przyznali, że nie mają nic do roboty…
-
Biblioteki eclass związane z Pythonem w #Gentoo są całkiem aktualne. Stosują się do aktualnych zaleceń i standardów, i usuwają na bieżąco rzeczy przestarzałe. Niemniej, mają za sobą długą historię, i najlepiej chyba to widać po nazewnictwie.
Biblioteki te powstały w celu zastąpienia wcześniejszych "distutils" i "python". Dlatego też nazwałem je odpowiednio "distutils-r1" i "python-r1", podążając za schematem rewizji dla ebuildów. Dla spójności, pozostałe biblioteki również doczekały się sufiksu "-r1": "python-any-r1", "python-single-r1" i "python-utils-r1" — mimo że nigdy nie istniały w wersji "r0".
Wkrótce poznałem swój pierwszy błąd. Uczyniłem bibliotekę odpowiedzialną za budowanie paczek dla wielu implementacji "domyślną", prawdopodobnie w oparciu o ówczesne rekomendacje pisania ebuildów. Jednak z czasem odkryłem, że w większości przypadków (tam, gdzie nie używamy "distutils-r1") nie potrzeba takiej funkcjonalności, a ebuildy stają się niepotrzebne skomplikowane. Gdybym wybierał nazwy dzisiaj, najpewniej nazwałbym ją "python-multi", żeby podkreślić zastosowanie. A "domyślnej" albo by nie było w ogóle, albo byłaby nią "python-single".
Z "distutils-r1" jest jeszcze gorzej. Oczywiście, kiedy powstawała, distutils wciąż istniało, a niektórzy ludzie (jak ja) preferowali je nad zależnością od setuptools. A dziś zostało już całkiem pochłonięte przez setuptools, a za sprawą #PEP517 nawet "setuptools" nie jest już dobrą nazwą. No i ludzie dziwią się, że np. dla systemu budowania Hatchling mają używać "distutils-r1".
No i to już jest coś, co mogłem zrobić lepiej. Wprowadzenie wsparcia PEP517 była sporą zmianą, i zamiast dodawać zmienną DISTUTILS_USE_PEP517 (nazwa ze sprzecznością), mogłem utworzyć nową bibliotekę. Dlaczego tego nie zrobiłem? Cóż, jeden i drugi tryb dzieliły ze sobą sporo kodu, i nie było sensu go duplikować. Oczywiście, z czasem wspólnego kodu było trochę mniej, i w końcu wsparcie starego trybu wyleciało — ale to już po ptakach.
(1/2)
