<SiFuh_>
farkuhar: "I have only tested it on a core CRUX system without any of opt or contrib ports installed" This isn't true. I ran a fully fledged CRUX system with it.
<SiFuh_>
farkuhar: That place in Bali is 1,200 Euro for 7 days :'-(
<farkuhar>
Admittedly, the gdbm update 1.24 -> 1.25 succeeds on CRUX-glibc even without the omitted #include, but it seems wasteful to carry a dup in the musl overlay when the official core port could be made more compatible.
<farkuhar>
I had to speak to drown out SiFuh_'s spam.
<SiFuh_>
Hahaha
<farkuhar>
LLVM making GCC redundant is somewhat different from libressl replacing openssl. Although in both cases the latter option is regarded as "ancient technology", LLVM has enjoyed wider adoption than libressl ever did, giving it that much more inertia to displace the older option.
<SiFuh_>
farkuhar: Well I an considering removing sudo completely and replacing it under /opt with opendoas
<SiFuh_>
And I will probably replace opnssl again with libressl but then you will have more fun with rust ;-)
<farkuhar>
sudo isn't even a runtime dependency for any other port. What is it doing in core anyway?
<SiFuh_>
My argument for a long time
<SiFuh_>
I don't see the need of sudo ever being in core because su works fine.
<SiFuh_>
farkuhar: I was even thinking but not too much that MUSL should have its own repo for core and maybe opt
<farkuhar>
The opendoas port that beerman maintains in contrib actually lists linux-pam as a hard dependency, rather than optional. Savvy users can disable this hard dep with `prt-get lock linux-pam`, or by maintaining a dup in their overlay.
<farkuhar>
As long as linux-pam remains in core, beerman is just implementing distro policy by declaring the hard dependency in his opendoas port.
<farkuhar>
But if linux-pam got moved to opt, then it should be demoted to a soft dependency of opendoas.
<SiFuh_>
I did all that in 3.7
<farkuhar>
Anyway, now that OpenBSD is uploading 7.7, I felt comfortable doing a security erase on my spare SSD containing an old installation of OpenBSD 7.6. I used the freshly-wiped SSD to reinstall CRUX-MUSL (core only) from ukky's ISO.
<farkuhar>
Hopefully after working my way through a sysup on this freshly-installed system, I can get a working llvm+clang+rust toolchain.
<farkuhar>
What would we be trying to accomplish by giving MUSL its own repo for core (and opt)? Preventing junk like linux-pam or dumb_runtime_dir from getting pulled into a depinst transaction? But we can accomplish that already, with dups of the affected ports in a muslcrux overlay.
<farkuhar>
All it requires is to give the muslcrux overlay a higher priority in prt-get.conf, and then the dependencies listed in the official repos will be ignored, letting us set the dependencies to whatever we prefer.
<SiFuh_>
No
<SiFuh_>
If I prt-get depinst the ssh port it will pull linux-pam from core because that is where it exists
<farkuhar>
Not if you have a dup of ssh in the muslcrux overlay, where linux-pam is not listed as a dependency.
<farkuhar>
As I said, you have to prioritize the muslcrux overlay so that the ports in core and opt are masked.
<SiFuh_>
SO you want me to duplicate all ports that pull linux-pam that magically appear when beerman is done fucking around with is gayland shit?
<SiFuh_>
Not all ports will build against linux-pam if it doesn't exist
<farkuhar>
SiFuh_: It's actually not so many ports that list linux-pam as a hard dependency. There won't be as many dups as you seem to be suggesting.
<SiFuh_>
I can't remember which one, but I think it was xorg-xdm that will just ignore pam if it isn't installed
<farkuhar>
I'm more worried about what might break if I temporarily remove libbsd and libmd, before building new versions that install under /usr/opt (where they won't be eagerly linked). I might not want to make those changes inside an SSH session, on the chance that removing libbsd and libmd will render the running ssh process unusable.
<farkuhar>
The shadow password suite also links to libbsd and libmd. If I forget to open a root shell where the new lib{bsd,md} packages can be installed from, then I might not be able to continue the operation.
<SiFuh_>
Why be worried?
<SiFuh_>
farkuhar: "Can I borrow your spanner?" "What for?" "This" "You mean screw driver" "Oh, hahaha. Can you tighten it for me" "Seems tight already" "No I want it tighter." "Are you sure? It's just plastic." "Tighten it!" Not even one turn, broken. "Why do you break everything?" she shouts. HAHAHAHAHA
<farkuhar>
Worried because sitting down at a console to carry out the lib{bsd,md} operation must be timed correctly, lest the loud sound of my mechanical keyboard disrupt the sleep of my housemates. It's less disruptive to SSH into that machine from a laptop whose keyboard is quieter.
<SiFuh_>
farkuhar: Put ear plugs in so it doesn't disturb you when they shout :-P
<farkuhar>
I started making a list of ports that will eagerly link to lib{bsd,md} even though they don't list those libraries as hard dependencies. In the xorg collection: xorg-lib{x11,xcb,xdmcp} -- and probably many others that I haven't yet built on this fresh installation.
<SiFuh_>
farkuhar: nice, when that list is ready, I will be curious to. If it isn't essential, it would be good to strip it out. However, I know some of my SDR stuff uses it.
<SiFuh_>
farkuhar: But I do beleive that MUSL core and GLIBC core will end up very different. So it makes sense to have our own repo.
<farkuhar>
It was inconsistent of beerman to declare linux-pam as a hard dependency for opendoas, but not declare the eager linking that occurs between lib{bsd,md} and some {opt,xorg} ports. Forgetting to mention these hidden dependencies means that users who wait too long between sysup are at risk of updating lib{bsd,md} *after* some of the ports that would eagerly link to them, possibly necessitating a rebuild.
<farkuhar>
IIRC the dependency resolver in prt-get does not have any logic to put core ports at the head of the queue, so if libbsd or libmd are flagged as out-of-date along with a non-core port like xorg-libx11, then it's possible the sysup works on xorg-libx11 first, only later getting around to the libbsd and libmd updates. That's a recipe for breakage.
<farkuhar>
I did insert a test into my prt-get reimplementation, so that if glibc is among the out-of-date ports during a sysup, then the sorting algorithm puts glibc at the head of the queue. But I never extended this test to prioritize all core ports; the remaining out-of-date targets were simply sorted according to the dependencies found in their Pkgfiles.
<SiFuh_>
I don't think beerman can be blamed for linux-pam since jaeger introduced it into core. So if it exists in core, it would make sense to utilize it right?
<SiFuh_>
farkuhar: My repo is being sysup'ed as we speak. It has been down a long time. So it has a lot of updates to do.
<SiFuh_>
I just finished that 6.12.23 kernel for jaeger and the ISO
<SiFuh_>
Also one of the guys in #crux-devel mentioned that NVIDIA doesn't work against 6.12.X yet
dlcusa has joined #crux-musl
<SiFuh_>
Welcome back dlcusa we all missed you
<farkuhar>
When will we get the chance to say "welcome back stenur"?
<dlcusa>
Thank you. My hexchat server crashed last night w/o warning for the 2nd time in two days, so I'm moving hecchat to a different box.
<dlcusa>
"welcome back stenur"
<dlcusa>
Oh, you mean when he's connected. ;-)
* farkuhar
runs /names to see if a join message slipped through the cracks
<farkuhar>
Nope, apparently he hasn't learned of this channel yet. Or if he has, he's too busy to join.
<SiFuh_>
farkuhar: Oooooooo I should ask him
<SiFuh_>
What is the hexchat? GUI I guess?
<SiFuh_>
farkuhar: Done.
<SiFuh_>
farkuhar: Should ask lavaball to
<SiFuh_>
Hahahaha
<dlcusa>
SiFuh, hexchat is the app I use for IRC.
<SiFuh_>
I don't speak Steve Jobs, what is this app you are referring to?
<SiFuh_>
dlcusa: I just searched it is a GUI
<dlcusa>
It also has a 1 manpage.
<SiFuh_>
I just had a thought. If farkuhar had prnounced GUI as gooey. I'd have slapped him. hahaha
<dlcusa>
Now I've got it issuing StarTrek Red Alerts when channels receive something (I wonder how long until I decide that's enough of that?).
<SiFuh_>
dlcusa: I prefer irssi. Tried XChat first when pIRCh and mIRC was all the rage in Asia but it didn't anything for me.
<SiFuh_>
dlcusa: No idea. Star Trek sucks shit.
<dlcusa>
Your mileage clearly varies.
<SiFuh_>
Nothing compares to Babylon 5
<dlcusa>
No arguement.
<dlcusa>
Is this off-topic?
<SiFuh_>
No it is farkuhar's channel so we can spam it with off-topic stuff. Hahahahahahaha
<dlcusa>
'Twas thimking of emmett...
<SiFuh_>
He'd be snoozing by now.
<SiFuh_>
He vanished about 4 hours ago in our PM Telegram chat.
<SiFuh_>
dlcusa: Las comment was a laugh at the reply to my wife's message "Aunt Sally (The dog) drank water from the gutter" and I replied "Aunt Sally licks her own vagina and rectum" I could hear the wife laughing from down the road when she got that message
* SiFuh_
afk and afd :-P
<farkuhar>
Heh, contrib commit a554f3911dbfe8723d5942c6b82ef267c8cdf6ee was supposed to fix the last typo in the libbsd README, but it merely exchanged one typo for another. (unbalanced double-quotes instead of unbalanced braces)
<farkuhar>
I notice that jaeger only sequestered libbsd under a non-standard prefix in contrib/3.7, whereas libmd was allowed to populate the usual /usr/{lib,include}. I wonder whether that was sufficient to shield libmd from being eagerly linked into other ports.
<farkuhar>
One key change when libmd got moved from contrib/3.7 to core/3.8 is that they put the shared library directly into /lib, making it available even if /usr is a separate partition that hasn't been mounted yet. This change makes me suspect that they anticipated libmd being needed by something during early boot. Any ideas what that might be?
<farkuhar>
Upstream devs closed the issue https://github.com/conformal/spectrwm/issues/586 , saying it was addressed in the current release (3.6.0), but somehow the version packaged by jue in opt/3.8 is still contaminating the environment with LD_PRELOAD. This leads to spurious appearances of spectrwm in the output of every `finddeps` command.
<farkuhar>
Anyway, I successfully updated libmd and libbsd, sequestering both of them in a non-standard prefix. The most essential ports to fix after that were shadow and openssh, but I went ahead and rebuilt the other ports that were eagerly linked to libmd and libbsd. Everything's running smoothly so far.