Been around since early Sabayon as a repository maintainer/developer and stayed in close contact with folks across these projects. This video gets it right. Agree?
Always nice when upstream accepts a trivial fix even though the obvious bug doesn't affect them right now.
Building stuff for #MocaccinoOS is a workflow that starts with a #Gentoo stage3 image. On top of that we grab the fresh #Portage tree. From there we build up all our layers.
Once everything is compiled we test it for breakages, they are rare because we are on Stable tree. Then I give the signal to the Community Repo team and they build against the packages I pushed into staging. Another little test round and we tag a new stable repository. #Docker #Linux
@Gina I've been #Gentoo since I think 2004. If you like the sense of accomplishment when your computer actually works, and you like to know exactly what it's doing at every stage, and you like performance and/or minimalism, and you don't mind it taking a week to get to any kind of graphical environment, and... you're an absolute lunatic, I can highly recommend it!
(no really, it's brilliant)
After almost a year without updating my thinkpad, it took about 12h (>800 things to update and compile)
But I wouldn’t change #gentoo for any other distro.
Given that #Gentoo #Bugzilla mail is down for three days now, if anybody needed to search for bugs changed since Friday:
https://bugs.gentoo.org/buglist.cgi?f1=delta_ts&o1=greaterthan&order=changeddate&v1=2025-07-11
@stuartl I feel your pain
At some point I looked into whether I could configure Portage to ignore Chromium updates (or, any package) unless a specific component of the version number is bumped, but I couldn't figure it out quickly enough. And then eventually I realized I wasn't using it and just uninstalled it.
```
2025-07-10 07:55:14: === (17 of 19) Merging (www-client/chromium-138.0.7204.92::/usr/portage/www-client/chromium/chromium-138.0.7204.92.ebuild)
2025-07-10 07:55:23: >>> AUTOCLEAN: www-client/chromium:0
2025-07-10 07:55:23: === Unmerging... (www-client/chromium-137.0.7151.119)
2025-07-10 07:55:28: >>> unmerge success: www-client/chromium-137.0.7151.119
2025-07-10 07:55:35: === (17 of 19) Post-Build Cleaning (www-client/chromium-138.0.7204.92::/usr/portage/www-client/chromium/chromium-138.0.7204.92.ebuild)
2025-07-10 07:55:35: ::: completed emerge (17 of 19) www-client/chromium-138.0.7204.92 to /
```
`emerge --sync` …
```
[ebuild U ] www-client/chromium-138.0.7204.100
```
*sigh*
New set of #Gentoo #Linux Distribution Kernels (6.1.143, 6.6.96, 6.12.36, 6.15.5) is out. This set brings some major changes:
• I've backported a bunch of changes from sys-kernel/gentoo-kernel to sys-kernel/vanilla-kernel that were missing — notably wider architecture support.
• I've added default #RISCV configs to 6.12 (in addition to 6.15), since Fedora had them.
• All three packages are based off the baseline kernel tarball + upstream patch (vanilla-kernel used to fetch patch-level tarball every time, and gentoo-kernel* used genpatches for patch versions). This should reduce disk space and bandwidth use.
• All three packages now support verify-sig. Rather than verifying the uncompressed tarball signature, we now use upstream `sha256sums.asc` file to verify the compressed tarball and patch.
• sys-kernel/gentoo-kernel* now repackages genpatches. This means patchset that's much leaner and faster to apply (since we just fetch and use the combined upstream patch rather than including point patches). This also means that we are able to release Distribution Kernels before gentoo-sources are done.
The changes still need to be done to 5.15 and 5.10 branches — we're going to do for the next upstream releases of these.
Jakiś czas temu, zainspirowany #Fedorą, wyodrębniłem paczki .whl z Pythonowego ensurepip w #Gentoo (właśnie sprawdziłem — "jakiś czas" to 3 lata). Umożliwiło to nam aktualizowanie ich razem z paczkami pip i setuptools, dzięki czemu nowe środowiska wirtualne otrzymują najnowszą dostępną wersję, a nie tę, którą włączono w dane wydanie CPythona.
Myślałem wówczas, by budować je z naszych systemowych paczek, ale już wówczas usuwaliśmy zagnieżdżone zależności, więc otrzymalibyśmy niepełne paczki. Zamiast tego po prostu zgarnialiśmy gotowe paczki z PyPI. A dlaczego nie budować ich na nowo ze źródeł? Pomijając fakt, że wydawało się to zbędne (wszak paczki na PyPI nie zawierają żadnego skompilowanego kodu), nie mieliśmy do tego dobrej infrastruktury w eclass.
Za inspiracją @hroncok, dziś przygotowałem nowe wersje paczek ensurepip, które budują wszystko ze źródeł. Co się zmieniło, i dlaczego warto dziś budować ze źródeł? Po pierwsze, nasz kod budowania PEP517 dorobił się możliwości wydobycia poprzednich paczek .whl. Po drugie, skoro usuwamy zagnieżdżone zależności z pipa i setuptools, to właściwie testujemy inny kod niż ten, który trafia do ensurepip — a myślę, że miałoby sens testowanie obydwu wariantów. Po trzecie, budowanie ze źródeł ułatwi nakładanie łatek, a w szczególności umożliwi użytkownikom łatwe dodawanie lokalnych łatek.
A skoro już się za to wziąłem, to przy okazji zaktualizowałem stan testów we wszystkich trzech paczkach (pip, setuptools i wheel — tego ostatniego potrzebujemy ze względu na testy). No i oczywiście, że trafiłem na padające testy w wersjach z zagnieżdżonymi zależnościami, i przypadkiem odkryłem błąd w #PyPy.
https://github.com/gentoo/gentoo/pull/42882 (tak, nadal tam jesteśmy)
https://github.com/pypy/pypy/issues/5306
Here's the customary #introduction: i'm into #C and tolerate C++ on a daily basis at work, i've also used others like java, kotlin, python, PHP, etc and am curious about #COBOL, #AdaLanguage and #erlang.
My dislike of jenkins is only surpassed by my hate of githubactions and everything MS-related. AI is not I, only A. I'm interested in #selfhosted stuff but atm that's a VPS with some sites, which doesn't really count. For now #syncthing is quite useful and #wireguard is on the horizon once i reformat/reinstall my current #gentoo (i'll keep the root #ZFS aproach and am on the fence regarding #XFCE or #KDE), would be interesting to have a barebones #KVM/#QEMU running all the stuff and i digress.
kthxbai\0
Jednym z celów, jakie sobie postawiłem rozwijając biblioteki eclass Pythona w #Gentoo, było unikanie niepotrzebnych komplikacji. Niestety, materia często ich wymaga. Niemniej, wiele funkcji, które ostatnio dodałem, była już ręcznie realizowana przez ebuildy od dawna.
Wyłączanie automatycznego ładowania wtyczek pytesta stosowaliśmy już od lat — pierwotnie dla pojedynczych paczek, które sprawiały problemy; następnie dla tych, w których testy stawały się powolne, a w ostatnim czasie praktycznie ilekroć cokolwiek robiłem przy funkcji `python_test()`. Robienie tego ręcznie było wyjątkowo toporne — a `EPYTEST_PLUGINS` wprowadziłem, jak tylko wymyśliłem dobry sposób na uogólnienie koncepcji.
Podobnie, zmienną `EPYTEST_XDIST` wprowadziłem po tym, jak wielokrotnie "na piechotę" powtarzałem pełne wywołanie `epytest -p xdist -n "$(makeopts_jobs)" --dist=worksteal` — a przy okazji dodałem brakującą możliwość nadpisania liczby procesów przez `EPYTEST_JOBS`.
Może `EPYTEST_TIMEOUT` nie było aż tak częste — natomiast miało głównie na celu wspomożenie procesów typu CI, w których zawieszone testy mogły powodować znaczne problemy.
Podobnie było z możliwością stosowania "wersji biblioteki standardowej" (np. `3.9`) w `python_gen_cond_dep` — wcześniej długo pisaliśmy `python3_9 pypy3`. Przy okazji, wówczas jeszcze `pypy3` mogło oznaczać różne wersje, więc przy okazji rozwiązaliśmy drugi problem.
Apparently the 2038 problem was fixed in #MariaDB 2 months ago, and considering the last time I checked up on this there were literally no plans to fix it ever, and some of the projects I've built do have date values beyond 2038 ('lifetime' accounts that expire in 2100 etc ), I'm genuinely a bit relieved about this one!
Absolutely no idea what the status of this is in anything other than MariaDB mind. That's going to be a fun year as a #Gentoo #Linux guy isn't it?
The time has come for me to propose that #Gentoo leaves #GitHub.
#Microsoft has been purveying #enshittification of this platform for years now. Pushing #Copilot everywhere was the last straw.
Nadejszła wiekopomna chwila. Zaproponowałem, by #Gentoo opuściło GitHuba.
Niestety, obsranie tej platformy postępuje już od lat. A wciskanie na siłę Copilota przetentegowało miarkę.
Modern programmers: "oh, let's hijack all #Python package managers in your bashrc without asking for consent, what could possibly go wrong."
And the best joke is, I didn't even really install the package — I was just making a random bugfix and running its test suite in a virtual environment.
Soo.. user error, #gentoo level. I had an old and forgotten python3.13 install in /usr/local/bin/ and it showed funny errors when I tried to migrate the system default to that same version. It took me more time than I'd want to admin to figure this out.