05:00 <cruxbot> [opt/3.7]: python3-cython: 3.0.12 -> 3.1.0

05:00 <cruxbot> [contrib/3.7]: gumbo-parser: 0.13.0 -> 0.13.1

05:00 <cruxbot> [contrib/3.7]: libdeflate: 1.23 -> 1.24

05:00 <cruxbot> [contrib/3.7]: qownnotes: 25.5.3 -> 25.5.4

05:06 <cruxbot> [contrib/3.8]: libdbusmenu-glib: fix FTBFS

05:06 <cruxbot> [contrib/3.8]: nmap: finally fix FTBFS

05:08 <cruxbot> [contrib/3.8]: Merge remote-tracking branch 'origin/3.7' into 3.8

05:08 <cruxbot> [contrib/3.8]: gumbo-parser: 0.13.0 -> 0.13.1

05:08 <cruxbot> [contrib/3.8]: libdeflate: 1.23 -> 1.24

05:08 <cruxbot> [contrib/3.8]: qownnotes: 25.5.3 -> 25.5.4

05:10 <cruxbot> [opt/3.8]: Merge remote-tracking branch 'origin/3.7' into 3.8

05:10 <cruxbot> [opt/3.8]: python3-cython: 3.0.12 -> 3.1.0

15:51 <dutch> Hi all. I just installed, from scratch and not an upgrade, 3.8. While installing xfce with prt-get, I received a slew of signature mismatches (12 at last count), mainly from the crux-xfce repo, but a few from contrib as well. What is the proper way to handle these? I have been using prt-get's -is flag, but this makes me uncomfortable, and the -us flag always fails.

15:56 <pitillo> hey dutch, for contrib ports you can create an issue at git.crux.nu and for xfce I'd send an email to the maintainer (if you have the right .pub file in /etc/ports/ for that repo and other xfce ports haven't that signature mismatch)

15:57 <farkuhar> dutch: Regarding the -us flag, that's meant for port maintainers. Without the secret key, you won't be able to run the signify(1) commands to re-sign the port.

16:00 <dutch> Cool, thanks for the sanity check. I was getting so many I thought I may have been doing it wrong.

16:27 <cruxbot> [contrib/3.7]: gegl: 0.4.58 -> 0.4.62

16:27 <cruxbot> [contrib/3.7]: mono: 6.14.0 -> 6.14.1

16:27 <cruxbot> [contrib/3.7]: python3-gevent: 25.4.2 -> 25.5.1

16:27 <cruxbot> [contrib/3.7]: python3-trove-classifiers: 2025.4.11.15 -> 2025.5.9.12

16:59 <cruxbot> [contrib/3.8]: libdbusmenu-gtk3: fix FTBFS

17:00 <cruxbot> [contrib/3.8]: libdbusmenu-gtk2: fix FTBFS

17:00 <cruxbot> [contrib/3.8]: Merge remote-tracking branch 'origin/3.7' into 3.8

17:00 <cruxbot> [contrib/3.8]: python3-calver: 2025.3.31 -> 2025.4.17

17:00 <cruxbot> [contrib/3.8]: python3-elementpath: 5.0.0 -> 5.0.1

17:00 <cruxbot> [contrib/3.8]: python3-xmlschema: 3.4.5 -> 4.0.1

17:00 <cruxbot> [contrib/3.8]: python3-yarl: 1.18.3 -> 1.20.0

17:00 <cruxbot> [contrib/3.8]: gegl: 0.4.58 -> 0.4.62

17:00 <cruxbot> [contrib/3.8]: mono: 6.14.0 -> 6.14.1

17:00 <cruxbot> [contrib/3.8]: python3-gevent: 25.4.2 -> 25.5.1

17:00 <cruxbot> [contrib/3.8]: python3-trove-classifiers: 2025.4.11.15 -> 2025.5.9.12

20:32 <farkuhar> dutch needed to activate both the crux-xfce repo *and* the contrib repo to install XFCE? That reminds me of the old policy that sepen cited in this thread: https://lists.crux.nu/archives/list/crux-devel@lists.crux.nu/message/U3YNYCOX46KRYTSP3LLV6WSD2Y65KAVP/

20:39 <farkuhar> Mikhail's reply in that thread strikes the right note of incredulity: "... it is a very rear case to see someone subscribed to a big descktop environment repo and not subscribed to the contrib." Nevertheless, the fact that prt-get's dependency resolver pulled in some contrib ports, when dutch installed XFCE, suggests that the policy cited by sepen is not the current practice these days.

20:43 <r0ni> what is said policy? (sorry for my ignorance) the readme for my repo does state one needs contrib enabled

20:46 <r0ni> oh that thread is a bit outdated, and here I thought I'd done deserved a slap on the wrist

20:48 <r0ni> i'd assume any 3rd party should at least work against the official repos- core,opt,xorg and yes contrib... now the lxqt is 2 repos deep, depending on plasma6 as well... and that one is a fn nightmare to get right unless ones installed plasma already

20:55 <farkuhar> r0ni: yeah, that thread is pretty ancient. It would be interesting to learn when contrib began to acquire a more respectable status. Obviously in 2008 it still had an aura of "here there be dragons", and users were cautioned against activating it without lengthy deliberation.

20:56 <r0ni> well TBH i'd only call it respectable on x86... things will burn trying to use it normally on arm

20:57 <r0ni> but i've found most thats there almost always perfect and linux itself has come a long way since 2008 too

21:06 <farkuhar> zorz recently asked why the contrib repo was deemed the right place for lynx, back when Mark Rosenstand introduced it all those years ago. zorz cited the natural pairing mutt + lynx as an argument that lynx should be in opt instead.

21:10 <farkuhar> There's already opt/links, though, and who needs so many alternatives for browsing the web in a terminal?