Search
1000 results for “mgorny”
-
-
-
-
-
-
@mgorny You're welcome?
We don't usually do RCs for patch releases, the last one was five years ago. The 3.14.5 RC was specifically for the GC change.
Unfortunately timelines were a bit short because I wanted to get this out, but it took a bit of time to prepare and test the patches and I didn't want to rush that, nor release during PyCon US.
https://discuss.python.org/t/reverting-the-incremental-gc-in-python-3-14-and-3-15/107014
#Python #CPython -
PSA: The annual #Gentoo #Python switch planned for 2026-06-01. CPython 3.14 becomes the default, 3.11 and #PyPy 3.11 go out. The latter fills me with sadness but keeping it is unrealistic now that projects are aggressively pushing for 3.12+.
Of course, we'll continue shipping the interpreters, so you can use venvs if you like. However, that's going to become harder to use since many projects either don't ship PyPy wheels or don't work on PyPy at all without patching.
We will revisit PyPy support if a version compatible with Python 3.12 appears in reasonable time.
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u -
I'm sorry to say that I actually wrote it:
"The pinnacle of enshittification, or Large Language Models"
"""
Honestly, I hate that I read about LLMs all the time. I hate all the marketing bullshit, but also all the critical pieces. Not because the criticism is wrong. I hate them precisely because they’re right. And I hate the feeling that I have to write yet another piece on that same topic, to collect some of the thoughts I have had over the recent months.Machine learning isn’t anything new. Neither is calling it “artificial intelligence”. Not only pop science writers and journalists, but even more technical folk have been using the term, and I never complained. I didn’t complain about games having “AI” either. It was always clear that this is a special use of “intelligence”, one far from what animals truly possess. This changed recently.
When LLMs enabled chatbots to use human language, the misuse of the term exploded. Obviously, the marketing people loved calling it “artificial intelligence”. The media, the users and the whole IT industry followed. Even people who knew better stopped bothering. On top of that, anthropomorphisms became commonplace. LLMs could be said to be “thinking”, “lying”, “hallucinating”, to “approve” or “disapprove”, “like” or “dislike”…
Perhaps it wouldn’t be so bad if not for the fact that LLMs are so good at imitating human intelligence. The problem is not really how people call them. The problem is that there is a number of people who start actually believing that their chatbots are conscious. And I can see why that would be happening…
"""And perhaps the most important piece:
"""
You may have noticed that I didn’t talk of quality per se. I don’t think there’s a point in doing that. I believe that LLMs sometimes spit quality slop, and sometimes they don’t. People who claim that they are “getting better and better” are probably right. Perhaps they will continue getting better, or perhaps they’ll suddenly start collapsing after eating too much of their own shit. That’s beside the point.The point is, however you look at it, LLMs are unethical. They may be useful, but they are poison — just like asbestos. They are trained in an unethical way, they are sold with immoral goals, and they are used to do a lot of evil. Yes, maybe they can make your life a little easier, a little more comfortable (just like cheap goods manufactured through slave labor). But is it something worth losing our humanity for?
You can just say “no”. Getting left behind can actually be a good thing.
""" -
-
Moi drodzy, z przykrością przychodzi mi oznajmić, że czas najwyższy opuścić #PolSocial. Moje nowe konto to https://mastodon.com.pl/@mgorny; aczkolwiek prawdopodobnie nie musicie nic robić; jak skończę przygotowania, to przeniosę profil.
Myślę, że byłem dostatecznie wyrozumiały i cierpliwy. Wiem, jak to jest prowadzić projekt non-profit. Podejrzewam, że z serwerem Mastodona jest trudniej niż z tym, co spotyka mnie w Gentoo. Niemniej, wiem ile czasu takie projekty potrafią pożerać. Wiem, jak to jest, kiedy wszystko sypie się akurat wtedy, kiedy tego czasu nie masz. Wiem, jak to jest, kiedy musisz cały czas walczyć z bogatymi dupkami, którzy celowo bądź przypadkiem starają się zniszczyć wszystko, co im się nie podoba. I koniec końców wiem, jak to jest, kiedy użytkownicy mają pretensje.
Niemniej, sytuacja nie wygląda zbyt dobrze. Komunikacja od dawna była zdawkowa, o ile w ogóle była. Z pol.socialu zaczęło się robić siedlisko kacapskich botów, a z braku komunikacji nawet nie wiem, jak realnie sytuacja wygląda — ani czy inne serwery nie zaczęły nas defederować. Z rzeczy mniej oczywistych, bo "flagowe usługi" wciąż działają, ftdl.pl leży już ponad tydzień. W praktyce oznacza to, że maile do wszystkich osób i organizacji, które korzystały z ich usług pocztowych, idą w eter. Ja co prawda już przy poprzedniej dużej awarii zorganizowałem zapasowy serwer (teraz już podstawowy), ale mimo to straciłem dostęp do ważnych maili, które dostałem tuż przed awarią, i zastanawiam się, czy je jeszcze odzyskam.
Prawda jest taka, że mógłbym jeszcze tu siedzieć, i nerwowo eksportować dane co kilka dni. Ale obawiam się, że pewnego dnia serwer zniknie bez śladu, i stracę dane od ostatniego eksportu.
-
-
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny The #OpenPGP situation is really sad especially because there is no alternative in sight.
This was also the topic of the round table discussion in the #GentooWorkshop 2025-06-14. Dear community, what do you think? Would you like another meeting to discuss #LibrePGP, #Sequioa-pgp and #GnuPG? Just let us know.
https://gentoo-ev.org/news/online-workshops-2025/ -
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
-
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
-
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
-
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
-
@mgorny Thanks for planning to bring up my bug (https://bugs.gentoo.org/963069) for discussion in the council. I personally use OpenPGP with all bells and whistles, but agree that what happens lately (#LibrePGP vs #RFC9580) is a s**tshow, and #OpenPGP was never easy to use. When it comes down to it, we should think about what the main use of OpenPGP at Gentoo is. And, that's signing commits if I am not mistaken. If #RFC9580 and #LibrePGP folks can't reach an agreement, I hope that #Git gets some logic implemented that allows it to automatically delegate the task of v5 (LibrePGP) or v6 (RFC9580) signature verification to the correct OpenPGP tool. In that case, users are free to choose the tool of their choice for Git commit signing.
-
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ś.
-
Jakiś czas temu zaimplementowałem w #Gentoo wsparcie #SigStore, by móc weryfikować nowe wydania CPythona. Dziś dowiedziałem się, że #PyPI również obsługuje takie "poświadczenia". Tylko jak je weryfikować?
https://blog.sigstore.dev/pypi-attestations-ga/
Ten post sugeruje, że na blogu PyPI znajdę "detale istotne dla użytkowników". No więc zajrzyjmy tam.
https://blog.pypi.org/posts/2024-11-14-pypi-now-supports-digital-attestations/
Tylko informacje o publikowaniu i przeglądaniu ich (a sposób wymieniony tam nie jest właściwą odpowiedzią na https://pol.social/@mgorny/114053976252968950), a nie weryfikacji. Szukamy dalej.
https://docs.pypi.org/attestations/
Tylko linki do kilku technicznych specyfikacji, nic przydatnego.
https://docs.pypi.org/attestations/consuming-attestations/
O, tu w końcu jest jakiś przykład. Sprawdźmy podlinkowany projekt.
https://pypi.org/project/pypi-attestations/
> [!WAŻNE] Ta biblioteka stanowi szczegół implementacji wewnątrz referencyjnej implementacji PEP 740. Większość użytkowników nie musi korzystać z niej bezpośrednio; więcej szczegółów w dokumentacji PyPI. [tłum. własne]
Tyle że ten link prowadzi do strony ze specyfikacjami! Jak jeszcze trochę pokopiemy, to możemy znaleźć API, które dostarcza nasze "poświadczenie":
https://docs.pypi.org/api/integrity/
No fajno, tylko co z nim zrobić? Przeskoczmy pół godziny wprzód, które zmarnowałem, próbując go użyć. Pokrótce rzecz biorąc, jedyne co pypi-attestations może zrobić jest pobranie interesującego nas pliku i danych "poświadczenia" *wprost z serwera*, i zweryfikowanie go. Więc trzeba używać dodatkowego narzędzia, które dodatkowo zawsze korzysta z Internetu.
A przynajmniej tak sądzę, bo nie brak wszędzie słów "eksperymentalne", a dokumentacja chyba już gorsza być nie może. No cóż, zgłosiłem prośbę o weryfikację w trybie offline, zobaczymy:
-
New on blog: "Poetry(-core), or the ultimate footgun"
"""
I've been complaining about the Poetry project a lot, in particular about its use (or more precisely, the use of poetry-core) as a build system. In fact, it pretty much became a synonym of a footgun for me — and whenever I'm about to package some project using poetry-core, or switching to it, I've learned to expect some predictable mistake. I suppose the time has come to note all these pitfalls in a single blog post.
"""https://blogs.gentoo.org/mgorny/2024/12/20/poetry-core-or-the-ultimate-footgun/
-
@mgorny Yes, as mentioned, that has to do with canvas thing.
But, funny thing, even if you get that fingerprinting thing turned off and allow writing to canvas, it's still unusable, because, depending on your monitor, it'll be either waaay too big or too small text.
With the line numbers not matching at all.
And text selection being unusable, too.Used to be work-aroundable with the "Accessible step output" toggle on top, but that seems to be gone as of this week :S
-
@mgorny
To może mnie zrozumiesz?W marcu 2022 wreszcie zaczęłam bardziej skutecznie, niż dotąd, radzić sobie z nawrotami hipomanii, łącząc przyjemne z pożytecznym, poprzez podróżowanie, gł. pociągami. Wtedy robiłam to, w noce i dnie podczas których przebywałam w GZM-ie. Kupowałam wtedy ówczesny wspólny bilet Kolesi Śląskich i ZTM-u „24h+Kolej” i jeździłam do woli pociągami na terenie pokrywającym się z obsługiwanym przez ZTM.
27.10.2024 próbując uciec przed ścigającym mnie świeżym nawrotem hipomanii pojechałam grubo przed świtem (4:32 z Katowic) do Bielska-Białej, by wreszcie chociaż zobaczyć socmodernistyczne Osiedle Grunwaldzkie, o którym tyle czytałam w Wikipedii: https://pl.wikipedia.org/wiki/Osiedle_Grunwaldzkie_(Bielsko-Bia%C5%82a)
Zdążyłam tylko zrobić mały rekonesans, gdyż chciałam zdążyć skorzystać w terminie ważności współczesnego biletu Kolesi Śląskich „Sieć24” z „bielsko-bialskiej kolei miejskej”, czyli przejechać jeden przystanek z Białej do centrum Bielska.Wreszcie wczoraj zachwycona wycieczką z przewodnikiem po obszarach Gliwic zlokalizowanych na zachód, lekko północny zachód od ścisłego śródmieścia, zostałam tam jeszcze przez dwie godziny, by samotnie nacieszyć się otaczającą mnie przestrzenią miejską, w której widać efekty uczciwie wykonanej pracy architektonicznej i urbanistycznej.
Zaczęłam fotografować zachowany „muzealnie” odcinek pierwotnego wąskotorowego torowiska tramwajowego na rogu ulic Zygmunta Starego i Górnych Wałów, w czym przeszkadzały mi licznie przejeżdżające po nim torowisko.
Kikut oderwanego na styku ulic (patrząc zgodnie z kierunkiem ruchu wskazówek zegara) Wieczorka, Sobieskiego, Daszyńskiego, Kozielskiej i Jasnogórskiej normalnotorowego torowiska tramwajowego prowadzącego w lewo i w górę, czyli Daszyńskeigo był jeszcze bardziej rozjeżdżany przez samochody.
Zatem wymyśliłam, że analogicznie do Ciebie, w niektóre niedzielne przedświty
będę wstawać przed 3:00, by zdążyć jeszcze przed świtem dotrzeć w te dwa miejsca oraz na fragment wąskotorowej mijanki na Górnych Wałów na odcinku od Księcia Ziemowita do ruchliwej Ofiar JPII i i spokojnie fotografować bez samochodowych „przeszkadzajek”.Teraz mnie rozumiesz?
#BielskoBiała #Osiedle #Grunwaldzkie
#Broniewskego #Tuwima
#Gliwice #Wieczorka #Daszyńskiego #GórnychWałów #Górnych #Wałów
#tramwaj #pociąg #przedświt #fotografia -
@mgorny Three of those are by me, sorry you think it look like shit. (I have since reverted some to be more concise: https://github.com/termcolor/termcolor/commit/09ca9cc88b7e31623b8c561aa1fe87383ddd8f72)
I also prefer the original, but #TOML isn't the prettiest and it's much more valuable and maintainable for me to have things consistent and autoformatted than to re-arrange by hand.
Have you tried making suggestions with the formatter? Do you know another formatter that I could use that is better? Is there a #PEP517 / #PyProjectToml style guide?
-
Zacząłem prace nad dodaniem wsparcie wersji #FreeThreading CPythona 3.13 do #Gentoo (tzn. technicznie już mieliśmy, ale jest zepsute). Rozszerzenia w tej wersji są niezgodne na poziomie ABI ze standardowymi, więc musimy ją zrobić odrębnie — włącznie z nową flagą PYTHON_TARGETS. W sumie ma to sens, bo i tak wypadałoby to osobno testować.
Koniec końców, teraz już rozważam spore zmiany w tym, jak #CPython jest paczkowany w Gentoo. Pokrótce, podążając za starymi zwyczajami, wersja freethreading by wylądowała jako:
dev-lang/python-3.13.0-r100:3.13t
Tyle że Portage upiera się, by zawsze instalować (dodatkowo) najnowszą wersją; nawet wówczas, kiedy wszystkie zainstalowane paczki akceptują wyłącznie wcześniejsze wersje (no cóż, czasem to ma sens). Tak więc wszyscy użytkownicy systemów ~arch dostaliby tę wersję zainstalowaną z automatu! Tak więc pomyślałem, żeby zamiast tego dać:
dev-lang/python-freethreading-3.13.0:3.13t
Ale jak się zastanowić, to problem niepożądanych aktualizacji nie jest niczym nowym. Kiedy dodawaliśmy pierwsze wersje 3.13, były instalowane użytkownikom ~arch z automatu, mimo że ich PYTHON_TARGETS nie wskazywał tych wersji. To samo użytkownicy stabilnej gałęzi, kiedy 3.13 w niej wyląduje. W gruncie rzeczy, mogło to doprowadzić do problemów, jeżeli ktoś używał własnych skryptów, które korzystały z systemowych paczek — zależności były zainstalowane dla 3.12, a tu nagle `python` zaczyna używać 3.13!
Poniekąd ten problem rozwiązaliśmy, dodając dev-lang/python-exec-conf, które instaluje domyślną konfigurację dla python-exec w oparciu o wybrane PYTHON_TARGETS. Ale dlaczego nie wziąć się za prawdziwy problem i pozbyć się łączenia wszystkich wersji w jedną paczkę ze slotami? Tak więc zaproponowałem, że kolejna wersja trafi w Gentoo jako:
dev-lang/python3_14
A skoro już zmieniamy, to może od razu pójść w "python3_13t" zamiast "python-freethreading"? Może nazwa mniej oczywista, ale przynajmniej wprost pokrywa się z PYTHON_TARGETS.
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://github.com/gentoo/gentoo/pull/38918 -
I've started working on adding the #FreeThreading version of #CPython 3.13 to #Gentoo (properly, our previous approach no longer works). Since it's not ABI-compatible with the regular 3.13, we need to make it truly separate — including a new PYTHON_TARGETS flag. Which kinda makes sense, because we'd want to test it explicitly anyway.
One thing lead to another, and now I'm considering major changes to how to we package CPython itself in Gentoo. Long story short, per the current custom we'd be adding the freethreading variant as something like:
dev-lang/python-3.13.0-r100:3.13t
However, because of Portage always insisting on additionally having the newest version installed anyway when only older slots are requested (well, in some scenarios this makes sense, I guess), this would mean all ~arch users would inadvertently get it installed! So I wanted to go for something like this instead:
dev-lang/python-freethreading-3.13.0:3.13t
But in fact, the inadvertent upgrades problem isn't really new. When Python 3.13 was added, ~arch people got it installed, even though their PYTHON_TARGETS didn't want it. Same goes for stable users when it gets stabilized. In fact, this used to lead to breakage when someone used custom scripts that relied on system #Python packages. Just imagine you've got all your dependencies installed for 3.12, and Portage suddenly installs 3.13 and `python` starts calling it by default!
Historically, we've kinda solved that problem by adding dev-lang/python-exec-conf that'd install a default configuration for python-exec that matched PYTHON_TARGETS. However, why not address the deeper issue and stop slotting instead. So I've proposed that going forward, we make them:
dev-lang/python3_14
And since I'm proposing a major change like this, why not go for "python3_13t" instead of "python-freethreading"? Perhaps it's less obvious, but has the advantage of matching PYTHON_TARGETS.
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://public-inbox.gentoo.org/gentoo-dev/[email protected]/T/#u
https://github.com/gentoo/gentoo/pull/38918 -
Another post on the blog, though this time it's more of a quick note: "Testing the safe time64 transition path"
"""
Recently I've been elaborating on the perils of transition to 64-bit #time_t, following the debate within #Gentoo. Within these deliberations, I have also envisioned potential solutions to ensure that production systems could be migrated safely.My initial ideas involved treating #time64 as a completely new ABI, with a new libdir and forced incompatibility between binaries. This ambitious plan faced two disadvantages. Firstly, it required major modification to various toolchains, and secondly, it raised compatibility concerns between Gentoo (and other distributions that followed this plan) and distributions that switched before or were going to switch without making similar changes. Effectively, it would not only require a lot of effort from us, but also a lot of convincing other people, many of whom probably don't want to spend any more time on doing extra work for 32-bit architectures. This made me consider alternative ideas.
One of them was to limit the changes to the transition period — use a libt32 temporary library directory to prevent existing programs from breaking while rebuilds were performed, and then simply remove them, and be left with plain lib like other distributions that switched already. In this post, I'd like to elaborate how I went about testing the feasibility of this solution. Please note that this is not a migration guide — it includes steps that are meant to detect problems with the approach, and are not suitable for production systems.
"""https://blogs.gentoo.org/mgorny/2024/10/04/testing-the-safe-time64-transition-path/