<farkuhar>
the handbook and the ports tools themselves are agnostic on the issue of wayland versus x11. It's still up to the user, which windowing system (if any) they want.
<beerman>
but ports currently opt to depend on x11 over wayland if they need something
<beerman>
libxcrypt for glibc is also worth talking about, I'd want to include that, same as libbsd and libmd for shadow
<beerman>
but i expect not everybody likes the idea of more core ports
<jue>
farkuhar: jaeger found a problem with your prtwash, fixed with the patch you've posted?
<farkuhar>
jue: to my knowledge the one-line fix should be enough. But I'll let jaeger report on how the automated ISO build goes, after applying that patch.
<beerman>
if anybody can improve it that would be great also but i am not sure what else to do
<jue>
farkuhar: what do you think, I'd like to hand over prt-utils to you?
<farkuhar>
jue: fine by me.
<jue>
great
<jue>
beerman, jaeger: objections?
<beerman>
i have none, farkuhar has been doing great work with it
<jue>
yep
<farkuhar>
beerman: speaking of vulkan, I did end up having to rebuild shaderc after the update. I haven't bumped the release number yet; hopefully most users who run into issues will try `prt-get update -fr`
<beerman>
on the /etc versus /usr/etc topic, I have to say I'd prefer to flatten it to /etc
<jue>
wrt libxcrypt, libbsd and libmd: it's ok for me to include them in core
<beerman>
farkuhar yeah if I wasn't mistaken shaderc is the problematic port that makes mpv go or not, after updating vulkan ports, but i wasn't too sure.
<beerman>
jue great, i'll integrate it over the weekend if nobody beats me to it :)
<farkuhar>
beerman: actually, the existing /usr/bin/mpv continued to work for me after the vulkan update; it was only when I needed to run /usr/bin/glslc again that I was affected by shaderc breakage.
<beerman>
glslc? Never used that binary tbh
<beerman>
still interesting
<beerman>
vulkan is still bit of a mess
<jue>
farkuhar: I see at least one problem with the optional stuff: our hard deps are AND linked, but the optional stuff is OR. What if a ports a group of optional ports. gnuplot is one example, I've grouped the optional qt6 ports with () together, just to do anything ;)
<jue>
* What if a port needs a group of optional ports.
<beerman>
thats a good point
<farkuhar>
jue: good point; I think this is where the concept of a metaport might be useful. Optionally depend on the metaport, not the individual components, if an entire group is needed.
<jue>
hmm, not convinced. In case of gnuplot a metaport with (qt6-5compat qt6-tools qt6-svg)?
<farkuhar>
that's my best guess at how to solve it, as of now. I'll need to think some more about possible side-effects, though.
<farkuhar>
regarding the rust update, do we know the specific piece of the toolchain that is allowing it to succeed on CRUX 3.8, but failing on 3.7?
<beerman>
it fails to link the first set of i686 target files
<beerman>
i suspect binutils or gcc, since it uses gcc directly to link the bootstrap stage
<beerman>
haven't had time to look deeper into it yet, maybe tomorrow
<beerman>
since it fails with clang/lld as well, i am leaning towards binutils