<cruxbot>
[opt.git/3.6]: libunbound: update to 1.14.0
groovy2shoes has joined #crux
GazL has joined #crux
<GazL>
Hey folks.
<GazL>
I'm trying to build 'wine' but the pkgbuild just blew because it exceeded my 4GB PKGMK_WORK_DIR. Anyone know how much space this thing needs to build?
ocb has quit [Remote host closed the connection]
ocb has joined #crux
<braewoods>
GazL: realistically you should allocate more space
<braewoods>
20GB+ is recommended
<braewoods>
how much gets used varies
<GazL>
Braewoods: thanks. Is that a definate? I've got 11GB free that I'm trying with now. Should I give up
<GazL>
... on this run now
<GazL>
just passed 5.1GB used.
<stenur>
With my 8gb ram also used as TMPDIR it does not work, clang and gcc i think blow it, but i thought not much is missing
<GazL>
I had workdir in tmpfs. I have 8GB ram. I've unmounted that now and letting it go do disk, but my rootfs only has 11GB free.
<GazL>
it just finished. Phew. It peaked at 5.4GB
<GazL>
That's a relief.
<braewoods>
GazL: that's still too little for me to recommend in practice. source based distributions need a lot more free space.
<braewoods>
technically there's no definite rule as it's always increasing with the size of software
<GazL>
Yes, I'm ok with the rootfs, I can side that appropriately for what I install, it's just that I wasn't sure how big the pkgmk workdir needs to be for some of these bigger builds.
<GazL>
I normally have it in tmpfs, but with only 8GB ram I can't get carried away
<braewoods>
... why? that takes away from RAM that could be used by the compiler.
<braewoods>
i tell you from experience, having the files in RAM makes little difference to compile jobs. especially with modern SSDs.
<GazL>
it's recommended in the crux handbook on the page related to speeding up builds
<GazL>
also cuts down on wear and tear on the hard disk
<braewoods>
that sounds like outdated advice. i've been compiling for years and don't do that.
<braewoods>
you know what really makes a difference?
<braewoods>
more processor cores and more RAM to support more parallel workers
<GazL>
... delayed write and vfs cache make me question that also. Perhaps I'll just not bother in future.
<braewoods>
best to just let the kernel deal with that shit
<braewoods>
RAM caching pretty much makes it moot
<GazL>
Yes, I don't disagree. I was just going with what was in the book as I was building a lot of stuff to get wine up and running.
<braewoods>
upgrading to an SSD would also help but i just did an nvme upgrade and barely noticed anything over my support to 8 cores from 4
<GazL>
Like you said though, possibly out of date advice.
<braewoods>
upgrade
<braewoods>
the worst part of build jobs is the archive compression
<braewoods>
it's always slow due to being single core
<braewoods>
there's ways to make it parallel to a degree but crux doesn't support it
<braewoods>
you sacrifice some compression % to make it work
<stenur>
Does TAR_WRITER_OPTIONS="xz:threads=${JOBS}" in pkgmk.conf no longer work?
<braewoods>
it probably does stenur but my point still stands that there's no general solution to the issue in pkgmk
<braewoods>
ideally there'd be a solution for each of the supported compressors
<braewoods>
last time i recall it being proposed it was rejected
<stenur>
libarchive is sometimes odd
<braewoods>
it's less of an issue on the decompression side
<stenur>
pkgmk could wrap it of course, causing correct libarchive settings, then.
<braewoods>
that's usually fast enough that parallel isn't worth the trouble
_moth_ has quit [Remote host closed the connection]
<stenur>
Last time i looked libarchive did not support parallelism for zstd
<stenur>
For the others: it is not a bug, it just does what it has been told, "it works exactly as has been specified"
<stenur>
ogAppenderFactorySingleton, das XML liest, um den Namen der Klasse zu bekommen, die es instanziieren muss, damit ich meine Logzeile da einwerfen kann, um sie asynchron an einen LogStream anzuhängen?
<stenur>
"Why do i need XML reading LogAppenderFactorySingleton to get the name of a class to be instantiated in order to print a line of log, asynchronous to a LogStream?"
<stenur>
Man!
<stenur>
Like said in 2003, "Logging for the Lazy"
<stenur>
Final article conclusion (haven't read their articles for many years!): Code. Ist. Nicht. Dein. Freund. -> Code. Is. Not. Your. Friend.