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/
<beerman> pitillo: heyo, is there any specific state that 3.7 is in on arm? I might be able to start working on the pi4 soon and make that a build host for the pinephone (hopefully). maybe I can help with outstanding tasks?
<pitillo> hey beerman, we have changed the way we were building "releases"
<pitillo> currently we are on the way with both arch (arm and arm64) getting a collection of stage1 generic packages
<pitillo> soon we'll share an RC1 generic rootfs just for jailing and looking for problems in different devices
<pitillo> if there is no problem, that RC1 will the release and it will be ready for all to start with optimizations
<pitillo> on the aim.....we have odroidxu4 and rpi3 as the main ones.... we want to try to get some old supported devices as far as they can be to 3.7 (probably locking toolchain ports not suported on these devices, like efikamx smarttop and samsung chromebook)
<pitillo> currently I'm with gcc, which takes 56h to build natively on the rpi3... which is really odd as the odroidxu4 takes a few hours....
<jaeger> It has twice the cores and RAM, right?
<jaeger> I have an efika mx smartbook somewhere, I wonder if that thing could be revived
<jaeger> I remember reading that getting modern kernels working on it was problematic due to usb device drivers or something
<jaeger> Pretty old at this point but I still like its design
<beerman> ah cool :) guess i will hold my horses and wait for the RC1 then
<pitillo> jaeger: yes, if I remember right, there were a 3.2 (or 3.x) development for the smarttop without many support (some DMA problems, so no usb, no wifi, no video...) but may be we can hold some ports (glibc specially) to try with the old 2.6 kernel
<pitillo> yes, 4 cores vs 8 cores with same ram... I see 56h too much anyways
<pitillo> beerman: will you put 32b or 64b on the rpi4?
<beerman> 64bit
<pitillo> ok, so if no one put hands on rpi4 32b, we'll remove not used repos
<beerman> yeah I guess that would be for the best, sorry. I am not even sure if 32bit on rpi4 still has the better video driver, I will be able to say that after I get to it
<jaeger> I can do 32bit on mine if you want it
<beerman> i mean, if there is no benefit in running a 32bit system on it why bother? maybe you can already answer the state of the gpu driver on 64 bit
<beerman> last time i checked is 2 years ago and it wasn't able to do proper video playback
<pitillo> no idea about the reason to have a 32b... I thought in what beerman said, any specific 32b blob or requirement...
<pitillo> if there is no benefit, I wouldn't go to 32b version
<beerman> ah that was directed at jaeger :)
<pitillo> yeah, but if any feels that a 32b could be interesting... go ahead
<jaeger> Yeah, I personally have no need for 32b, was just offering in case you wanted it done
<pitillo> I don't see any point to have it at 32b, but I haven't an rpi4 :D
<jaeger> I do recall 64b NOT having good GPU support but yes, that was at least a couple years ago and I don't know what it's current status is
<jaeger> OK, fair enough
<jaeger> s/it's/its/
<pitillo> it could be a good research just to be sure
<pitillo> btw, probably not many users, and most of them will not be looking for 32b distro...
<pitillo> btw, making a 32b optimization for it shouldn't be hard if all things go as expected with the new release procedure (we'll be able to start from a generic relase and give the option to anyone to bootstrap any build (32b/64 generic/optimized)
<jaeger> ok