<farkuhar>
opt commit c320bee1e5d8cd7dceb3e8dae175a36e18eb9b2d altered the footprint of python3-flit-core, in a way that might trigger the pkgadd error "Could not remove /usr/lib/python3/ : not a directory" (when upgrading).
<farkuhar>
Strangely, I cannot find any other python3 port in the CRUX 3.8 branches that populates /usr/lib/python3/ instead of /usr/lib/python3.12/; something is weird about python3-flit-core and its build process when avoiding pip3.
<farkuhar>
The "not a directory" pkgadd error was actually the original motivation for FS#15 (pkgadd symlink handling). If I recall correctly, the issue back then was a port installing its files into a symlink under /var, rather than the canonical path.
<farkuhar>
beerman opened this task https://github.com/Libvisual/libvisual/issues/300 about two years ago, and fixed it by adding autoconf-archive to the dependency list. Lately I've encountered something similar, but on one machine the pkgmk process cheerfully ignored the exit status of ./configure and proceeded to run `make` with no Makefile!
<farkuhar>
Manually running each command under build(), I hit the same error with ./configure, and then asked my shell for the exit status of that command. Of course it was non-zero. Strange that on this machine, `set -e -x` was not enough to stop pkgmk from proceeding to the make command.
zorz has joined #crux-social
<farkuhar>
SiFuh: zorz is here!
<farkuhar>
One feature unique to the python3-flit-core Pkgfile is its use of bootstrap_install.py (no other python3 port in the CRUX 3.8 branches uses such a script). Maybe that would account for the different directory appearing in its footprint.
<farkuhar>
This line might be where the bootstrap_install.py is determining "/usr/lib/python3/" instead of "/usr/lib/python3.12/", but I'll leave it to a python expert like zorz to confirm. line 32: purelib = Path(sysconfig.get_path('purelib')).resolve()
<farkuhar>
Perhaps a safer approach is the one taken by ukky's python3-flit-core: run `/usr/bin/python3 build_dists.py` in the flit_core subdirectory rather than bootstrap_install.py
<farkuhar>
Hmm, it would introduce a circular dependency to use ukky's python3-flit-core (with the final line /usr/bin/python3 -m installer ...), now that beerman has revised python3-installer to depend on python3-flit-core.
<zorz>
wait i show you 2 templates that i have now
<farkuhar>
It could be as simple as passing --installdir $PKG/usr/lib/python3.12/site-packages to the bootstrap_install.py script. Either that, or fix FS#15 so that symlinks are handled properly, and pkgadd doesn't complain about /usr/lib/python3/ "not a directory" when upgrading python3-flit-core.
<zorz>
srcpkgs/python3-flit_core-bootstrap/template and srcpkgs/python3-flit_core/template why they have 2?
<ukky>
farkuhar: Python-3.12 in crux-amd64-3.8 is a mess and does not let you to upgrade from 3.10 to 3.12. And it does not let you install 3.12 from scratch. My changes for musl let you do both operations.
<zorz>
why dont you go direct to python3.13?
<farkuhar>
ukky: Why didn't you change the maintainer line in your muslcrux38 repo? No need to give beerman any credit for the fixes you made.
<ukky>
zorz: I could, but that would be a bigger deviation from amd64-3.8, with greater risk to require new (potential) python dependencies.
<ukky>
farkuhar: I don't like to take credit for any work I do. Plus, I do not want to maintain this overlay, as I am in a process of leaving Linux for good.
<farkuhar>
ukky: I hope whichever OS you migrate to will be as receptive to your patches and contributions as CRUX-MUSL has been. And also, may you not be plagued by a messy python3 ecosystem in your new OS of choice (NetBSD?).
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-social
<ppetrov^^>
will the new CRUX release include *.la files?
<ukky>
farkuhar: yes, it is NetBSD. I'm still stuck with Linux at work as I need to run some binary SDK that only available for Linux and Windows, though I will test whether that SW can run under NetBSD' Linux emulation.
<ukky>
ppetrov^^: for musl-3.8, yes. Removing all *.la files would require extra work and it was not in the initial objective. But this could be done, leaving only a few ports that require *.la to build properly.
<ppetrov^^>
are there any ports that require *.la files?
<ppetrov^^>
Slackware removed them from /lib and /usr/lib, leaving the package "specific" ones intact
<ukky>
ppetrov^^: Yes, but I don't recollect them all. Probably imagemagick.
<farkuhar>
Okay, I've tagged beerman in #crux-devel, so he'll be aware of at least one place to start cleaning up the python3.12 mess in CRUX-amd64-3.8.
<ukky>
remiliascarlet: one of my server systems gets really hot to the touch. I probably need to downgrage it to CPU with lower TDP. Currently it uses 130W CPU. Maybe fault in system design.
<zorz>
farkuhar: i need to setup a server, where is the 3.8 iso to try ?
* farkuhar
is AFK, somebody else will have to keep zorz happy
<zorz>
SiFuh: why musl? does this thing will update easily? support for wiregurd?
<zorz>
i will give it a try
<farkuhar>
zorz: why did 0x0.st blacklist my IP address? I fell back on uguu.se because I had a shell function for it, but I had forgotten that the default expiry time is so short.
<zorz>
farkuhar: how you managed to get banned???
<zorz>
farkuhar: you need special talent to get banned in 0x0.st
<farkuhar>
zorz: It might have been only temporary, as a response to someone else with the same ISP making too many requests. In this channel I only know of dlcusa who has the same ISP, so an ISP-wide ban might take a while to get noticed here.
<ukky>
farkuhar: what is the curl response from 0x0.st?
<farkuhar>
ukky: "Your network (2600:4000::/24) is blocked from uploading files."