<farkuhar>
More evidence for zorz's claim "json-c is bullshit": consider the update 0.10 -> 0.11 on 7 April 2013, where jue had to preface the commit msg with "[notify]" because the footprint rearranged /usr/include/json to be a symlink rather than a directory, thereby triggering FS#15 (broken symlink handling in pkgadd).
<farkuhar>
In case anyone missed it, here's how ukky proposed to fix FS#15: https://0x0.st/8bDs.patch
<farkuhar>
There are basically five steps in the pkgadd operation: 1, apply install rules from pkgadd.conf to the list of files in the built package. 2, populate a list of files that conflict with what's on the filesystem. 3, if conflicting files are found and --force is not in effect, make a keep list and remove conflicting files from the pkg database (db_rm_files). 4, uninstall existing package if performing an upgrade (db_rm_pkg).
<farkuhar>
5, db_add_pkg followed by db_commit. Note that in this step the "INSTALL NO" rules in pkgadd.conf are not taken into account. Hence /var/lib/pkg/db might list some files that never made it onto the system.
<farkuhar>
So as I reexamined the various scripts in the prt-utils suite, I noticed a few scripts that didn't consider the possibility of such extraneous entries in /var/lib/pkg/db, and I added the extra logic to filter out those entries.
<farkuhar>
Although it's also possible that a package got installed before the admin wrote any "INSTALL NO" rules in pkgadd.conf, in which case we might not want the filter to be applied. It's a delicate question, whether to respect the configuration as it exists at the time of running, say, pkgexport, or the configuration as it existed when the package was first installed.
<farkuhar>
It would probably be easier in the long run if pkgutil.cc acquired the logic to prevent extraneous entries from appearing in /var/lib/pkg/db in the first place, and then none of the prt-utils scripts would need to worry about whether to apply a filter.
<farkuhar>
Hahaha, I opened ukky's patch https://0x0.st/8bDs.patch in the Microsoft Edge browser, and it asked whether I wanted it translated from Danish to English.
<SiFuh>
Heh
<farkuhar>
stenur copied the crux mailing list on 29 Mar 2024 with his patch for zstd support in pkgutils. I didn't notice until this morning that he slyly inserted what appears to be a complaint about using the insecure http protocol in the source array.
<farkuhar>
Running that command in the core, opt, and contrib repos returned 12, 59, and 52, respectively, at the time when stenur was writing. I suppose he was pushing for more maintainers to use https instead?
<farkuhar>
Anyway, json-c upstream is free to rearrange its footprint between versions 0.10 and 0.11; that's hardly much evidence for zorz's claim "json-c is bullshit". The fact that it triggered the FS#15 bug in pkgutils (symlink handling) speaks to a problem in pkgutils, not to the bullshit that json-c might be.
<farkuhar>
We could try to trigger FS#15 again, by preemptively creating the symlink /usr/man -> /usr/share/man before installing opt/iputils (the version where four new man-pages were added). If jue subsequently updates the footprint to put the man-pages under /usr/share/man, then `pkgadd -u iputils#$version-$release.pkg.tar.?z` might complain about "files already installed".
<farkuhar>
For the sake of completeness, here's the approach I was taking to address FS#15: https://0x0.st/8bRL.patch Still haven't given it enough testing to say how well it handles situations like /usr/man -> /usr/share/man or /usr/include/json -> json-c (not relevant with the latest json-c, anyway).
<farkuhar>
Sometimes stenur's English can be a barrier to understanding what he means, but in this case ("who really does check GPG or whatever signature of upstream when updating a package"?) the most natural conclusion is that he thinks using HTTPS is the least we can do as maintainers, to compensate for users being too lazy to verify with upstream GPG keys.
ppetrov^ has quit [Quit: Leaving]
<SiFuh>
zorz: Looks like farkuhar has stopped spamming the channel with off topic stuff in a social channel ;-)
<farkuhar>
SiFuh: Didn't you say that this channel would become the new #crux, and the old #crux would be limited to receiving cruxbot notifications and questions from newbies (which beerman would answer through cruxbridge)?
<SiFuh>
zorz: :-) he has the power to remove it :-P
<SiFuh>
farkuhar: Not me ;-)
<farkuhar>
Maybe it was remiliascarlet who said it, then.
<SiFuh>
Well it is the most active channel that is for sure.
<zorz>
maybe this channel should be named something unix... linux bsd crux
<zorz>
unixol
<SiFuh>
#crux-farkuhar's-lecturing
<zorz>
hahahahaha
<SiFuh>
#crux-zorz's-shenanigans
<SiFuh>
#crux-remiliascarlet's-ramblings
<SiFuh>
FARTGATE: DOGE Discovers $8 Million In Taxpayer Dollars WASTED On Torturing Cows Because Their Farts Are 'Bad'
<zorz>
only in USA
<zorz>
hahahaahha
<SiFuh>
Netherlands, NZ to name a couple
<zorz>
nz is new zealand
<zorz>
NL is Dutch
<zorz>
aaaaaaaaaa
<zorz>
u mean both?
<SiFuh>
Yes twat
<zorz>
then write NL and NZ.... heh
<zorz>
just a moment
zorz has quit [Quit: leaving]
<SiFuh>
I wonder how long a zorz moment is
zorz has joined #crux-social
<SiFuh>
zorz: You need to learn the definition of 'a moment'
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-social
<farkuhar>
SiFuh: The optical drives are probably not at fault. One of those drives, when plugged into a Mac Mini, has no problem reading the 8-year-old CD-R (although it took a few minutes for the disc to be recognized). It's only on my Linux machines that 'mount' and other commands become unresponsive when trying to access that CD-R.
<SiFuh>
mesg?
<SiFuh>
dmesg?
<farkuhar>
So the most likely explanation is a bug in the mkisofs or genisoimage that I was using back then, or a failure to pass the appropriate command-line option.
<SiFuh>
Doesn't sound right
<zorz>
SiFuh: ahahahahaha
<zorz>
teaching fishing.
<zorz>
farkuhar: ask beerman... the magic bridge will help you