<farkuhar>
I don't know if the misspelling was intentional, but it is rather appropriate neologism in the context of a fork: "May 2004, Debian starts ... a *diffamation* campaign against cdrtools." https://cdrtools.sourceforge.net/private/linux-dist.html
<farkuhar>
And the ambiguity regarding big-endian or little-endian "last-modified" date at the bottom of that page is cleared up by considering the quoted output of `cdrecord -version`, which is more consistent with a date format of YY/MM/DD (the other possibility, a misconfigured sysclock, is too far-fetched.)
<ukky>
farkuhar: Thanks for the cdrtools story. I will add 'cdrkit' to systemd/udev/pam/pulseaudio/elogind/ifplugd list.
serpente has quit [Remote host closed the connection]
ppetrov^ has joined #crux-social
zorz has quit [Quit: leaving]
<farkuhar>
ukky: The git log for the opt repo includes cdrtools commits spanning 2006-02-23 to 2008-10-14. I don't know if it's the fault of my locale or my terminal font, but between commits ff046742b7 and 9a7df3cb44 the glyph representing the "ss" in Simon Glossner's name switched its character encoding, displaying more reliably in later commits.
serpente has joined #crux-social
<farkuhar>
The date of the last cdrtools commit is also the date when cdrkit appeared in the opt repo. I wonder what was happening around October 2008 that prompted the switch.
<farkuhar>
Someone with a different locale or terminal font might not be able to detect any change in the character encoding that Simon Glossner used for commits ff046742b7 and 9a7df3cb44. I should try a few different settings for LANG and LC_* to see if that fixes the display of his name in the `git log` output.
SiFuh-Radioactiv has joined #crux-social
SiFuh-Radioactiv has quit [Client Quit]
SiFuh-Radioactiv has joined #crux-social
<SiFuh-Radioactiv>
Where is remiliascarlet?
<SiFuh-Radioactiv>
lI am so mad at my wide what the fuck
<SiFuh-Radioactiv>
Wife
<farkuhar>
ukky: The bash FAQ is amusingly hostile to getopt(1) from util-linux, which it says was "... written in the Days of Olde, when shells didn't have arrays, lists were stored in strings, and it was all fine and dandy because filenames didn't have spaces either." https://mywiki.wooledge.org/ComplexOptionParsing#util-linux.27s_special_getopt
<SiFuh-Radioactiv>
She asks me to get the wheel chair and push her mother into the hotel. So I did. Then asks me to bring the suitcases that belong to her entire family. Which I did. My passport is gone. No room key. They all went to dinner without me.
<farkuhar>
Manual option parsing is the recommended approach in the bash FAQ, and most of the scripts that date back to the early days of CRUX were in fact written that way. Only later did you start to see getopts appearing in the argument parsing routines.
SiFuh-Radioactiv has quit [Ping timeout: 240 seconds]
SiFuh-Radioactiv has joined #crux-social
<SiFuh-Radioactiv>
spammer
SiFuh-Radioactiv has quit [Quit: Client closed]
<farkuhar>
I wonder if there was ever a Perl counterpart to today's "Rewrite it in Rust" meme. As soon as a bash script grows beyond 100 lines (25% of which are dedicated to option parsing), the ongoing maintenance becomes too burdensome compared to the equivalent Perl program.
<farkuhar>
It's conceivable to rewrite pkginfo in awk, using fewer than the ~200 lines currently in pkginfo.{h,cc}. But pkginfo itself is already slower than prt-get when it comes to 'list' and 'diff' operations; the gap could be expected to grow even larger with an awk implementation of pkginfo.
<farkuhar>
Somebody should have listened to SiFuh and hosted a read-only copy of the old Flyspray database. In connection with FS#15 (symlink handling), it would be nice to have the original test case, to see if a rewritten pkgadd can handle situations like: a symlink in the old version of a package becoming a regular file in the new version, getting clobbered by a regular file that another package wants to
<farkuhar>
install with pkgadd -f, or similar scenarios.
<farkuhar>
"Rewrite it in Perl" is probably the wrong response to r0ni's rediscovery that pkgmk gives lower priority to command-line options than to /etc/pkgmk.conf. It's easier just to improve the option parsing in the current script.
<farkuhar>
ukky: Is that in all of Simon's commits, or just the ones prior to 2007? Starting with his October 2007 commit to opt/cdrtools, the 'ss' character displays correctly in my terminal.
<ukky>
pkgadd/rm/info should be written in C. 'texlive' port is a good test to see performance, if in doubt, of any language other than C.
<ukky>
farkuhar: Many his commits have proper 'ß', i.e. 55ffab6d8f2b7b5a77b32ac715d71c8c343df42e
<farkuhar>
ukky: I agree on the use of C for performance reasons, but as far as maintainability goes, the symlink handling bugs would probably have been eradicated by now if pkgadd/rm/info were written in a different language.
<farkuhar>
I don't suppose there's a way to extract (just from the git log) the locale and character encoding used for a specific commit. Maybe we'll never know precisely why some of Simon's commits display properly, and others show up with <DF>.
<ukky>
farkuhar: symlink issue should be dealt differently: /var/lib/pkg/db should have real paths instead of symlink paths. And .footpring should reference real paths.
<ukky>
farkuhar: git could have put <DF>, four caracters, instead of single 0xDF byte in the log. Just an idea.
<farkuhar>
ukky: Under that proposal, what would be the footprint generated for your sbin-init-runit port? An empty footprint, because all it does is create a symlink? Or a footprint consisting of /sbin/init-runit (the real path targeted by the symlink)?
<ukky>
farkuhar: symlink like '/sbin/init -> runit-init' are fine in the Crux 'db', and should be owned by single package. But /usb/lib64/libcrypt.so should be converted to /usb/lib/libcrypt.so
<farkuhar>
ukky: Maybe I misunderstood your earlier description. I thought the only purpose of the sbin-init-runit port was to create the symlink /sbin/init, but the actual file /sbin/runit-init is owned by a different port (runit). If that's how you set it up, what is the expected output of `pkginfo -o /sbin/init`?
<farkuhar>
If symlinks are resolved first, and the resulting real path passed to `pkginfo -o`, then you'd expect the same output as `pkginfo -o /sbin/runit-init`. But what if you wanted to know which package installed the symlink? Would there be any way to recover that?
<farkuhar>
ukky: Thanks for clarifying. So your proposal isn't to resolve all symlinks when creating the footprint, only the symlinks that appear in path components before the basename? That way you can still query the db to discover which port owns a symlink. And accidental clobbering (one port stealing ownership of another port's files) is prevented, because comparison takes place between canonical paths.
<ukky>
farkuhar: exactly
<ukky>
and, ideally, symlinks lile '/lib64 -> lib' and '/var/run -> ../run' should be deleted/removed/avoided.
<ukky>
s/lile/like/
<farkuhar>
Regarding the code 0xDF in a git log, if it were really written into the file as four characters <DF>, I wouldn't expect it to be displayed in my terminal with any special adornment. Yet it shows up reverse-highlighted for me.
<ukky>
hexdump has explanation for misterious 0xDF. When 'ß' is displayed properly, git log contains two-byte UTF-8 sequence '0xC3 0x9F'.
<zorz>
farkuhar is using runit ?
<ukky>
zorz: no
<ukky>
farkuhar: in a similar way, /bin/sh should not belong to 'dash' port, nor 'bash' port. A separate ports, bin-sh-dash and bin-sh-bash should be created and user should have a choice to install either of those two.
<zorz>
but dash is not interactive. its only for running no?
<ukky>
zorz: /bin/sh is not supposed to point to interactive shell, but user can select it to point to bash.
<farkuhar>
ukky: If users need to make a choice regarding which symlink-providing port to install, you'd have to insert a new dialog into the CRUX setup where they would be prompted to make that choice. Otherwise they could go through the installation and end up with an unbootable system (with rc scripts written to use /bin/sh).
<farkuhar>
Easily fixed for now, just by hard-coding /bin/dash as the shebang in the rc scripts. But what if dash eventually goes the way that bash did, accumulating so much bloat that it no longer serves the "fast noninteractive scripting" niche? It's more future-proof to use /bin/sh as the shebang.
<ukky>
Scripts should use /bin/sh shebang. But /bin/sh link should not belong to dash port. Crux installed should install bin-sh-dash port by default without giving user a choice. After install user can uninstall bin-sh-dash and install bin-sh-bash if they prefer bash as default.
<ukky>
s/Crux installed/Crux installedr/
<ukky>
s/Crux installed/Crux installer/ ...fsck me
<farkuhar>
How are you invoking hexdump to view the two-byte UTF-8 sequences? `git log bac05111457 | head -n 2 | hexdump -C` does suggest that 0xDF on its own was used for the eszett, without the preceding byte 0xC3.
<ukky>
farkuhar: git log >/tmp/git.log; hexdump -C /tmp/git.log | less <=== Search for 'Simon[[:space:]]' in 'less'
<farkuhar>
Okay, so the one-byte '0xDF' is the one that doesn't display properly in our terminals these days, but the two-byte sequence '0xC3 0x9F' does display the eszett. Are there any locale and terminal settings that allow both representations to display correctly?
<ukky>
farkuhar: definitely you are onto something. Character 'ß' representing 0xDF is displayed properly in 'man iso_8859-1', but it might use two-byte UTF-8 code.
<zorz>
ukky what i know, is they linked /bin/sh to dash so they dont have to change the scripts from #!/bin/sh to #!/bin/dash
<zorz>
my root runs /bin/sh dash
<zorz>
i rarely use it .
<farkuhar>
zorz: Speaking of shells... `export CFLAGS+=" -lz"` is perfectly acceptable in bash, but try that in ksh and the variable won't be updated.
<farkuhar>
Anyway, CFLAGS doesn't seem to be the right variable to export ... For this particular program, "cc" is always called with -lssl -lcrypto -lunwind, but not with -lz no matter what my environment has for $CFLAGS.
<ukky>
zorz: It is stanard practice to specify /bin/sh as shebang. But in that case your script must be POSIX-compiant and do not use any features of a specific shell.
<zorz>
yes i think there is a debian perl sctipt that checks bashisms
<farkuhar>
ukky: `file -z /usr/share/man/man7/iso_8859-1.7.gz` reports that the man-page has UTF-8 encoding, so it's probably not representing the eszett with 0xDF.
ppetrov^^ has quit [Quit: Leaving]
<farkuhar>
Oh, so I needed to export RUSTFLAGS, not CFLAGS? I guess there's a limit to how much detail can be expected from the compiler output, even in a language that has a reputation for super-helpful error messages.
<farkuhar>
The compiler *could* have inspected the environment and gently informed me that RUSTFLAGS was unset, but env vars are not the only mechanism for passing options to rustc, so there was no reason to point me in that direction specifically.
<ukky>
Nah, compilers never inform their environment variables are not being set. One of the tricks is to use some bogus option that would trigger compiler error and if there is no error, then that variable is not being used.
<farkuhar>
ukky: I wonder if Simon decided one day to run `iconv -f ISO-8859-1 -t UTF-8` on his opt/.git/config, and afterwards all his commits got entered with the two-byte sequence representing the eszett. Late 2007 is not unrealistic as the occasion for such a change.
<farkuhar>
Here's another possibility: two separate computers that he used for testing his ports, but with different encodings of opt/.git/config on each machine. Depending on which machine he used to make the commit, the log dutifully recorded either 0xDF or the sequence 0xC3 0x9F.
<ukky>
farkuhar: it seems that .git/config is the only way for a git user to specify encoding for commit user name. And as you point out, he might have used two different systems, with different .git/config encodings, to make his commits at random.
<farkuhar>
But I wonder why `git commit` isn't smart enough to detect a mismatch between the encoding used for the previous log entries, and the encoding of the text being appended? In the event of a mismatch, shouldn't there be some logic for reconciling the different encodings, so that the resulting log is not a hodgepodge of incompatible representations?