<SiFuh_>
farkuhar: First of all, I have never given anyone permission to post my stuff. Secondly it isn't ready it has only been forwarded to people willing to test it. Thirdly I told jaeger in the email if he read it that it will be done probably by next month. So as long as everyone has patience, it will actually probably be ready quite soon.
zorz_ has joined #crux-musl
zorz_ has quit [Quit: leaving]
farkuhar has joined #crux-musl
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-musl
<farkuhar>
Heh, rc-colour as its own port overriding rc, that would be a job for prt-get.aliases if rc weren't in core. I recently had another opportunity to add a line to prt-get.aliases (sdl12-compat: libsdl) because on a fresh installation of CRUX-MUSL the legacy port libsdl-1.2.15 wouldn't build. Even the upstream project recommends sdl12-compat instead.
<farkuhar>
I have yet to test all the ports that claim libsdl as a dependency, to see whether they build fine against sdl12-compat. The one dependent that I did test, had no errors during the build.
<SiFuh_>
farkuhar: Actually rc can be in core, you could even put rc-color in core.
<SiFuh_>
Just you can only select one
<farkuhar>
I meant that with both of them in core, and none of them providing dynamically-linked libraries, distro policy prevents them from being listed on anybody's dependency line. So prt-get would never have reason to search its aliases file for either rc or rc-color.
<SiFuh_>
distro policy prevents them from being listed <-- I actually do not think that is a thing
<farkuhar>
Heh, zorz was using the `prt-get dependent` command recently, for python3-cython, I believe. Maybe he'd be willing to report also the results of `prt-get dependent --all rc`
<SiFuh_>
And besides, I doubt anything depends on it, or is a dependent of it.
<farkuhar>
Yeah, it's not a dependency for anything, and neither is grub or syslinux. So it's a choice that setup-helper (or just setup) would have to be programmed to handle, if we wanted to go that route.
<farkuhar>
Hmm, libsdl is not installed on the laptop that I upgraded from CRUX-MUSL 3.7 to CRUX-MUSL 3.8 ... I could have sworn I had a CRUX-MUSL 3.7 installation where the libsdl build actually succeeded. Maybe it's on the spare hard drive.
<SiFuh_>
Well, did you test that rc of mine?
<SiFuh_>
I am unsure if jaeger even recieves my emails.
<farkuhar>
In case anyone's curious, the libsdl build errors are all due to iconv_* functions, which are obviously not implemented the same in musl as in glibc. So rather than go hunting for patches to legacy software, I just wrote a port for sdl12-compat.
* farkuhar
reboots to test SiFuh's rc
farkuhar has quit [Quit: nyaa~]
farkuhar has joined #crux-musl
<SiFuh_>
farkuhar: Hmm, I thought you'd have had a VM to do that on. Oh well. I tested it without rc.functions, tested it with rc.functions, tested with colour and verbose set in all. So many reboots on this dinosaur box. But I never tested advanced terminals that support over 8 bit colours.
<farkuhar>
SiFuh_: No VM here, just a few spare machines in various approximations of up-to-date.
<SiFuh_>
My machine came out of the trash bin at the back of some offices down the road.
<SiFuh_>
That is why the photo of the screen is so yuck. And it has a broken stand. So it is balancing upright.
<SiFuh_>
If I slide the screen, it powers off and on again. Because the button is underneath it.
<farkuhar>
I did get one unexpected message at startup. When mounting /home, recovering the journal was needed. I would have expected the sync commands in rc shutdown to prevent journal errors like that.
<SiFuh_>
I feel like Donatello from the Ninja Turtles
<SiFuh_>
I have three sync commands in rc.shutdown.
<SiFuh_>
Unmount all filesystems has 2 syncs and Remount the root filesystem as read-only has 1 sync.
<SiFuh_>
Old school sync; sync
<farkuhar>
Note that it wasn't the root filesystem whose journal needed recovery, only /home. Both are formatted ext4. I should check /proc/mounts to see how /home is listed.
<SiFuh_>
Yeah, if it is weird we should take note.
<SiFuh_>
But pretty much the old rc.shutdown and the new rc shutdown are very similar, just removed the deprecated parts and put in a proper LVM support
<SiFuh_>
Your /home isn't LVM right?
<farkuhar>
I need to remember not to click the "[reboot]" button on my X11 login screen, but to switch instead to tty1 and issue the shutdown command at the console. Because in tty7 (where the xdm login daemon was listening) I can't see any messages during shutdown or reboot.
<SiFuh_>
Ahhh, I have never tested anything to do with Xorg
<SiFuh_>
farkuhar: I wonder if jaeger does receive it and pushes it to CRUX git.
<farkuhar>
No switching to runit for CRUX-MUSL, which is meant to be a continuation of Per's legacy. But the question remains: would port maintainers find it easier to write runit service files correctly, and not make so many mistakes as are found in the rc.d scripts?
<SiFuh_>
Heheh I don't think so
<farkuhar>
Heh, laziness is laziness, no matter which program we choose for starting up the system and launching services.
<SiFuh_>
Oh and a side note. Don't forget the main and most important of Per's design was BSD style scripting. So runit would probably be out of the question.
<SiFuh_>
Didn't zorz give up on just recently and go back to rc?
<farkuhar>
I can't keep track of zorz and all his distro hopping.
<SiFuh_>
hopping? I call it whoring
<SiFuh_>
I spent 3 days messing around with the rc. I am satisified until someone else finds an issue. I will go smoke a cigar with the dog.
<farkuhar>
Go ahead, you deserve it.
<SiFuh_>
I told jaeger next month haha but after all the attention it drew that the rc has issues, I decided better I just do it. And thanks for your idea by the way. I was a sleep and subconsiously thinking about it in the back of my head and I think your idea of the rc.functions was probably the best.
<SiFuh_>
farkuhar: my wrapper script was pretty cool though. Divert the output through a filter and change the colour.
<SiFuh_>
I tried to overide the printf in bash but it just wouldn't allow it. So I hijacked the output instead.
<SiFuh_>
It was a fun experiment if you want every text red :-P
<SiFuh_>
farkuhar: So from what I see -a = all, -d = loopback devices, -r = try readonly (in failure), -t = type. So I wonder why the umount -a -r is run again.
<SiFuh_>
I don't use /home for anything really. So I should have created on for the test.
<SiFuh_>
farkuhar: I see what is happening. They are trying to umount everything that is not a no* and if it fails they mount let's say / as read only because /home may not have umounted because they may have attempted to umount / before /home. Hence the second run. Umount all the temp shit. /home would have been umounted previously after /root failed.
<SiFuh_>
/root /*
<SiFuh_>
So the since umount doesn't have a reverse umount option I can see in the man pages. Rather than calling a command like awk and sort, they ran it more than once.
<SiFuh_>
farkuhar: That would explain why your /home didn't umount and you needed that second line
<SiFuh_>
Maybe.... your home didn't umount with the first command.
<SiFuh_>
You don't have anything mounted under /home
<SiFuh_>
Right?
<SiFuh_>
Maybe we should poach the OpenBSD's umount