<SiFuh_>
farkuhar: Not sure if your while loop is the best option for ansi colours because it makes it more difficult for a newbie to select the colour they want. For example. What if the put in "red bold underlined" out of order? So you may need to have examples in a comment section.
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-social
<farkuhar>
SiFuh_: Good point. I think there's some orthogonality among the control codes (e.g., "bold underlined" has the same effect as "underlined bold"), but I haven't tested all permutations to ensure they still work.
<SiFuh_>
farkuhar: Me too. I found an old machine. Kernel is compiling now.
<farkuhar>
SiFuh_: A few preliminary tests are confirming that order doesn't matter, at least for bold/underline/inverse. The colour name does have to be last, though. Easily fixed, by saving another control code to a local variable and then concatening when the loop is done.
<SiFuh_>
farkuhar: Seems a bit extreme :-P
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
SiFuh_: you scared away ppetrov^
<SiFuh_>
Heh
<farkuhar>
Another option is to sanitize the input to `get_color_code`, ensuring that the function always receives its argument from an approved list.
<SiFuh_>
farkuhar: I personally think the introduction of colours is just dumb
<farkuhar>
Sifuh_: Heh, that's why I suggest that we move the colour functionality to a contrib port, not bundled into a core port.
<SiFuh_>
farkuhar: I'd prefer to just keep it straight forward and simple. No need for loops and stuff. What if someone wants to copy the ANSI code for their script and now you have split it up?
<farkuhar>
"split it up?" <- You're referring to the list of pre-approved colour descriptions appearing separately from the loop that looks up the ANSI control codes?
<SiFuh_>
farkuhar: I wonder how much extra time it uses to use the while loop and assemble the get_color_code compared to mine just taking it?
<farkuhar>
SiFuh_: probably too small a difference to measure.
<SiFuh_>
farkuhar: Yeah, I see what you are doing. Making it smaller and more compact
<SiFuh_>
farkuhar: And I included a reset which I can't see in your script
<farkuhar>
\033[0m is RESET, right? That's the output when no arguments are given.
<SiFuh_>
Yes
<SiFuh_>
Or any incorrect arguments
<SiFuh_>
It's a kind of failsafe, even though I use it separatly in the rc.multi script as well.
<farkuhar>
There's a precedent for splitting up the code that performs a lookup (not necessarily human-readable) from the presentation of the resulting lookup table (more human-readable). The latter belongs in an ansi.colors man-page.
<SiFuh_>
farkuhar: This morning before I set up the slow cooker I had a quick look at the URL provided and cracked up laughing because the file I wrote at the top that said "DO NOT EDIT THIS FILE" it was like the first thing you did. Hahaha
<farkuhar>
I was going to write an rc.conf man-page anyway. I might as well write an ansi.colors man-page too.
<SiFuh_>
Well, I am not too concerned with what I have done with the colour yet. But as soon as this kernel builds, I need to work on LVM and I might put in some DEBUG options into rc.shutdown since the shut down logging too early. And maybe a Control C to get a shell before poweroff.
<SiFuh_>
And if it works, I'd probably leave it in the script anyway but commented out for future developers who want to debug
<farkuhar>
If the colour feature does get moved to its own port in contrib, then it would look kind of bare with only two entries (/etc and /etc/ansi.colors). A footprint with /usr/share/man/man5/ansi.colors.5.tar.gz (and its parent directories) would serve as better justification for a standalone port.
<SiFuh_>
And zorz wants me to look at the logging issues. He provided examples but I told him I have other ways
<farkuhar>
zorz thinks that /sbin/bootlogd needs to be started right after mounting /run, if I understand him correctly.
<SiFuh_>
I dunno. I don't think they'd bother since the ansi.colors would be useful out of rc as well.
<SiFuh_>
farkuhar: Yes
<SiFuh_>
Something about starting boot log to late and closing logging to early. But I will probably just create a /var/log/shutdown.log anyway
<SiFuh_>
/bin/dmesg > /var/log/boot
<SiFuh_>
Hmm, this is just a dmesg dump
<farkuhar>
According to bootlogd(8), the resulting log is "technically a text file, but not very easy for humans to read." I wonder why zorz cares so much about saving that output.
<SiFuh_>
darfo was talking about $1 by the way.
<SiFuh_>
I have $1 but it isn't used by most of the printerror
<SiFuh_>
The only time $1 is actually used is here....
<SiFuh_>
printerror "Failed to scan LVM volume groups"
<SiFuh_>
and ...
<farkuhar>
darfo's Gitea report, you mean? That was in reference to the 2.34.1 version of rc, and I already noted in #crux-devel 2024-09-11 that the nested printf functions were not being given the right number of arguments.
<SiFuh_>
printerror "Failed to activate LVM volume groups"
<SiFuh_>
{ printerror ; exit 1; } <--- can be modified too ---> { printerror "Some shit happened!" ; exit 1; }
<SiFuh_>
farkuhar: I couldn't find jaeger last night. I was going to ask him about those 1 line code lines and maybe suggest a more human readable version rather than something extremely compact.
<farkuhar>
SiFuh_: can you be more specific? Point to an example of a line that you consider extremely compact.
<SiFuh_>
I'd probably not even use those use that at all. I'd have /var/lock and /tmp as tmpfs
<SiFuh_>
use those use/use those*
<farkuhar>
Simone Rota made the commit that changed line 160 (previously the condition had been '! -name .' like line 161). Rather appropriate, given that his domain is varlock.com.
<farkuhar>
I disagree that lines 160--161 need to be made more human-readable. It's perfectly obvious what they're doing. Your stronger argument is that they aren't even necessary, if you deploy a default fstab with those mountpoints configured as tmpfs.
<SiFuh_>
No, it was an example of a short compact line.
<SiFuh_>
Also in OpenBSD they have rc.* built into rc. So no separate rc.multi rc.shutdown rc.single
<SiFuh_>
It could also been done in CRUX and have rc call a function so for example instead of rs:S1:wait:/etc/rc.single You could have rs:S1:wait:/etc/rc single
<SiFuh_>
By doing so, we could strip repeated code out of the separate rc files
<SiFuh_>
Just a thought
<farkuhar>
Heh, I remember thinking something similar.
<farkuhar>
So are there better examples of a short compact line? Something that actually needs to be taken care of by /etc/rc, and doesn't have an alternative solution using /etc/fstab?
<SiFuh_>
HAVE_X=false in rc.conf <-- then rc.fix could exist in rc but not run.
<SiFuh_>
Oh nevermind. rc.fix checks if /usr/share/fonts/X11 and /var/cache/fontconfig exists first.
<SiFuh_>
I have three crux machines running. All have no X at all.
<farkuhar>
rc.local and rc.modules are protected from upgrades by a pkgadd.conf rule, so it's expected that the user will customize them in-place. But rc.single and rc.shutdown and rc.multi could all be incorporated into rc, as you said.
<SiFuh_>
farkuhar: I will probably do that.
<SiFuh_>
OpenBSD has the option for /etc/rc.shutdown that a user can create for extra shutdown functions.
<SiFuh_>
Which I think is a really good idea to introduce
<SiFuh_>
Oh I did install xorg on the 4th CRUX machine that I am building today for the rc script overhaul. But that was to make sure no hidden surprises for people who run X
ppetrov^ has joined #crux-social
<SiFuh_>
farkuhar: Back on /var/lock. Is there any reason why anyone would want to keep certain files in that directory?
<farkuhar>
What about hidden surprises for people who partition with LVM? Are you experimenting with that feature on your 4th CRUX machine too?
<farkuhar>
I can't imagine anything in /var/lock that needs to survive reboot.
<SiFuh_>
Not yet. I am thinking to make an external LVM volume instead.
<SiFuh_>
Got a few extra drives laying around. Mount it as an encrypted LVM /home or something.
ppetrov^ has quit [Remote host closed the connection]
ppetrov^ has joined #crux-social
<SiFuh_>
farkuhar: ppetrov^ is bouncing off the walls.
zorz_ has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
<zorz_>
where is falken fauker farkuhar ?
<zorz_>
its okay no need
<zorz_>
:P
<farkuhar>
zorz_: Here
<zorz_>
neee
<zorz_>
i did it.... i was trying to set my overlay for crux
<zorz_>
i changed a bit your firefox, and mesa
<zorz_>
32 mins to compile firefox.
<farkuhar>
zorz_: Your computer must be very powerful. Here it takes at least 90 minutes to compile firefox.
<zorz_>
why in core/vim you dont enable clipboard and make my life miserable
<zorz_>
but you enable python and perl
<zorz_>
heh
<zorz_>
okay python... good addition from last year.
<zorz_>
i think i order my personal overlay even before core heh
<farkuhar>
zorz_: that's what we do with the muslcrux overlay.
<SiFuh_>
# Print error in color <--- should really be after ---> # Load colors. If file doesn't exist then disable color
<SiFuh_>
farkuhar: So can 'case' be up that high in the script too?
<zorz_>
i mean i hit vim --version and see crazy and normal things, thangs god no more farsi :P
<farkuhar>
SiFuh_: bash doesn't try to perform any parameter expansion until the function is actually called. It should be okay to define printerror() up front, and the main() function too.
<SiFuh_>
farkuhar: Hmmm
<SiFuh_>
Did you test it yet?
<farkuhar>
Not yet, I'll do so shortly.
<farkuhar>
Did you get a chance to view the man-pages I added?
<farkuhar>
Heh, I always forget to escape the hyphen when writing nroff. I'll have to push a quick fix there.
<zorz_>
4 tabs or 2 for Pkgfiles?
<farkuhar>
SiFuh_: When OpenBSD detects the presence of the user-created /etc/rc.shutdown, do those commands get prepended before the entirety of the usual shutdown sequence, or inserted somewhere in the middle (after /bin/stty onlcr, for example)?
<farkuhar>
zorz_: No tabs at all. The preference these days is to use spaces.
<SiFuh_>
farkuhar: No
<SiFuh_>
It is near end but after it is ifconfig going down
ppetrov^ has joined #crux-social
<farkuhar>
Hmm, that might be hard to implement, given that `/etc/rc.d/net stop` is part of the reverse loop through the SERVICES array.
<farkuhar>
It might be too drastic to propose eliminating the hand-curated SERVICES array entirely, and adopt something like NetBSD's rcorder (which would automatically determine the correct order for launching the enabled services).
<farkuhar>
A safe place for inserting a user-created shutdown script would therefore be after the reverse loop through the SERVICES array, right above "# Terminate all processes".
<SiFuh_>
Probably. But I have kernel compilation issues
<farkuhar>
It would be even safer not to reuse the same name rc.shutdown, and to test for a different name like rc.shutdown.local (which the user will be more willing to tweak).
<SiFuh_>
Don't agree
<SiFuh_>
rc.modules and rc.local have specific names.
<SiFuh_>
And the chances are no one is going to bother with the rc.shutdown script anyway unless they are zorz
<zorz_>
cant go back to vim, i added in Pkgfile # vim: filetype=sh
<zorz_>
fuck vim
<farkuhar>
We're proposing to change inittab so that it calls `/etc/rc shutdown` on runlevels 0 and 6, but not all users will notice the change. They might think /etc/rc.shutdown is still reserved for the CRUX team, not a file they can edit themselves.
<farkuhar>
That's why I suggested testing for /etc/rc.shutdown.local, so there's no confusion about repurposing a name that already has meaning in the CRUX context.
<zorz_>
zorz does not bother :P
<farkuhar>
Plus, if we test for /etc/rc.shutdown and users haven't deleted the existing file, then it will try to run commands that were already done as part of `/etc/rc shutdown`. Safer to test for a new name, one that is unlikely to be populated already.
<zorz_>
so far i have no libnotify, no c-ares, no gnutls... I am on the right path :P
<zorz_>
and no dav1d
<zorz_>
heh
<SiFuh_>
farkuhar: Well it seems you don't particulary care what users think. You took my alias.colors script that was super simple and easy to read and made it more complicated. Even after you were against the idea of me making it because it would be too difficult for new users to figure out.
<SiFuh_>
farkuhar: Compiling this kernel has taken 1.9GB of memory and chewed through it. Now chewing through my swap
<farkuhar>
SiFuh_: It's not too difficult to figure out, if the feature is accompanied by appropriate documentation. That's why I wrote the ansi.colors man-page.
<SiFuh_>
farkuhar: The write a man page for rc.shutdow..... bloody hell
<farkuhar>
zorz_: I haven't run dwm in years. I don't know how much of that is necessary for your day-to-day use.
<SiFuh_>
farkuhar: It doesn't need to exist anyway. A user who perused the rc script and notices the option could easily figure out. Hey I can create this file and add stuff.
<farkuhar>
SiFuh_: correct. I'm just making sure that we don't test for a file that might already be present, if the user is testing out the new rc-scripts manually (not using `pkgadd -u`, which would delete the rc.shutdown owned by the previous version).
<SiFuh_>
Going to archive my lib modules and transfer them to the new machine. See if I can reboot into that kernel and compile again since the ISO uses up a large chunk of memory
<farkuhar>
zorz_: xev is quite small, and could come in handy if you ever want to remap your keyboard or mouse. No need to delete it just because it shows up in the long output of `prt-get listorphans`.
<SiFuh_>
farkuhar: by the way, I could have kept all of the printf function code in ansi.colours but I didn't want to because I'd rather a clean file that is super simple. But using a while loop, you are no longer keeping it simple. You are turning it back into a beerman style rc.function so you may as well rename it rc.function again and shove all the print functions in.
<SiFuh_>
So farkuhar back on the bash thing above. so if I write a function do_some_shit I can now execute it at the beginning of the script before do_some_shit(){}. I always though it had to follow it.
zorz_ has quit [Quit: leaving]
<farkuhar>
zorz_: I notice you didn't contemplate removing xorg-xset. `xset q` is quite nifty, if you want to see the delay before a keypress goes on auto-repeat, or before a mouse click is registered. For some reason, I seem to need longer mouse clicks when running fluxbox, compared to what I remember running spectrwm.
<farkuhar>
SiFuh_: The way I understand it, bash function definitions can make use of variables that haven't yet been initialized, as long as those variables *are* initialized when the function is actually called.
<farkuhar>
As for the gratuitous use of the while loop, I wanted to take advantage of the orthogonality among bold, underline and inverse, so that users could pass those modifiers in whatever order they want, rather than having to remember a particular sequence. As long as they know the set of valid tokens, they can form an argument acceptable to get_color_code().
<farkuhar>
The man-page doesn't bother to list all the permutations, though. Only the ones in your original list. It takes a bit of experimentation to discover that "bold underline cyan" and "underline cyan bold" will yield the same output.
<farkuhar>
But anyway, the introduction of colour was already superfluous. Adapting the script to be more forgiving (when users pass the tokens in a non-standard order) might look complicated under the hood, but the end user will be grateful not to have one more detail to memorize (e.g., does underline have to come before bold, or after?).
<farkuhar>
I haven't uploaded it to the git repo, but here's a test you can try to verify the orthogonality among bold, underline, and inverse: https://dpaste.com/C4SLWK9HW
ivandi has quit [Quit: WeeChat 4.6.2]
ivandi has joined #crux-social
zorz_ has joined #crux-social
<farkuhar>
orthogonality and idempotence, actually. It turns out you can pass bold, underline, or inverse as many times as you want, in whatever order, and the printed output still looks the same. That's a very forgiving function.
<SiFuh_>
Nope, don't like it.
<zorz_>
with this crux... i startx, then i exit WM and i see ladder effect in console
<zorz_>
first time.
<zorz_>
any ideas?
<farkuhar>
zorz_: what do you mean by "this crux"? You're not still installing from the 3.8rc4 iso, are you?
<zorz_>
noooo fresh install iso
<zorz_>
but its first time i get this
<zorz_>
never in crux3.7 or void or debian
<zorz_>
its nothing... but is annoying for my eyes. :P
<farkuhar>
SiFuh_: Users weren't clamoring for colours in the console, but beerman went ahead and added that feature to a core port without asking for input from the broader CRUX community. But now we have a way to disentangle that feature from the core port, and users will be free to implement colors however they want. Some might prefer a fixed-strings lookup table, others will prefer a function that gracefully handles permuted args.
<farkuhar>
So even if I add my ansi-colors to the contrib repo, everyone is free to put a dup in their overlay that implements the feature in a more readable way. The crucial aspect of decoupling the non-essential feature from a core port has already been achieved.
<farkuhar>
zorz_: Fresh install from ukky's 3.8 crux-musl iso, and I don't see the staircase effect after exiting WM. My shell is oksh and my WM is currently fluxbox, although I'm not sure if that matters. Maybe the crucial difference is in our ~/.xinitrc?
<zorz_>
=======> ERROR: Building '/usr/ports/zorz/ack3/ack3#git-1.pkg.tar.gz' failed.
<zorz_>
why man..? i placed the zorz.pub in /etc/ports
<zorz_>
.xinitrc is the same for years.
<zorz_>
fuckin hell how do you sign the packages.
<zorz_>
SiFuh_: how do you sign a package in crux ?
<ppetrov^>
farkuhar, I am having trouble with pkg-get, downloading packages from my home server
<ppetrov^>
it downloads the package as a web page
<ppetrov^>
Saying: Moved Permanently
<ppetrov^>
The document has moved here.
<ppetrov^>
might it be a problem with pkg-get or maybe I did not configure apache correctly? I did as before
<zorz_>
never mind i found my way
<ppetrov^>
no, it's a problem with curl
<ppetrov^>
does curl have problems with the "#" in packages name?
<farkuhar>
ppetrov^: It's possible that curl needs some help parsing the url. I'll have to see how exactly that argument list is constructed.
<ppetrov^>
please do. Old pkg-get that uses wget works fine, however it had other issues with runscripts, etc
<farkuhar>
ppetrov^: It looks like the url has any # replaced by %23 before being passed to curl. I thought that was the standard way to encode # in an http request, but maybe curl doesn't need such help and would do the right thing on its own.
<farkuhar>
Try two variants on the command line: one with the original # in the url, and another with %23 instead. Report back whether curl can download the file in each case.
<farkuhar>
Hmm, that's basically how the command is constructed by pkg-get. The only difference is that pkg-get inserts the flags --retry --retry-delay 3.
zorz_ has quit [Quit: leaving]
<farkuhar>
You can edit pkg-get to insert a debug command: sed -e '/my .downloadcmd/a print STDERR "$downloadcmd\\n";' -i~ pkg-get
<farkuhar>
That should show you the exact command that pkg-get is trying to run when downloading the package from your apache server.
<ppetrov^>
sigh... will try
<ppetrov^>
i temporarilly went back to pkg-get 0.4.*, because downloading there worked
<ppetrov^>
also i applied my fix about the post-install stuff
<ppetrov^>
i need to get my work computer ready for Monday, and really am not in the mood to play with that crap
zorz_ has joined #crux-social
<farkuhar>
Hmm, time to install a web server of my own to test the curl invocation. Lately my pkg-get usage has been limited to NFS mounts, which pkg-get treats the same as a local filesystem.
<farkuhar>
zorz_: Where are the stenur ports? I'd rather install lighttpd than play around with apache.
zorz_ has quit [Quit: Lost terminal]
ppetrov^ has quit [Quit: Leaving]
zorz_ has joined #crux-social
<zorz_>
if you change the order in /etc/rc you get no error
<zorz_>
Sat May 3 22:29:18 2025: Mounting / in read-write mode..
<zorz_>
Sat May 3 22:29:18 2025: Found lvm, creating device nodes and lvm volumes
<zorz_>
Sat May 3 22:29:18 2025: Mounting other filesystems (excl. network devices)..
<zorz_>
no more Sat May 3 17:26:23 2025: Starting udev..Found lvm, creating device nodes and lvm volumes File locking initialisation failed.
<farkuhar>
zorz_: That's strange. Does your rc have `/sbin/vgscan --mknodes --ignorelockingfailure`?
<zorz_>
yes
<zorz_>
but it starts to early
<zorz_>
so i changed the order as you can see after the mounting / in read write
<zorz_>
i just added bootlogd and change the order of lvm
ppetrov^ has joined #crux-social
<SiFuh_>
zorz_: The rc is ugly as shit. Hehe, I can't beleive that was even allowed to have been released
<zorz_>
okay.... for the moment we will live with this
<zorz_>
SiFuh_: in ansi.colors why you did not use printf instead of echo ?
<zorz_>
SiFuh_: i changed echo with printf and i added reset
<farkuhar>
zorz_: I pushed an updated ansi.colors within the past hour (flat-text file, parsed by bash rather than sourced). Sync my repo again to see the changes SiFuh and I have been discussing.
<zorz_>
its good idea the /etc/ansi.colors
<farkuhar>
zorz_: So the scan for LVM volume groups has to appear *after* remounting / read-write, and *before* mounting other filesystems? Currently it appears too early in the script?
<zorz_>
yes
<zorz_>
exactly where i place it
<zorz_>
not even need to use this/sbin/vgscan --mknodes --ignorelockingfailure 2>/dev/null
<farkuhar>
zorz_: To be clear, is the `/sbin/vgscan --mknodes` unnecessary for *every user* nowadays, or just for the configuration on your system?
<zorz_>
this is crux
<zorz_>
i never used encrypted volumes
<zorz_>
the lvm is not used by me.
<SiFuh_>
zorz_: Yeah, had to tell farkuhar off that I had no intentions of ever using functions inside of ansi.colors. It was only suppose to be a plain text file
<farkuhar>
zorz_: I'm confused. If you aren't using lvm, then why is your startup affected by where the scan for LVM volume groups appears? What is it trying to do that leads to failure when / is mounted read-only?
<SiFuh_>
farkuhar: Mine is affected too and I have no LVM
<farkuhar>
Hmm, maybe I've been fortunate never to have installed opt/lvm2 then.
<zorz_>
farkuhar: what it does?
<zorz_>
if [ -x /sbin/lvm ]; then
<zorz_>
i have the /sbin/lvm binary
<zorz_>
this does not mean i use lvm
<SiFuh_>
zorz_: I have some ideas. I just was busy setting up a CRUX box today. Kept running out of RAM and swap to build the kernel.
<SiFuh_>
I had to leave IRC for awhile and ignored it because farkuhar kept distracting me. Hahahaha
<zorz_>
hahahaaha
<zorz_>
falken fauker farkuhar
<farkuhar>
Okay, so moving the LVM stuff to appear after remounting / read-write is enough to satisfy people who have lvm2 installed but no logical volumes defined. Would this placement of the code cause problems for people who *do* have LVM volumes defined?
<SiFuh_>
Then SYSLINUX was being a bitch on top. Ended having to format twice and reorder partitions and introduce a boot partition and use syslinux ---install /dev/sda1 instead of extlinux --install /boot/
<farkuhar>
I mean, what if their root partition is inside an LVM volume? Is that why the LVM code was placed so early?
<SiFuh_>
farkuhar: Encrypted root probably
<farkuhar>
Well at least we have an answer to jaeger's question (do the vgscan and vgchange commands not exit gracefully when the user hasn't configured any LVM volume groups?).
<SiFuh_>
farkuhar: It hasn't worked properly since it was introduced. I remember always commenting it out on non-encrypted machines
<zorz_>
Correct — vgscan and vgchange do not exit with an error code if no LVM volume groups are found. They exit successfully (exit code 0) even when:
<zorz_>
No volume groups are defined,
<zorz_>
No physical volumes are present,
<zorz_>
No LVM configuration exists.
<zorz_>
This is intentional behavior, allowing scripts to run LVM commands unconditionally without needing to pre-check for LVM usage.
<zorz_>
chatgpt
<farkuhar>
My concern is that moving the LVM code prematurely, just to silence the error messages for users who have lvm2 installed but not configured, might lead to problems for users who do set up LVM. That code hasn't been moved from its current location, in all the years it's been in the rc.
<SiFuh_>
zorz_: I have yet to find any decent use for Simulated AI
<zorz_>
what to silelnce man... this is not silence... is where is supposed to be
<SiFuh_>
farkuhar: Well, I understood you the first time
<zorz_>
having lvm to early.... maybe not work for some users.
<farkuhar>
zorz_: What ChatGPT appears to be saying, is that the vgscan and vgchange commands *should not* have caused errors on your machine. Who are you going to believe, ChatGPT or your lyin' eyes?
<zorz_>
what i understand.... with my eyes is that... lvm is to early
<zorz_>
that is why initialiasation fail
<zorz_>
Gentoo provides the LVM service to automatically detect and activate the volume groups and logical volumes.
<zorz_>
Gentoo has it way later
<ppetrov^>
farkuhar, there's a linke in pkg-get that should do the %23 substitution. but it does not work
<farkuhar>
zorz_: Okay, fine. The patch we'll propose to the core team will have the lvm code moved to where you suggested. Unless SiFuh_ has any objections?
<farkuhar>
ppetrov^: Thanks for the bug report. I'll get a minimal working example and see what needs to be changed on that line.
<ppetrov^>
please do
<ppetrov^>
line 376, $url =~ s/\#/\%23/;
<ppetrov^>
i guess
<zorz_>
farkuhar: to understand what is going on is
<zorz_>
Even though you're passing --ignorelockingfailure, LVM still tries to initialize its file locking infrastructure, which fails because at this point in the boot process, /var/lock (or /run/lock) and/or /run/lvm might not exist or be writable.
<zorz_>
This is expected during early boot in some setups, especially if root is mounted read-only or /run is not fully populated yet when vgscan runs.
<zorz_>
i boot: ro quiet
<zorz_>
same in shutdown
<zorz_>
in shutdown this needs to move a bit up
<zorz_>
if [ -x /sbin/lvm ]; then /sbin/vgchange --ignorelockingfailure -a n
<zorz_>
fi
<SiFuh_>
farkuhar: I have objections
<farkuhar>
ppetrov^: Here's a minimal working example, https://dpaste.com/33ARQZRG8 ,and the substitution seems to have the desired effect. Maybe the error is caused by a failure to populate the hash table correctly, and $url is not yet initialized when the curl command is being constructed.
<SiFuh_>
farkuhar: Because I told zorz to wait for me to look into it in the next couple of days and it is more priority than his logging.
<ppetrov^>
thanks farkuhar, so how shall I modify pkg-get?
zorz_ has quit [Quit: leaving]
<farkuhar>
SiFuh_: Okay, we won't make any pull requests until you've had a chance to investigate the LVM stuff. As for logging, zorz already added an rc.d service file for his precious bootlogd, so that's taken care of.
<farkuhar>
ppetrov^: I wonder if the error is in pkg-repgen instead. Is it generating PKGREPO with an improper format, and pkg-get has trouble parsing it?
<farkuhar>
Okay, that looks fine. I think I must have changed a function signature somewhere, and the hash table is not getting populated correctly for a remote server.
<farkuhar>
Hmm, try adding the -L flag to the curl command, and see if that succeeds.
<ppetrov^>
nope
<ppetrov^>
i tried
<farkuhar>
Even with the -L flag, and the # replaced by %23, you still get an html file?
<ppetrov^>
if # is replaced, curl works, even without the -L flag
<farkuhar>
Okay, then the curl invocation is okay, it's just a matter of ensuring that the hash table is not being used incorrectly. I think it'll be enough to edit one line within the downloadpkg subroutine.
<ppetrov^>
and po-install scripts execution seems to be also OK
<farkuhar>
ppetrov^: Great! I'll push that in a bit.
<ppetrov^>
thanks
<farkuhar>
SiFuh_: Void's 03-filesystems.sh does not have any vgscan commands. Maybe zorz was right about that command being irrelevant these days.
<farkuhar>
No vgscan in the Alpine scripts, either.
<SiFuh_>
farkuhar: https://dpaste.com/924ZAQJJG.txt Original shit code at the top. Two different codes using vgdisplay to detect if you have any volumes. This is for booting up.
<farkuhar>
Void does put the LVM stuff very early in the script, even before / is remounted read-write. Seems to be a problem with how CRUX is doing things, that the vgscan command is causing errors when / is mounted read-only.
<SiFuh_>
farkuhar: That could be it
farkuhar has quit [Quit: Shutting down.]
zorz_ has joined #crux-social
<SiFuh_>
zorz: try this https://dpaste.com/924ZAQJJG.txt Original shit code at the top. Two different codes using vgdisplay to detect if you have any volumes. This is for booting up.