eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Server stats:

209
active users

#gentoo

0 posts0 participants0 posts today

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

Replied in thread

@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)

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

github.com/gentoo/gentoo/pull/ (tak, nadal tam jesteśmy)
github.com/pypy/pypy/issues/53

GitHubdev-python/ensurepip-*: Switch to building from source by mgorny · Pull Request #42882 · gentoo/gentooBy mgorny

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? 👀

Also I am curious about #FreeBSD with #ports and #poudriere, how do you guys manage #Firefox and possibly #LibreOffiice? It took me~5h to compile #LLVM default flavor on my laptop, I would just assume giants I listed above will take more than 10 hours? I still remember old days when I was using #Gentoo #Linux and whenever there was updates for them I had to keep my PC on overnight...But nowadays #Firefox seems to update more frequently, I dare not to compile few times a month.

#BSD #Unix #UseBSD #RUNBSD #FOSS

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.

github.com/pyupio/safety/issue

GitHubRunning safety's test suite hijacks user's bashrc and leads to a broken system · Issue #766 · pyupio/safetyBy mgorny

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.