<cruxbot>
[contrib.git/3.7]: keepassxc: removed old patch file
ppetrov^ has quit [Quit: Leaving]
<ukky>
brian|lfs: what is the output of 'locale' and 'sudo locale' ?
groovy2shoes has quit [Quit: Leaving]
guido_rokepo has quit [Quit: guido_rokepo]
<ukky>
brian|lfs: also, what is the output of: grep 'LC_ALL' $(which pkgmk)
guido_rokepo has joined #crux
<farkuhar>
brian|lfs: interestingly, python3-wheel was one of the few ports that redefined unpack_source() to use gnutar rather than bsdtar, precisely because the pathnames in the tarball were badly handled by bsdtar. See https://crux.nu/gitweb/?p=ports/opt.git;a=blob;f=python3-wheel/Pkgfile;hb=2514e0c6482efca55337e205d35e7d82053532b5 for the last such Pkgfile.
<farkuhar>
this workaround disappeared in the version bump 0.37.1 -> 0.38.2, because by that time CRUX 3.7 was released, with a new procedure for generating locales, and an extra line in pkgmk to export LC_ALL.
<brian|lfs>
interesting
<brian|lfs>
reason I ran into the bug was becuase I'm building building Linux from Scratch multilib and packaging all the base packages and re-writing ports lol
<ukky>
I had a feeling your are using older pkgmk, and that you are not building CRUX
<ukky>
s/your/you are/
<brian|lfs>
its odd because I ran bsdtar without pkgmk and it extracts wheel fine
<ukky>
older pkgmk might be setting LC_ALL=POSIX, and that might be an issue for you
guido_rokepo has quit [Quit: guido_rokepo]
<brian|lfs>
ah ok
<brian|lfs>
I couldn't get the newest pkgutils to compile
<ukky>
it is included in the rootfs on the install ISO
<jaeger>
There's also a copy in /tools/ on the ISO
groovy2shoes has joined #crux
<brian|lfs>
good points
<ukky>
opt@rust#1.68.2-1 fails to install. There are a few dozen of new json files being installed compared to .footprint. All new files are under /usr/lib/rustlib/{i686,x86_64}-unknown-linux-gnu/analysis/ directory
<SiFuh>
ukky: dpaste them
<ukky>
SiFuh: too late, successfully installed via private overlay build. To reproduce, I have to rebuild it again and the error shows as the last step after 45 minutes compile time
<SiFuh>
NEW isn't neccessarily bad
<SiFuh>
In fact, most of the time it is normal
<SiFuh>
Anyway, rust sucks. :-P Hah
<ukky>
I don't mind new json files
<ukky>
The issue is that the whole build process fails, and it takes 45 minutes to build
<SiFuh>
Rust sucks ;-)
<ukky>
clamav pulls it in, so I have no choice
<SiFuh>
I don't use any of that these days
pitill0 has quit [Ping timeout: 250 seconds]
pitillo has quit [Ping timeout: 276 seconds]
pitillo has joined #crux
pitill0 has joined #crux
<farkuhar>
ukky: 45 minutes build time isn't so bad. At least you weren't building qtwebengine with one core (924 minutes as reported by jaeger). But the footprint mismatch wouldn't cause any problems if you just set PKGMK_IGNORE_NEW=yes.
<ukky>
farkuhar: Adding PKGMK_IGNORE_NEW=yes to my notes. I am not efficient in CRUX yet, so I just made a copy of rust port in my local overlay and deleted footprint and signature.
<ukky>
And why jaeger uses only one core to build qtwebengine? Building chromium on single core might be another option to try :-)
<SiFuh>
ukky: we were playing around to see build times on certain machines
<ukky>
SiFuh: I have spent about a month or two doing the same before I settled with my CPU/RAM config. I was rebuilding clang, firefox, libreoffice and chromium with different HW config (3 CPUs, different RAM layout)
<SiFuh>
We were building the kernel (Fully modular), single core on an E5700 mine took 3 hours and 20 minutes
<SiFuh>
Guest5447: took 6 hours and 56 minutes
<ukky>
What was the objective, doing that on single core?
<jaeger>
ukky: that was just a test, definitely not ideal for regular use
<jaeger>
Just a curiosity point, "how long does this take?"
<SiFuh>
jaeger: had the more powerful beast
<ukky>
Have you limited RAM to 2 GiB too? :-)
<SiFuh>
Guest5447 yes, me I was on 4GB
<ukky>
My tests were to find better NumCores/RamPerCore/NumMemChannels ratio
<SiFuh>
We didn't care that. We just wanted to see the actually compilation time
<SiFuh>
Guest5447, though was running in a VM
<jaeger>
VM overhead is likely negligible or within margin of error unless the system was also busy doing other tasks
<SiFuh>
jaeger: I don't really agree though.
<jaeger>
Any workload can be virtualized successfully as long as you treat it properly, in my opinion
SiFuh has quit [Remote host closed the connection]