<farkuhar>
I thought it was unnecessarily restrictive to insist on exactly one argument for `prt-get current`, and in my fork I changed the output format, prefacing $version-$release with the name of the port. But then we have Pkgfiles that rely on the old output format (https://git.crux.nu/ports/opt/commit/157a74a48b819dc2db0ab85e6a77473c36d1cf5f) so I should revise my fork to reproduce that output in the one-argument case.
<farkuhar>
The test could also be conducted using llvm_version=$(prt-get printf "%v-%r" --filter=llvm), which would work with prt-get 5.19.6 and my fork too. Given how much beerman likes printf in the rc-scripts, I'm surprised he fell back on `prt-get current` for this purpose.
<farkuhar>
Running CRUX-MUSL this past year spared me from hitting the different outputs of `prt-get current`, because opt/clang and opt/llvm were always masked by my MUSL overlay. Now that the ports in opt are versatile enough to work in CRUX-MUSL, I need to reconcile these subtle differences between prt-get 5.19.6 and my fork.
<zorz>
typescript, with native compiler go... thats why microsoft is microsoft.
zorz has quit [Quit: leaving]
zorz has joined #crux-social
ppetrov^ has joined #crux-social
<farkuhar>
SiFuh: ppetrov^ is here.
<ppetrov^>
SiFuh, farkuhar, zorz: I am here
<zorz>
ppetrov^, farkuhar : I no here!
<SiFuh>
Is that so?
<SiFuh>
According to a report by the New York Post, “Tens of thousands of acres of protected Amazon rainforest are being cleared and paved over to build a new four-lane highway for, of all things, the upcoming United Nations COP30 climate summit in Brazil.”
<farkuhar>
Hmm, contrib/texlive is not one of those ports that gets immediate attention when a new version is tagged upstream. Could be due to the massive download size; no CRUX maintainers are eager to saturate their network trying to grab the full texmf tree.
<zorz>
nice one speaks for forbes, the other one for contrib/texlive
<SiFuh>
I didn't speak. I typed
<farkuhar>
I wonder if it would work to redefine download_source() in the texlive Pkgfile, to use the upstream-provided Perl script install-tl with a trimmed-down subset of the texmf tree. That way the initial bandwidth requirements are reduced, and the user still has the option of running tlmgr later, if more texmf packages are desired.
<SiFuh>
zorz: Do you plan to get a haircut like Giorgio Tsoukalos?
<farkuhar>
Passing a trimmed-down set of packages to install-tl in download_source() was the idea I wanted to pursue, after Arch stopped bundling subsets of the texmf tree into more manageable meta-collections. But lately I've been exploring alternatives to TeX itself, so I haven't followed up on the install-tl idea yet.
<farkuhar>
After I finish rebuilding clang and confirm that it's working on CRUX-MUSL 3.8, I might just shut down the computer and rearrange my home office to take advantage of the changing solar angle. Daylight Saving Time is giving me plenty of late-afternoon sun, but having it at my back might not be the best arrangement.
<farkuhar>
Not that the sun is at my back in the current arrangement. But having the sun in my face a few hours from now should also be avoided. I might want to turn my desk 90 degrees, placing it with the western-facing window on its left.
<farkuhar>
100 more targets to go, before clang finishes building. Let's hope that's the final piece of the toolchain that needs a rebuild on my CRUX-MUSL 3.8 installation.
<farkuhar>
Okay, clang 19.1.7 is built and reinstalled. Comparing the size of the package tarballs (Jan 17 lzip: 506423808, today's zstd: 1105823232), I wonder why zstd compression was such a sought-after feature. It seems to take up more space than lz or xz, but maybe it's more efficient on other metrics.