<farkuhar>
I put "improvements" in quotes because all those nested printf commands in /etc/rc could arguably be simplified. If you inline the new functions, you might even find a misplaced closing parenthesis. Run it through `shellcheck -x` to confirm.
<farkuhar>
I could change the anchor myself, s/ntoc22/ntoc21/, but why draw attention to all the new variables supported in /etc/rc.conf, when they couldn't be bothered to run shellcheck on the script that makes use of those variables?
<farkuhar>
Speaking of shell script messiness, I notice that fluxbox installs /usr/bin/startfluxbox, which uses legacy backtick syntax on line 3, and also spawns a superfluous subshell to create a default "$startup" file. There's no test of whether the parent directory of "$startup" is writable, or whether an existing (but not runnable) "$startup" can be overwritten.
<SiFuh_>
No need. Errors out and closes and leaves a bitch message in .xsession-errors
<farkuhar>
I like to see scripts that test the exit status themselves, and handle the reporting of any errors. Scripts that leave it to the individual commands to generate output, might not exhibit a uniform style. But I guess that's just personal preference.
<farkuhar>
It is possible to take such preferences too far, the way beerman has done with the /etc/rc "improvements". In trying to ensure a consistent style, he defines so many abstractions that it's easy to invoke them in a way that shellcheck will complain about.
<farkuhar>
Going by FeodorPetrov's comment in https://git.crux.nu/tools/pkgutils/issues/4#issuecomment-460 , I shouldn't find any entries in /var/lib/pkg/db matching 'usr/lib/.*\.la' if I write a pkgadd.conf rule "INSTALL ^usr/lib/.*\.la$ NO" prior to installing something like imlib2. But I checked just now, and /var/lib/pkg/db does indeed list files like usr/lib/imlib2/loaders/tiff.la
<farkuhar>
I don't mean to pick on imlib2 in particular; there are plenty of other ports that don't preemptively purge the libtool garbage from their footprints. But imlib2 is interesting because it's listed as a hard dependency for fluxbox, yet fluxbox compiled just fine without imlib2 installed. Does that mean imlib2 is merely a runtime dependency for fluxbox?
<farkuhar>
I hope I'm not misreading FeodorPetrov when he writes "pkgadd does not create entries in db for ignored files". I assume he meant I wouldn't find them listed in /var/lib/pkg/db, not that I wouldn't find them in the filesystem. We already agree that pkgadd does the right thing on the latter metric. Indeed, `ls /usr/lib/imlib2/loaders/*.la` returns nothing.
<farkuhar>
The linked ticket https://git.crux.nu/ports/core/issues/7 makes a distinction between 1, saving under /var/lib/pkg/rejected those files that were blocked by an INSTALL NO rule; and 2, writing into /var/lib/pkg/db the entries for such files. beerman correctly pointed out that the first behaviour is a "new feature" request. But the second behaviour, if confirmed, would suggest that my own observations
<farkuhar>
on imlib2 (and others) are not reproducible across all CRUX installations.
<SiFuh_>
What do you mean /etc/rc ?
<SiFuh_>
beerman should not be touch /etc/rc at all
<SiFuh_>
beerman has no authority to touch rc. He is a port maintainer not a developer
<farkuhar>
SiFuh_: wrong channel dude. Post your concerns in #crux-devel.
<SiFuh_>
What the fuck has happened to the rc?
<SiFuh_>
farkuhar: This is shameful. Whomever did this is a fscking amateur.
<SiFuh_>
And it is has been pushed into the official realm for the world to see? WTF
<SiFuh_>
farkuhar: Alright, been through and fuck no. I am not putting that abomination into CRUX-MUSL.
<SiFuh_>
Like a fucking 15 year old child with limited code writing experience produced that puke.
<farkuhar>
Heh, AI might have produced something cleaner, if you prompted it with the bullet points on the TODO38 wiki page.
<farkuhar>
I blame myself for copying some of stenur's feature requests (and old Flyspray tickets) into bullet points on the TODO38 wiki. I guess beerman read them as an invitation to go wild with /etc/rc.
<dlcusa>
SiFuh, forgive me for being too terse. That page and a few others was what 0.9.2 offered as a Handbook. I think we need at least a Handbook to jump off from.
<SiFuh_>
farkuhar: I just did, but didn't prompt it. I gave it rc.function and rc.conf and rc and said "What's wrong?" and it complained about the printf just like shellcheck then said I can use shellcheck to verify
<SiFuh_>
farkuhar: I looked through the history. He's been fucking with rc for 3 years. 161 new entries!
<SiFuh_>
Not sure if all 161 are his though
dlcusa has quit [Read error: Connection reset by peer]
dlcusa has joined #crux-musl
<farkuhar>
161 commits in 3 years? It sounds like he took to heart the mantra "publish early and publish often" (usually associated with kernel development, or free software more generally)
dlcusa has quit [Read error: Connection reset by peer]
dlcusa has joined #crux-musl
<SiFuh_>
farkuhar: Not sure if it is entirely him since the start of it being in gitea. Probably everyone's contribs in total.
<SiFuh_>
farkuhar: If I could have clicked the 161 and listed all the changes, then I could see it. But I am both dissapointed and disgusted that this barbaric change was implemented. I wonder how many people who test CRUX 3.8 are going to complain about how poorly it was written
<SiFuh_>
Someone was playing with macaroni and glue making an rc for CRUX with glitter
<farkuhar>
The ee9ec453 commit illustrates yet again his preference for spaces instead of tabs. Other than that, nothing quite on the level of the 2.32 -> 2.33 changes.
<SiFuh_>
Actually if you are doing bash you should really choose spaces over tabs. Because bash has been changed to 2 spaces. Mostly because you ran out readable columns
<SiFuh_>
Too many lines were being wrapped because of so many tabs
<farkuhar>
As for ab251eac6a, the user was always free to add back a line like FONT=sun12x22, if the devs accidentally shipped rc.conf without any such default. Speaking of which, I find it rather comfortable to work at a tty with FONT=sun12x22, even on a high-res monitor.
<SiFuh_>
Actually it would be far better to modify the tab two cursor spaces instead of 4
<SiFuh_>
I use space for everything except that one.
<SiFuh_>
Verily, I shall proceed to complete mine viewing of this television series. Let me uncork a new ale and revel in the invigorating froth and fragrance whilst I assuage my eager thirst.
<farkuhar>
Speaking of tabs ... dash and bash have different ideas about the allowable flags for the builtin `echo`. bash recognizes `echo -e` to enable expanding \t into a tab, and `echo -E` to disable such expansions. dash doesn't support either flag.
<farkuhar>
So if you want a post-install script to do the right thing, no matter what the user has set as the runscriptcommand in prt-get.conf, it is best to use an absolute path: /bin/echo -e "$string_with_escape_sequences"
<SiFuh_>
farkuhar: Pet peeve? I think is what it is called. I don't think you should even use #!/bin/bash. Shebang? It should be #!/bin/env bash. It is pretty much universal accross the board.
<SiFuh_>
And as I discussed before farkuhar. All commands should have FULL path name.
<farkuhar>
Or you could resort to printf, whose behaviour across shells is more standardized. But printf would trigger too many bad memories of the rc 2.32 -> 2.33 "abomination".
<SiFuh_>
That printf thing pissed me off because it is a clear violation and incorrect usage. Yet it was approved by 3.8? What happened to jue? Shouldn't he be reviewing and adapting the changes the Tim made? He did with me and jaeger. How come Tim gets a free pass to do shit code but we have a fine toothed comb scrubbing our stuff. I think that this really needs to be addressed as it is very ammateur.
<farkuhar>
SiFuh_: I'm pretty sure the full path to env is standardized as /usr/bin/env. Tested on OpenBSD 7.6 just now: `ls /bin/env` -> No such file or directory
<SiFuh_>
Done!
<SiFuh_>
farkuhar: Yeah something like that.
<farkuhar>
SiFuh_: Thanks for speaking up where the core team might start to pay attention.
<SiFuh_>
farkuhar: It's been bugging me since you brought it to my attention.
<SiFuh_>
I mean the entire colour function could even be written into a single variable. Instead of repeating the same line over and over and over again. It could be done way shorter.
<SiFuh_>
My question though is why does an rc.function exist? Can't it be written into rc? Or is it because the modifer of the code has taken an easy way to bypass failure of not being about to read that? I don't know. But all I know is it is very ammateur work.
<farkuhar>
Heh, according to the timestamp in my home directory, there's a rc38.patch dated 2024-09-11 that I vaguely recall sharing via pastebin in the #crux channel. Hopefully they'll see greater urgency in fixing /etc/rc now, as opposed to 8 months ago when 3.8 was still in testing.
<SiFuh_>
I think this is a serious turn off. Even the point I am disgusted so much I don't want to touch CRUX anymore. If your rc scripts the foundations of booting your system into a working environment has been put together so weakly and cheaply, then what does that say about CRUX in general?
<SiFuh_>
As I said in crux, just paraphrasing myself. I have nothing against the new idea of introducing colours. It's just the way it has been written is my issue. It reminds me of a stenur port that beerman abused stenur for writing it so poorly and then beerman gets away with this poor code, in an official release?
<SiFuh_>
farkuhar: I asked stenur to look also.
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-musl
zorz_ has joined #crux-musl
<zorz_>
-- Packages installed
<zorz_>
python3-distlib
<zorz_>
-- Packages installed
<zorz_>
python3-setuptools-scm
<zorz_>
-- Packages installed
<zorz_>
python3-setuptools-scm
ukky has joined #crux-musl
zorz_ has quit [Quit: leaving]
<farkuhar>
Partial timeline as I've been able to reconstruct it: 2024-07-19 "rc: 2.32 -> 2.33" (161 additions, 61 deletions). Then on 2024-09-11 or thereabouts I shared a patch via pastebin. One of the incorrect quotations was fixed 2025-01-20, but the nested printf messiness still remained.
<farkuhar>
In retrospect, sharing a patch via IRC and pastebin was not durable enough to focus the core team's attention on it. I should have filed a ticket on Gitea.