jaeger changed the topic of #crux-arm to: CRUX-ARM 3.6 Released! - http://crux-arm.nu/Documentation/ReleaseNotes3-6 | Logs: https://libera.irclog.whitequark.org/crux-arm/
<pitillo> morning
<pitillo> beerman: I've seen the PR. I need some timento finish gcc build to check and merge them
<beerman> ☕️
<beerman> I will try and do some other things with mesa after work
<beerman> I might need input on which gallium targets i can drop again, because these are substantially more than what we had before
<r0ni> i'm currently updating my pkg repo with all the latest stuff
<r0ni> my pinebook really dislikes upgrading large packages
<r0ni> might be time to consider a new sd card, as no doubt i've tortured this one
<beerman> on another note: it looks like I finally got myself a working rust wasm toolchain
<beerman> my confusion stemmed from me trying to build a Pkgfile for zjstatus to test my port on. And my prefered way of writing a rust port didn't work, because it deploys a custom cargo config file making that an explicit wasm32-wasi target. calling cargo directly with that target didn't work for some reason, it looks like it doesn't change the linker which needs to be lld because ld won't understand what to do
<beerman> this feels so stupid
<beerman> cd $name-$version && cargo build --release just works
<beerman> while cargo build --release --manifest-path=$name-$version/Cargo.toml doesn't work
<beerman> fml
<pitillo> sorry, but that sounds like chinesse for me... the best part is that you got it working :D
<beerman> xD
<beerman> https://dpaste.com/3U3L7V88V <- i talk about that, to be used with e.g. https://github.com/dj95/zjstatus
<beerman> zellij can be the cooler screen/tmux replacement as it looks :) they integrate a plugin system, but for some freakish reason its wasm32-wasi, thats a web assembly build target, not x86_64 or aarch64 but wasm32-wasi
<beerman> i have no idea man this is a strange time we live in
<beerman> i am just rolling with it
<pitillo> too fast or I'm too slow... I feel I'm getting older by seconds reading you xD
<beerman> hahaha its not important
<beerman> sorry :D
<beerman> i will need a new aarch64 kernel first before really testing that mesa update
<pitillo> it's interesting... always learning a bit
<beerman> jaeger any chance you have something up2date flying around for the pi4?
<pitillo> that should be fast to build nativelly
<beerman> fast?
<pitillo> should't it?
<beerman> if you do the full bloated default raspbian kernel or something it takes a while
<pitillo> 8 jobs on that toy... probably it should be a half hour build....
<pitillo> don't you have a minimal config for it?
<beerman> i have no idea if that bug stems from the kernel i run or the wayland stack on vc4 driver or whatever, there is no obvious error why my resolution crashes
<pitillo> are you currently running a bloated one?
<beerman> i have a non bloated one but it maybe unbloated a bit too much? :D
<pitillo> jaajajajajaja
<pitillo> take the .config and do a fast check, at least for what you want/need
<pitillo> if it's booting... that will avoid you some time
<beerman> yeah its booting
<beerman> just the resolution is foobared
<pitillo> no log overthere?
<beerman> looked at logs, no clues :D
<beerman> see, it worked before when i was setting it up
<beerman> one monitor hooked up for the initial setup and then i moved it and connected two monitors (because, why not? It's free real estate)
<beerman> and since then its fucked
<beerman> so i have a strong feeling its fucked because of the dual head setup, but i have never verified that :D
<beerman> nothing in any log imaginable
<jaeger> Nothing recent... I can plug it in and look but it's undoubtedly quite out-of-date
<pitillo> really strange
<pitillo> btw
<pitillo> have you booted with the monitor connected?
<beerman> yeah both connected and turned on makes no difference
<pitillo> sometimes devices do strange things when you disconnect/connect them
<beerman> i should just unplug one and see what it looks like then
<beerman> but its in a... hard to reach spot
<pitillo> and only one monitor plugged in when booting?
<beerman> i hate fiddling with it :D
<pitillo> I know the feeling
<beerman> i'll do it, later, maybe tomorrow, ok?
<beerman> :D
<pitillo> sounds fine xD
<beerman> great :D I might just compile a new, more bloated kernel again
<pitillo> jaajajajaja
<pitillo> just take one bloated one for testing, don't build that kind of sheet
<beerman> xD
<pitillo> I'm trying to remember things I've found.... may be something related to a specific boot loader option?
<pitillo> I remember the rpi3 had some options at boot level to handle hdmi output (video/sound)
<beerman> mh, maybe
<beerman> look what i found
<beerman> the tim in the past left a note
<pitillo> tim in the past has spoken xD
<beerman> xD i am building a defconfig
<beerman> i was on 6.1.29-v8+ from somewhen, probably in january or so
<beerman> 6.1.54-v8+ its building that now, lets se
<beerman> e
sajcho has joined #crux-arm
<beerman> Everything finished fine 2h:22m:28s
sajcho has quit [Quit: Client closed]
<beerman> The kernel is borked, it enables gzipped modules by default which our kmod doesn't read
<jaeger> Maybe we should just enable compression in kmod... is there any good reason not to?