<crux-arm-bot>
[ raspberrypi5-arm64/3.8 ]: linux-raspberrypi5: update to kernel 6.12.28
crux-arm-bot has left #crux-arm [#crux-arm]
<r0ni>
does the gitea build new rootfs on a set schedule or are they manually controlled?
<cruxbridge>
<pitillo (@pitillo:crux.nu)> It’s scheduled for tonight
<cruxbridge>
<pitillo (@pitillo:crux.nu)> The runner on the macOS still has some problems
<cruxbridge>
<pitillo (@pitillo:crux.nu)> It just for the containers (really the builder) build
<r0ni>
oh sweet, i tried locally building but always missing sources kill it
<cruxbridge>
<pitillo (@pitillo:crux.nu)> That’s a pain
<r0ni>
i need to keep local source archives, things online go down too often lol
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Sometimes it’s able to get all the sources and sometimes there is one which breaks… usually offline sites which come back later….
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Indeed
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Which kind of build are you running r0ni? Native or dockerized? And for which device?
<r0ni>
native for rpi5
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Great
<r0ni>
basically the envvar OPTIMIZED_DEVICE refuses to set, i had to manually chenge the scripts myself but when it finally started going then couldnt DL libcap-ng sources
<r0ni>
setting the opt dev kept defaulting x86-64
<r0ni>
i thought maybe i should try on a non-crux system but got it going only to find dead sources and didn't have it locally and just didn't feel like scouring mirrors lol
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Do you pass the var before or after the make command? On the native build it should be passed before
<cruxbridge>
<pitillo (@pitillo:crux.nu)> DEVICE_OPTIMIZATION=raspberrypi5 make bootstrap
<cruxbridge>
<pitillo (@pitillo:crux.nu)> The var name passed is right btw?
<r0ni>
yeah tried both and exporting i think, dunno i'll have to try again, it was late and i hadn't slept in 2 days heh
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Too much time without sleeping, that’s insane;€/€/):)/&
<r0ni>
quite possibly true, got some sleep now tho, now that my schedules all messed up anyway lol
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Don’t touch any that that state… just rest and you’ll be ready later
<beerman>
yo
<beerman>
the action actually caches sources for that reason
<beerman>
but its not running successfully until the m4 builder is running stable
<beerman>
but in general, it _should_ work for anybody locally
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm64/3.8 ]: ruby: update to 3.4.4
<r0ni>
i'm trying a fresh pull right now... i'll let ya'll know how it goes for me
<r0ni>
pkgmk failed for libgmp and then a bunch of can't find stage0 errors before it finally gives up
<cruxbridge>
<pitillo (@pitillo:crux.nu)> can you share the command line?
<beerman>
you can also sideload the source if you got it somewhere else
<beerman>
otherwise I am sure we can help you out here
<r0ni>
it downloads and builds just fine from my installed system.... maybe just a network hiccup
<beerman>
yeah
<beerman>
some of these sources seem flaky like that
<r0ni>
oh i see it's still trying to build x86
<pitillo>
yes, a libgmp error smells to that
<r0ni>
i have to be spelling optimizied or raspberrypi wrong
<pitillo>
that's why I asked you the command line used :D
<r0ni>
it's literally the only words i could mess up lol
<pitillo>
DEVICE_OPTIMIZATION=raspberrypi5 make bootstrap
<pitillo>
that should take the device optimization and then, use its ports overlays
<r0ni>
i see the docs say OPTIMIZED_DEVICE but the common.mk say DEVICE_OPTIMIZATION
<r0ni>
bork bork bork
<pitillo>
let me check the docs... I've changed all those wrong vars
<pitillo>
are you checking 3.8 docs or another branch?
* r0ni
is not crazy lol
<pitillo>
jaajajjaa
<pitillo>
yeah
<r0ni>
just whats on the main url
<beerman>
lmao
<beerman>
good one :D
<pitillo>
you are right....
<r0ni>
crux.nu/sysstem/crux-rootfs url
<pitillo>
fixing them atm
<r0ni>
was beginning to think it was designed to spite me
<r0ni>
it's pulling arm ports now!
<pitillo>
nah, it works like a charm for both arches, X86_64 and ARM.... it's a really interesting builder for those who like to make tests....
<pitillo>
I've changed the documentation (I though I have changed it... but may be I didn't commit on that time... or it's commited in the wrong branch.... no idea)
<pitillo>
anyways, thank you so much r0ni|~|~@|@|#@
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm64/3.8 ]: libcamera: update to 0.5.0
crux-arm-bot has left #crux-arm [#crux-arm]
<r0ni>
i feel like the term color seting in rc.conf is messing it up
<r0ni>
the logs are a mess
<r0ni>
anyway, it still fails, i made a few logs before i realized it is logging itself
<r0ni>
arm64fail = dev_opt arm64 | rootfsfail = rpi5 log and the others it makes
<cruxbridge>
<pitillo (@pitillo:crux.nu)> python not installed on the host? or may be the problem is that libcap-ng is still trying to use python instead of python3
<cruxbridge>
<pitillo (@pitillo:crux.nu)> the problem is libcap-ng:
<cruxbridge>
make[7]: Nothing to be done for 'install-data-am'.
<r0ni>
it wouldn't build python, but python is installed but i've had numberous issues with python even when i started the 3.8 branch initially. this install was built with one of those very rootfs images on that site
<cruxbridge>
<pitillo (@pitillo:crux.nu)> I think the problem is that there isn't a python link to python3
<r0ni>
hrmm ill make a symlink then and see
<cruxbridge>
<pitillo (@pitillo:crux.nu)> it will probably go ahead then
<r0ni>
it sure is!
<beerman>
this is not inside a container? e.g. with tools/dockerize.sh?
<r0ni>
btw the cpu_graph xfce-panel plugin gives me much satisfaction to watch while compiling things. it was fake LED lights and its just great heh
<beerman>
heh
<cruxbridge>
<pitillo (@pitillo:crux.nu)> great
<cruxbridge>
<pitillo (@pitillo:crux.nu)> I think that could be something to think about for CRUX, as there is still some software which call python instead of python3....
<cruxbridge>
<pitillo (@pitillo:crux.nu)> not sure if that can create compatibility problems in any way
<r0ni>
well iirc it should be a link to the system default python install, so maybe the port should be doing that?
<beerman>
it's something I was thinking about lately too, yeah
<beerman>
r0ni: the dockerize.sh question was for you
<beerman>
this should be a safe way to successfully build the rootfs
<cruxbridge>
<pitillo (@pitillo:crux.nu)> it can be though and may be sorted on python ports (if there is still python too and not only python3)
<cruxbridge>
<pitillo (@pitillo:crux.nu)> yeah r0ni, the dockerize.sh version is a good one for the M4
<r0ni>
beerman: oh no container, just on my VM install
<r0ni>
i basically have a mac, vmware and a giant vm using 80% of the system resources, and I work in there ;)
<cruxbridge>
<pitillo (@pitillo:crux.nu)> VM on the macOS?
<r0ni>
yes
<cruxbridge>
<pitillo (@pitillo:crux.nu)> interesting.... I'm using it with podman/docker and builder containers and the runner
<beerman>
these apples are powerful but these oddities around them...
<cruxbridge>
<pitillo (@pitillo:crux.nu)> oddities created by crazy/dumb users really xD
<r0ni>
TBH i can have a 8core/16gb ram VM which is more powerful than any arm64 thing I have outside of the Mac, i see no real reason to use docker when I can completely live inside a crux system and still have spare resources
<cruxbridge>
<pitillo (@pitillo:crux.nu)> yeah, that's fine too. Are you running it on the internal storage or do you have any kind of external storage for it?
<beerman>
thats just how we developed it.. I have no idea what needs to be done to reliably work with the setup you are trying it on :^
<cruxbridge>
<pitillo (@pitillo:crux.nu)> I think a native build will work very well on that setup... it's a native CRUX-ARM VM running on a beast, so it's fine too
<beerman>
it should be, yet we are talking about why it wouldn't
<cruxbridge>
<pitillo (@pitillo:crux.nu)> it's a rock solid builder
<cruxbridge>
<pitillo (@pitillo:crux.nu)> you know
<beerman>
yeah, obviously :P
<cruxbridge>
<pitillo (@pitillo:crux.nu)> yeah
<r0ni>
pitillo i have 2tb external storage but this particualr vm is on internal because i've found the ssd will not stick to my case and I get up and ssd falls out, unplugging and killing whatever vm i'm working in. if its internal drive-- i won't drop it lol
<cruxbridge>
<pitillo (@pitillo:crux.nu)> I know about that…. I’ve done a user’s home migration to a external nvme and got the same behaviour…. Now I want to give a try to a external SSD ….
<r0ni>
the speeds I get seem to be fast enough that i don't notice its an external drive, even in VM systems
<r0ni>
i've one of the samsung T7 drives
<r0ni>
have one on my M1 system as well been using since i bought the m1 and its proved to be a valuable bit of extra storage without fail
<beerman>
ok, I dunno, I don't have one of those toys :) It's just from the problems pitillo is having that it seems very specific chipsets that just work better than others on the m4 mini
<cruxbridge>
<pitillo (@pitillo:crux.nu)> Yeah, here I’ve done some benchmarks on an old device and it was running at 1.5GB/s….. good enough… now the SSD IS 400MB/s which could be enough too for builds
<r0ni>
the only downside to this macbook air is fanless which is fine for normal people, but i'm building mass amounts of software, and this gets hot with no real way to cool it
<beerman>
dump it in the freezer
<r0ni>
I have been known to put ice packs under laptops ;)
<r0ni>
they say the cpu throttles down to keep cool, but if this is throttling heat, maybe it shold throttle more lol
<beerman>
heh
<cruxbridge>
<pitillo (@pitillo:crux.nu)> The Mac mini has a good fan and it runs only once per build (sometimes I can hear it when I’m rebuilding big beasts)
<cruxbridge>
<pitillo (@pitillo:crux.nu)> My brother in law just printed me a support to get a better air flow and put the external storage case there too
<beerman>
nice!
<r0ni>
yeah i need to get some kind of laptop stand to increase air flow
<cruxbridge>
<pitillo (@pitillo:crux.nu)> That will help for sure too
<beerman>
the apple stand, only $499
<beerman>
;D
<r0ni>
heh they sell a stnad for something that is insanely prices, so you're not far off lol
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ xorg-arm64/3.8 ]: mesa: update to 25.0.6
crux-arm-bot has left #crux-arm [#crux-arm]
<pitillo>
xDDD
<beerman>
should really be the hand of adam holding it up or something :p
<beerman>
the apple that drives you out of paradise
<pitillo>
finishing a 3.7 container build (sysup atm) and I'll put hands on the user's home movement to the external SSD.... second part of the history.....
<pitillo>
beerman: I have pending another one.... I want to use a Ubuntu container (the one I've used to debug the Overlayfs stuff) to make some tests/builds nativelly with crux-rootfs on it...
<beerman>
good luck!
<pitillo>
we'll see.... I need to setup to get the runner ready for tonight build.... but it will break on the container-builder step... if we don't force vfs I think I'm furk3d
<r0ni>
ok libmd links to lz4 and this thing is failing... whys it always do that, I always have to enable contrib and get lz4 before things work on my installs. it sure feels like lz4 needs to be elsewhere
<cruxbridge>
<pitillo (@pitillo:crux.nu)> stage0 build I feel
<r0ni>
hrmmm i'll just remove lz4 and rebuild libmd maybe it'll work
<pitillo>
it's trying to link with host's stuff, so that should affect if it's there or if something needed it's linked with lz4
<r0ni>
even removing the pkg don't fix it, i'm sure its ingrained into the system by now, ive never got a crux system working without lz4 being installed tho, always fails lol
<beerman>
but exactly the reason why the dockerized build might be the better approach here..
<beerman>
i know i had that problem before but i am not sure what was the problem anymore
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm/3.8 ]: ruby: update to 3.4.4
crux-arm-bot has left #crux-arm [#crux-arm]
<cruxbridge>
<pitillo (@pitillo:crux.nu)> something important has been linked to it so it carries everywhere
<cruxbridge>
<pitillo (@pitillo:crux.nu)> looking at /usr/lib to check what is linked with it and try to debug it is the only thing I can think to get the root cause
<beerman>
yeah
<beerman>
indeed
<r0ni>
nothing even appears linked to it, i dunno
<r0ni>
libc probably heh
<beerman>
libarchive
<beerman>
its what my system links liblz4.so, among others (mariadb, wireshark)
<beerman>
for f in $(/usr/bin/grep -lr "liblz4.so" /usr/lib/ 2> /dev/null | sed 's|._/||');
<beerman>
do prt-get fsearch $f | /usr/bin/grep '^Found in' | sed -e 's|._/||' -e 's|:$||';
<pitillo>
can you check what's linked with libarchive (libarchive.so) beerman ?
<beerman>
next to everything I suppose
<pitillo>
it smells to that
<beerman>
well, ok, no, not so much
<pitillo>
libc links with it?
<beerman>
but from out of core: perl
<beerman>
no
<pitillo>
interesting
<r0ni>
it spit out "prt-cache isinst takes at least 1 argument"
<beerman>
that means it found nothing to display
<beerman>
the xargs prt-cache isinst is not getting anything
<r0ni>
yeah, so i dunno. I'll have to come back to it, gotta get off here and get to bed, work later... if all else fails, i'll ship lz4 with my rootfs lol
<cruxbridge>
<pitillo (@pitillo:crux.nu)> have a good one r0ni
<beerman>
gn8
<cruxbridge>
<jloc0> Just a thought, but what if lz4 is required by something but only req on arm platforms, cuz I always come across this issue. Of course it could just be all my systems have fallen prey to it being installed, but there could be something to that…
<beerman>
not impossible, but hopefully not exactly the case here
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm/3.8 ]: python3-cython: update to 3.1.0
crux-arm-bot has left #crux-arm [#crux-arm]
<pitillo>
may be we can check any of the builds and see if there is something linked with lz4
<pitillo>
but I doubt it
<cruxbridge>
<jloc0> Yeah thinking the rootfs would also fall prey to that, not just me lol
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm/3.8 ]: python3-pyyaml: synced with upstream release
crux-arm-bot has left #crux-arm [#crux-arm]
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm/3.8 ]: gobject-introspection: update to 1.84.0
crux-arm-bot has left #crux-arm [#crux-arm]
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ opt-arm/3.8 ]: nss: update to 3.111