henesy has quit [Remote host closed the connection]
henesy has joined #crux-social
ppetrov^ has joined #crux-social
farkuhar has joined #crux-social
<SiFuh_>
farkuhar: That laptop still hasn't booted
<farkuhar>
SiFuh_: It sounds like a piece of electronic waste, then.
<farkuhar>
I made some updates to the 3.7 Handbook, in the sections on kernel building and syslinux setup. Still haven't eradicated your pet peeve, /boot/efi/EFI/BOOT
<SiFuh_>
Hehe
<farkuhar>
Hmm, ChangeLog and NEWS at shadow-maint haven't been updated in 2 years. I guess they expect distro packagers to read https://github.com/shadow-maint/shadow/releases to learn what's new with each release. But that's just as unwieldy as reading the git commit history.
<farkuhar>
I'm trying to figure out which shadow version started requiring the libbsd-provided readpassphrase function. Older versions build just fine without trying to eagerly link libbsd.
<ppetrov^>
farkuhar, any plans to implement an easy to follow ChangeLog section at crux.nu?
<ppetrov^>
farkuhar, well, as we discussed some months ago, is it possible to at least parse the commit messages from gitea for core, opt, xorg, contrib to a html that is found easily on crux-nu
<farkuhar>
The opt/iputils update 20240117 -> 20240905 added four new man-pages, but placed them under /usr/man instead of the usual /usr/share/man. This layout appears intentional, judging from the `install $name-$version/doc/*.8 $PKG/usr/man/man8` line in the Pkgfile, but it deviates sharply from standard CRUX directory structure.
<ppetrov^>
maybe just a mistake out of habit or sth?
<farkuhar>
A mistake by jue? Inconceivable!
<farkuhar>
Maybe nobody noticed the non-standard man-page location because opt/iputils is not required by any other port except contrib/gping. And who needs a fancy GUI to see the results of ping? https://github.com/orf/gping
<farkuhar>
It makes me wonder why iputils is in opt, anyway. If its only dependent is a contrib port, why not move it to contrib, leaving opt just a little less cluttered?
<farkuhar>
I'm baffled at how I manage to have libbsd still installed under /usr/opt, where it won't be eagerly detected when building other ports. I never issued a `prt-get lock libbsd`, and there's no libbsd in any overlay collection. Maybe they changed the Pkgfile and moved it into core, all without bumping the version.
<farkuhar>
cd /usr/ports/core/libbsd; cut -f3 .footprint | sed 's/ ->.*//' | while read -r f; do [ -e "/$f" ] || echo "/$f not installed"; done
<farkuhar>
^ gives me 41 hits.
<farkuhar>
All 41 hits are actually under /usr/opt instead.
<farkuhar>
You would think that bumping the version or the release is an obvious step, when rearranging the footprint of a port. But somehow libbsd was never flagged as in need of an update, after I first installed it under the non-standard location /usr/opt.
<farkuhar>
Actually some of the 41 hits were missing from /usr/opt too: /usr/opt/libbsd/lib/libbsd-ctor.a, /usr/opt/libbsd/lib/pkgconfig/libbsd-ctor.pc, and /usr/opt/libbsd/share/man/man3/reallocf.3bsd.gz
<ppetrov^>
farkuhar, libbsd has a readme about the unusual file places
<ppetrov^>
would be handy if the HandBook would mention about when to use /usr/opt
<farkuhar>
ppetrov^, the libbsd/README was only provided when the port was in contrib. Once they moved it to core (in the 3.8 branch), the README disappeared, the footprint changed, and yet they didn't even bump the release number!
<ppetrov^>
well...
<farkuhar>
So if someone installed libbsd while it was still in contrib, and then did a `git checkout 3.8` in the core repo, `prt-get diff` would never report libbsd as in need of a rebuild. Seems to be what happened in my case, which is lucky because I managed to avoid darfo's fate with the eager linking.
<ppetrov^>
did you twll this in #crux-devel?
<farkuhar>
ppetrov^: I don't think there's a consensus about the practice of putting stuff in /usr/opt. jaeger followed that advice after an early discussion on adding libbsd to contrib, but it wasn't meant to set a precedent because so few other libraries get eagerly picked up by autotools builds the way that libbsd does, meriting darfo's description "cancer for a Linux system".
<farkuhar>
ppetrov^: You saw what frinnst wrote in #crux about in-place upgrades. It's not safe in general, checking out the 3.8 branch and then running prt-get sysup.
<ppetrov^>
farkuhar, i actually did not see that, i am semi-following the discussion here
<farkuhar>
It's funny that by keeping $version and $release unchanged when moving libbsd from contrib 3.7 to core 3.8, they actually created the rare counterexample to frinnst's claim about in-place upgrades being unsafe. By not triggering a rebuild, they allow libbsd to remain in the non-standard location where it won't be detected by autotools.
<farkuhar>
But the in-place upgrade is only safer for users who already installed libbsd from contrib 3.7. If they switch the core repo to the 3.8 branch and then sysup, the lower priority assigned to the contrib repo will result in the installation of the libbsd dup that puts stuff under /usr, rather than the dup that puts stuff under /usr/opt.
<SiFuh_>
I took out the hard drive from the laptop and run a smartctl test on it. It has over 900 errors in its history. So I took another drive I have. Ran smartctl on it and it was passed. Nothing wrong with it at all. So I plugged it into the laptop. The laptop booted very fast then 15 minutes later it stopped. So I powered off and my hard disk is fried.
<ppetrov^>
test the laptop
<SiFuh_>
The hard disk has "End_to_end" failure and the laptop has "DRA FAILURE"
<SiFuh_>
So the original drive is on its way out. I checked the ribon cables and the connectors. They are fine. So I am guessing something is fried with the SATA controller. The only other thing I could do is a firmware update. But couldn't be bothered.
<SiFuh_>
Ribbon*
<zorz>
which laptop?
<zorz>
this is serious!
<SiFuh_>
Pile of shit i3/Radeon HP. I won't waste my time with it. If they don't want it. I will poach parts off of it.
<SiFuh_>
farkuhar: It is why I run prtcheck before I upload ;-)
<farkuhar>
What do you think CRUX-MUSL should do about libbsd and libmd? Keep patching the core ports so that none of them depend on that shit, or apply the /usr/opt workaround to prevent eager linking? The latter strategy would involve tweaking the Pkgfiles for a few core ports whose libbsd dependency is too hard to patch away.
<SiFuh_>
My favorite scene is when he is late for hockey and bumps into her and she falls on her arse. She shouts back "What were you raised in, a barn?" and in the background the Anthem is playing and he replies "Honey, where I’m from we stand for the national anthem."