uwumeowmeownyaa has quit [Remote host closed the connection]
ppetrov^ has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
<ppetrov^>
hey guys, we have p5-* for perl modules, I did r4-* for R packages, so why not have say py3-* for python stuff, as a naming convention?
zorz has joined #crux-social
<farkuhar>
ppetrov^: wrong channel for that question. The majority of python3-* ports are maintained by people in #crux or #crux-devel.
<ppetrov^>
I am afraid to go there, farkuhar
<ppetrov^>
:P
<farkuhar>
zorz: Who exactly is complaining about mesa compile times nowadays? Commit 6cfb6de28e160beb464086e333e7f9984fc3c27e (2023-09-29) reminds me of a bug report by alexmat, requesting more independence between the opt and xorg repos (on a headless host, for example).
<zorz>
aaaaaaaaaaaa
<zorz>
tell him mesa -> llvm -> cromium hahahahahha
<zorz>
moment i am from a different machine tweaking bots... and the keyboard, if not 105 keyless huge problem for myself
<zorz>
ok
<farkuhar>
zorz is using the keyboard layout as an excuse for not unpacking the arrow notation (mesa -> llvm -> cromium). If I had to guess, I would say X -> Y means "people who get used to regularly rebuilding X are more easily persuaded to compile Y on a similar schedule".
<zorz>
i speak about the time
<zorz>
and my cpu is not that bad, ryzen7 5800
<farkuhar>
zorz: how many fans do you need to keep that CPU cool?
<zorz>
laptop has 2
<zorz>
1 cpu 1 gpu
<zorz>
but it runs no more than 90 when i compile
<zorz>
reds for this cpu is 110
<zorz>
my kernel as it is configure takes around 10 minuts to compile.
<zorz>
farkuhar: you know that kernel 6.7 introduced make hardening.config?
<farkuhar>
zorz: no, I wasn't aware of the new target.
<zorz>
man is amazing, for me is (on an new kernel) make defconfig / make hardening.config and make menuconfig add mouse graphics network cpu
<farkuhar>
you do get amazing hardware support in Linux. Plan9, on the other hand, I'm not sure would provide the same breadth of support for the consumer-grade hardware in common use. https://9p.io/wiki/plan9/Supported_PC_hardware/index.html
<zorz>
yes its hard for others to keep up with new hardware.
<farkuhar>
also amazing: that Plan9 wiki page received its last update more than 10 years ago.
<zorz>
heh
<zorz>
lately farkuhar, i use a lot in linux python3.13, bash, and gnu parallel
<ppetrov^>
gnu/parallel is cool, however the default "please cite me!" notification is annoying
<ppetrov^>
nagware i never like
<farkuhar>
zorz: you said yesterday that python3.13 and python3.12 are "totally diff". Looking at the ChangeLog, I don't see anything that would restore support for firefox `mach build` (a failure that emmett1 discovered in CRUX-3.8-rc).
<farkuhar>
So we actually don't have to introduce native git features in pkgmk, to handle the three common git frontends: GitHub, GitLab, Gitea. All of them have HTTP methods for checking out a tarball at a specific commit.
zorz has quit [Ping timeout: 265 seconds]
zorz has joined #crux-social
<farkuhar>
ppetrov^: Got any suggestions for renaming the gtk3 libraries glibmm and pangomm? The upstream devs are focusing on the gtk4 branches, whose versions are rapidly diverging from the names that beerman chose (glibmm-2.68 and pangomm-2.48).
<farkuhar>
Better parallelism would be achieved by having "Depends on: atkmm3 cairomm3 gtk3 pangomm3" in the gtkmm3 Pkgfile header (which entails three renamed ports), and also renaming glibmm as glibmm3.
<ppetrov^>
glibmm3 or gtk3-glibmm?
<ppetrov^>
for my legacy stuff, i use gnumeric-gtk2
<ppetrov^>
, so i put is as a tag
<farkuhar>
Appending a tag is how beerman did it, but he went with the soversion rather than the gtk version, and now we have the awkward situation that pangomm-2.48 is at version 2.52.
<farkuhar>
I wonder how many people actually care about the discrepancy, though. Only a user who installs pavucontrol would see these gtkmm4 dependencies pulled in.
<ppetrov^>
bleh
<ppetrov^>
append -legacy and that's it
<ukky>
farkuhar: If you are talking about 2.48 vs 2.52 discrepancy, then this is simply unacceptable, though I do not have it installed.
<ppetrov^>
just checked it on portdb, looks funny
<farkuhar>
ppetrov^: It would be the currently-untagged ports (glibmm and pangomm) that deserve the -legacy tag. Then beerman could rename pangomm-2.48 as pangomm. But this renaming might itself become obsolete if they ever move on to GTK5.
<farkuhar>
Another reason to agree with uwumeowmeownyaa: GTK was a mistake.
<ppetrov^>
*GTK3 was a mistake
<ppetrov^>
:P
<ppetrov^>
i just updated my main ports collection
<ppetrov^>
was a bit tedious
<farkuhar>
Some users might read negative connotations in the tag -legacy. I prefer a more neutral tag like -gtk3.
<ppetrov^>
then -gtk3
<ppetrov^>
or just do pangomm3
<ppetrov^>
however, pangomm3 would imply its major version is at 3.* which might not be the case
<farkuhar>
Anyway, the perfect time to roll out these changes in the port names is in the CRUX 3.7 -> 3.8 transition, because the iso comes with setup-helper to make the necessary changes in the pkgdb.
<ppetrov^>
or at least that's how i see it
ivandi has quit [Quit: WeeChat 4.5.1]
<farkuhar>
So for the duration of CRUX 3.8, the absence of a tag would imply it's the GTK4 version, and anything targeting GTK3 or lower would get the appropriate tag. How does that sound, as a naming policy?
ivandi has joined #crux-social
<ppetrov^>
ask in #crux-devel
<ppetrov^>
:P
<ppetrov^>
will python2 be removed from crux 3.8?
<farkuhar>
The TODO38 page says it's already been done.
<ppetrov^>
sorry, have not been checking actively lately
<farkuhar>
Actually, a lot of discussion is being mediated by the TODO38 page and Gitea issues or pull requests. Not so much activity on IRC.
<ppetrov^>
that's why you invited me to open a ticket at gitea
ivandi has quit [Quit: WeeChat 4.5.1]
ivandi has joined #crux-social
<farkuhar>
Now if I manage to get Inkscape to compile against gtkmm4, that would be one less port pulling in the gtkmm3, atkmm, glibmm, and pangomm dependencies. Repeating such a GTK3 -> GTK4 transition for rawtherapee and transmission-gtk would allow these "legacy" dependencies to be dropped completely.
<farkuhar>
And then people like ppetrov^ would keep maintaining the legacy ports in personal repos.
<ppetrov^>
*weirdos like ppetrov^...
<farkuhar>
I wonder what it would take for port maintainers to get into the habit of preemptive tagging. Instead of reacting to the mainstream adoption of a backward-incompatible version of GTK by renaming all the old (untagged) ports, it could become common practice to always tag the port on the very first upload (-gtk3 or -gtk4, for example).
<farkuhar>
Heh, preemptive tagging could be the path forward for Inkscape. Just push a new port inkscape-gtk4, mark the old port unmaintained, and then drop the old port after a few months (by which time the users will have adapted to the changes).
<ppetrov^>
well, see the qt6- stuff
<ppetrov^>
these guys simply name the tarball properly and that's it
<ukky>
I think this idea is great for the long term. There will be no need to rename ports when they become legacy/obsolete/previous.
<ppetrov^>
so, we do this only for the -gtk3 and gtk4 stuff?
<ppetrov^>
or clementine-qt5, too?
<ukky>
imho, this should be done for every toolkit/sdk that potentially may break API (GTK/QT) on major version bump
<farkuhar>
Even easier if the upstream devs would fork the project or change the name, whenever they target a new toolkit. Then the maintainers wouldn't have to introduce any tags at all. GTK2 -> SodiPodi, GTK3 -> Inkscape, GTK4 -> $Some_Other_Name
<ppetrov^>
sodipodi, heh
<ppetrov^>
you still remember i had a port for that