SteveTux, German
kubikpixel,
mgorny, Polish Technicznie rzecz biorąc, sporą część pracy związaniem z portowaniem paczek #Gentoo do Pythona 3.13 można zautomatyzować. W gruncie rzeczy, mamy już większość potrzebnych elementów — narzędzia, by znaleźć potencjalne paczki, zaktualizować PYTHON_COMPAT, uruchomić testy. Dlaczego więc robię to na wpół ręcznie?
Po pierwsze, daje mi to okazję, by zajrzeć w ebuildy. Mogę poszukać starych problemów, poprawić kod, czasem odkryć paczki, które powinniśmy byli usunąć dawno temu. Po drugie, patrząc na logi czasem mogę zauważyć, że testy gdzieś nie działają poprawnie (a w szczególności przypadek, że paczka nie zwraca błędu, kiedy testy nie przechodzą).
No i koniec końców, daje mi jakieś poczucie wartości, kiedy przez tę przeklętą gorączkę nie mogę się na niczym skupić.
timorl, No i koniec końców, daje mi jakieś poczucie wartości, kiedy przez tę przeklętą gorączkę nie mogę się na niczym skupić.
Ja też jakl jestem chore to potrafię wykonywać ino podstawowe funkcje życiowe takie jak programowanie. :blobfoxcomfycomputer:
librecast, We love encouraging others to try out and package our tools.
We'd love for librecast to be in #gentoo so we've submitted a request for the e-builds for liblibrecast, lcrq and lcsync to be packaged for gentoo.
https://bugs.gentoo.org/931672
It's now in the list of packages that would like a maintainer.
etchedpixels,
mgorny, Polish Wiemy już, że wielu autorów oprogramowania jest wrogo nastawionych do testowania przez dystrybucje.
Co jednak powiecie na to, by zaszyfrować testy tak, by tylko CI było w stanie je uruchomić?
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/pefile/pefile-2023.2.7.ebuild?id=ec0d293b15ba0514e9349fdbf9fed7131a72c226#n24
https://github.com/erocarrera/pefile/blob/master/tests/test_data.tar.bz2.enc
timorl, @mgorny Wut. Ależ to jest dziwne, ich repo z testami brzmi jakby twierdziło że to ze względu na to że nie wiedzą skąd się ich dane do testów oryginalnie wzięły (chyba?) i to wygląda jakby chcieli w ten sposób obejść ich licencjonowanie? Bardzo konfundujące. :blobfoxconfused:
mgorny, @timorl, owszem, dziwne. Ja to czytam tak, że oryginalnie odziedziczyli te zaszyfrowane testy, a teraz starają się zrobić nowe, publiczne, ale też mają wątpliwą licencję.
timorl, Soo… say I have a couple ebuilds that are probably not great quality (approximately first ones I wrote), but work. How should I go about making these useful for other people? Perhaps even including them in the main gentoo repo? This is mostly about Request Tracker, which already is in the repo, albeit in an old version (and with a wrong makefile patch), plus some of it’s dependencies (some of which I updated, some that never were in the main repo).
ScottE, @timorl
I think the Guru repo might be a better place.
timorl, @ScottE Unfortunetely, rule 11:
The primary purpose of GURU is to maintain packages not present in the Gentoo repository. Forking (overriding) actively maintained Gentoo packages into GURU is prohibited. If the package is moved to Gentoo, it should be removed from GURU.
And
www-apps/rt
is already in the maingentoo
repo, so I’m not allowed to put that there. :blobfoxcry2:
Ryan,
gabrielesvelto, @Ryan for running a dekstop system OpenRC requires a bit more configuration than a systemd install, but it's usable and shouldn't pose too many issues
oddly, #Gentoo question; what is the best way to share a small improvement on an ebuild in the Guru repo? Asking to become a contributor sounds like overkill, with getting PGP working and all.
Would it be best to just create my own repo and add it to the list so it can be discovered?
(The improvement is making iio-sensor-proxy work on openRC by implementing a fix I found on the forums. Not that impressive, though now my Chromebook runs perfectly :))
oddly, @ferki thanks! I'm going to tinker with this over the weekend.
ferki, @oddly Sounds great!
Thinking more about it, bugzilla may work a lot better for sending patches because:
- the gentoo/guru repo on GitHub is only a mirror of the real repo, so merging pull requests there won't work directly
- even if that would work, GURU maintainers in general don't have permissions to merge stuff inside the gentoo organization on GitHub
At the same time, bugzilla tickets are assigned directly to the maintainer of the ebuild in question.
ferki, I'm going to host an online workshop for the Gentoo e.V. on 2024-06-15 about how to "Host Gentoo dependency tarballs as GitHub releases".
I'll show how to use GitHub for dependency tarballs as an external #Gentoo #contributor, such as a proxied maintainer, a GURU committer, or an overlay #maintainer.
I use this approach to package #opensource #Golang software, and it can be applied to other similar situations, or even automated through local scripts or GitHub Actions.
ferki, If you are impatient to learn about the approach, I blogged about it earlier at https://blog.ferki.it/2023/04/24/host-gentoo-dependency-tarballs-as-github-releases/
linuxuserspace, We're FINALLY doin it again. Livestreamin' that is.
Come join us and laugh at how badly the #Gentoo journey will go. And while we're waiting for compiles, we'll be on the other side of the spectrum with composables? immutables? image based? whaaaa?
#Linux #Livestream #Immutable
https://www.twitch.tv/linuxuserspace
TeamLinux01, @linuxuserspace @jorge I am very happy to have been able to make it and talk with everyone. Thank you!
peppe, The Gentoo wiki is an excellent source of information, as is the handbook. It's almost not for these times anymore, because you have to read carefully and not just skim the headlines. The most valuable information is usually 2 paragraphs down from that headline. But it's there, trust me. How else would I've learned about the gentoo-pipewire-launcher script ? 😎
withoutclass, @peppe I burn myself regularly due to predisposition to not read everything completely 😁
governa,
nikatjef, @governa
Will be interesting to watch how this plays out. Not many people are doing it yet, but I can see a lot of developers, in the future, using LLMs / AI to learn to program. Never actually using the code provided bu the LLM, but learning from it and writing their own based on their understanding of it.Also understand that the bulk of Gentoo's code base is direct upstream project repositories... If the upstream allows direct LLM code, will Gentoo drop that package?
governa, @nikatjef all great points
joostruis,
soulsource, WTF, #Gentoo?
A bit late to change this now, after the new profiles were declared stable, don't you think?
mgorny, Polish Jeszcze jeden post w temacie xz/sshd, a także wcześniejszej sprzedaży "Simple Mobile Tools".
Dawno temu, nauczono mnie ważnej zasady bezpieczeństwa w IT: kiedy grożą ci przemocą, ulegnij. Życie i zdrowie twoje i twojej rodziny jest ważniejsze niż jakikolwiek projekt wolnego oprogramowania, nad którym pracujesz. Wielu ludzi będzie cię obwiniać, ale ci naprawdę ważni zrozumieją.
Ale co, jeśli przed twoim nosem wisi marchewka, a nie kij? Co, jeśli ktoś oferuje ci pieniądze w zamian za "zdradę"? Powinieneś się opierać czy ulec?
Lecz czy nie powinieneś spodziewać się kija na drugim końcu? Czy nie uderzy cię wówczas, kiedy odrzucisz marchewkę? Wszak czy pieniądze nie są po prostu "cywilizowanym" sposobem umywania rąk od implikowanej groźby przemocy?
A co, jeżeli naprawdę potrzebujesz tych pieniędzy? Jeżeli z trudem wiążesz koniec z końcem, a odrzucenie marchewki jest kijem samo w sobie?
Cóż, nie sugeruję, że w #Gentoo spotka mnie taka sytuacja (sytuacja łapówki; brak dochodu znam aż za dobrze), ale naprawdę nie wiedziałbym jak postąpić. I jestem w stanie zrozumieć każdego, kto przyjąłby te pieniądze.
A morał z tego taki: dopóki ludzie będą wykorzystywać twórców wolnego oprogramowania jako darmową siłę roboczą, dopóty nie będą mieli prawa się dziwić, że istotne dla nich projekty są sprzedawane albo niszczone od środka.
mgorny, Polish @piotrsikora, gdybym miał zdrowie do biurokracji, to pewnie łatwiej byłoby mi znaleźć sponsoring w jakimś korpo.
piotrsikora, Polish @mgorny my aktualnie będziemy sporo robili w tej kwestii i właśnie zaczynamy. W sensie nie w sponsoringu od korpo tylko pozyskiwaniu grantów (Polskich, UE, ale też światowych). Więc jakbyś miał ochotę brać w czymś udział to daj znać.
spla, Catalan Gràcies al USB HUB de la imatge, he tingut una idea que ja funciona perfectament: connectar disc durs externs al HUB, cadascun amb un sistema operatiu diferent. Si vull engegar #Gentoo, acciono l'interruptor del disc dur amb Gentoo, si vull engegar #Ubuntu activo l'interruptor del HUB que alimenta al disc dur extern amb Ubuntu.
D'aquesta manera es poden tenir fins a 7 sistemes operatius diferents per a la #Raspberry.
Lioh, German That's great news: Gentoo is now part of the SPI (Software in the Public Interest) like many others, e.g. The Debian Project https://www.phoronix.com/news/Gentoo-Linux-SPI-Project
withoutclass, German @Lioh wow this rules. Now I can get employer matching to go with my monthly donation.
mgorny, Polish Po otrzymaniu kolejnego zgłoszenia błędu, że pythonowa paczka (tym razem #VirtualEnv) nie buduje się, bo użytkownik nie ma dostatecznie nowej wersji paczki #TroveClassifiers, zgłosiłem wniosek o to, by #Hatchling uczyniło weryfikację "trove classifiers" opcjonalną, albo przynajmniej nie traktowało jej niepowodzenia jako błędu.
W tej chwili z tym się po prostu nie da ujechać. Technicznie rzecz biorąc, każda paczka musiałaby deklarować minimalną wersję paczki
trove-classifiers
, która dostarcza niezbędne im identyfikatory, a my musielibyśmy kopiować te specyfikacje do ebuildów w #Gentoo. Jednakże to mało prawdopodobne, więc w praktyce zmuszeni jesteśmy sprawdzać wszystkie identyfikatory, używane przez paczki, i dopasowywać je do wersjitrove-classifiers
. Albo — bardziej realistycznie — zawsze wymagać najnowszej dostępnej wersji, i mieć nadzieję, że nie zapomnimy regularnie aktualizować tej zależności.https://github.com/pypa/hatch/issues/1368
https://bugs.gentoo.org/928447
m3tti, German Found my new old love #gentoo man i somehow missed it. Thank you gentoo guys to still keep up the awesome work. and with the binary option it is now even more cooler to use. Cause you get started really fast and can go from there.
mgorny, Polish
mgorny, Polish Ostatnio zastosowałem prostą sztuczkę w standardowej inwokacji PyTesta w #Gentoo, by rzucało błąd, kiedy wykryje nieużywane funkcje async. Miało to na celu zwiększenie szansy zauważenia, jeśli w którejś paczce przypadkiem pominięto zależność od dev-python/pytest-asyncio (albo równoważnej wtyczki), albo przy wyłączonym automatycznym ładowaniu wtyczek, pominięto ładowanie takiej wtyczki.
Dziś otrzymałem pierwsze zgłoszenie, dotyczące paczki dev-python/ipython. Przeszukałem źródła, i potwierdziłem zależność — tyle, że z jakiegoś powodu przypiętą do wersji < 0.22. No cóż, nie mamy już takiej, ale warto sprawdzić, czy mimo to nie zadziała. Tak więc dodałem zależność, dodałem
-p asyncio
… a #PyTest dalej jej nie widzi. Podrapałem się po głowie, spróbowałemPYTEST_PLUGINS
— dalej nie działa. Co do…?Tak więc sklonowałem repozytorium git, spróbowałem ze starszą wersją wtyczki — testy działają. Zaktualizowałem do 0.23.6, przestały działać. Sprawdziłem historię, i okazało się, że starą wersję wymuszono ze względu na błąd w wydaniu 0.22.0. Tyle że ten błąd już poprawiono, wydanie usunięto, a mój problem był zupełnie inny.
Przyjrzałem się sprawie bliżej. Z jakiegoś powodu, w kodzie #IPython testy nie są bezpośrednio oznaczone markerem
pytest.mark.asyncio
. Zamiast tego,conftest.py
automatycznie dodaje ten marker do wszystkich testów, będących współprogramami. Ze starszymi wersjami to działało, z nową przestało. Wygląda na to, że test zostaje poprawnie oznaczony, ale wówczas przestaje być rozpoznawany jako współprogram. Przygotowałem minimalny przykład i zgłosiłem problem.Istotne w tej historii jest to: (potencjalny) problem nie został zauważony przez dłuższą chwilę, bo autorzy IPythona przedwcześnie wymusili starą wersję ze względu na chwilowy błąd, a następnie nie usunęli tego ograniczenia.
https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/python-utils-r1.eclass?id=1f35acddca01e91d4477f3d0340c47329517f474
https://bugs.gentoo.org/928411
https://github.com/ipython/ipython/commit/e27ee203ad54df0431d817abad09ec1caafde4d6
https://github.com/pytest-dev/pytest-asyncio/issues/810
mgorny, Polish Jak sobie to wyobrażałem: włączę #DistCC na cienkim lapku, zasypie stacjonarnego Ryzena kompilacjami, utrzymując 12 wątków z boostem na 100% obciążeniu, i skończy kompilować webkit-gtk w chwilę.
Jak wyszło w praktyce: 4 rdzenie laptopa są w 100% obciążone preprocesorem i nie wyrabiają z dostarczaniem zadań Ryzenowi, a ten je wykonuje tak szybko, że ledwie jest obciążony.
No cóż, przynajmniej preprocesor nie zużywa tak dużo pamięci jak pełna kompilacja, więc budowanie cały czas postępuje, zamiast zaciąć się na swapowaniu.
piotrsikora, Polish @mgorny ja zawsze robiłem tak że slalem ostro nadmiarowo do stacjonarek/serwerow. Na lapku ustawiałem zero bo i tak sporo musi liczyć i sporo i tak musi zostać lokalnie wykonane. No i połączenie ethernet.
Jeszcze się robiło jakieś sztuczki żeby więcej słać niż normalnie.
hadsn, Japanese #Gentoo 使いはxz-utilsのバックドアに対処をお願いします
"Gentoo(Portage)の履歴
2/24 5.6.0が追加(Stabilizeされないまま後にdrop)
3/10 5.6.1が追加
3/24 5.6.1がStabilize
3/30(ついさきほど) 5.6.0以降がマスクされ、5.4.2が復帰というわけで、3/24~3/30の間にemerge -uしたGentooユーザーは危険に晒されています。"
https://twitter.com/shimariso/status/1773868518729200051
dervishe, Hey gentooers, the xz vulnerability is also in #gentoo update asap
Take a look:
https://packages.gentoo.org/packages/app-arch/xz-utils
Vulnerability describe here: https://www.openwall.com/lists/oss-security/2024/03/29/4