<pitillo>
give a try to go... compiler-rt sucks, but go, if I remeber right, was a real pain (the samsung chromebook wasn't able to build it)
<pitillo>
ohhhhhh
<pitillo>
that's very interesting
<pitillo>
expensive? I was looking for a riscv cheap board to bring back the toolchain repo and adapt it for cross building a busybox for riscv
<beerman>
this was 8€ not including tax and postal fees
<beerman>
~14€ a unit i'd say
<pitillo>
but we have too many fronts... and not enought time to do all we'd like to do
<pitillo>
wow, cheap one then, sounds interesting
<beerman>
and a very interesting feature set
<beerman>
i started building go on the pi, lets see if that finishes
<beerman>
finished fine
<pitillo>
too fast
<pitillo>
may be I'm confused and it was rust and it wasn't go...
<pitillo>
let's see if I can verify
<pitillo>
may be clang... I can't check the chromebook atm
<beerman>
clang swapped around a bit
<beerman>
i'm almost done installing sway, but can't test right now
<pitillo>
interesting
<pitillo>
I remember that such big port was related to enlightenment... but I don't remember exactly which one was
<pitillo>
probably clang, which is anotherpbeast (the Ãp±ort was dependet on rt-compiler and a overlay was needed)
<jaeger>
Any more testing you need done for crux-arm-release since the last chat about it?
<pitillo>
I've built the last RC with those changes jaeger, but I haven't had time to test that RC
<pitillo>
I've done a bit more research about the DEVICE_OPTIMIZATION "option" because the export made by sepen wasn't working right here (optimizing for arm64). I'm not sure if I'm doing something wrong or if really the exported option isn't passing right to the sub make commands
<pitillo>
if you can, want and you have time, you can give a try to another RC for the rpi4 with these lasts ports bumps (if you want to try passing DEVICE_OPTIMIZATION instead of changing the Makefile... could be a good option too, but probably it will stop on stage1)
<jaeger>
ok
<pitillo>
I need to look for a time window to make a call/meeting with sepen to check current status and I'd like to speak with him about you too, because I'd like to see you inside the project (at github and any other level) not only as contributor
<jaeger>
I'm not sure that I'm qualified for arm things much, heh, but appreciate the vote of confidence
<pitillo>
your CRUX knowledge, your work in CRUX-ARM... is not just work from a contributor. We know you for some years, we know how you work, how you "think" and the mood you have for debate
<pitillo>
probably you are more qualified than me in a lot of senses... ARM is another arch, at least for our position (we don't do assembler programing nor kernel/compiler development...)
<jaeger>
ok, I've started up the build container again, just want me to test the rpi4 RC passing optimization instead of exporting, right?
<jaeger>
I'm starting with a fresh clone
<pitillo>
yes, passing option instead of changing it directly in the Makefile
<jaeger>
ok, I'll get it started. Easy to start and then let it go while I work :)
<pitillo>
like I said, if I'm right, it will stop on stage1, then you can confirm.... if it breaks, then you can do some tweaks (prt-get.conf file probably) to go ahead from that point and don't spend time rebuilding stage0 again (and you should get an dupdated RC with updated overlayed ports in sync with what should be final release)
<pitillo>
yeah, great
<jaeger>
ok
<pitillo>
I'm trying here to do things right..... generic 32b build on the odroid (3.6) instead of doing it on the cubieboard2 (3.3)
<jaeger>
Could you not also do that 32b generic one on the M1?
<pitillo>
I've tried but got a strange behaviour, not sure if 3.6-32b is broken or if it's the M1
<pitillo>
prt-get isn't working (it doesn't find ports)
<jaeger>
weird
<jaeger>
Was that in a generic 3.6 rootfs?
<pitillo>
yes, fresh 3.6 release download
<pitillo>
I should download it on the odroid and chroot into it to confirm if it's something related to 3.6 release or to the M1
<jaeger>
I definitely see the behavior you're talking about, pretty strange
<pitillo>
I don't know if it's related to armv7
<pitillo>
and strace can't help with the current kernel on the M1
<pitillo>
not sure if rebuilding core collection directly there can help... but I finished using a real device for 32b due to lack of time and to dont disturb my wife
<pitillo>
I'm not sure if it's worth the effort
<pitillo>
I need to change the external disk on the odroid
<pitillo>
I'll do it tomorrow... I don't want to disturb the kid neither xD
<jaeger>
I'm going to rebuild the toolchain in that 32b generic container to see if it helps
<jaeger>
if it doesn't, I'll rebuild core and see if THAT helps :)
<jaeger>
heh, my build with passing DEVICE_OPTIMIZATION failed again with curl not found
<pitillo>
I feel it will work, but I see one problem
<jaeger>
and [Config error: can't access /workspace/ports/core-arm]
<pitillo>
curl not found because it's looking in core-arm instead of core-arm64?
<jaeger>
so yeah, it's still not working quite right that way
<pitillo>
yeah, that's the point
<jaeger>
Just confirming what you expected
<pitillo>
the export in theory muse work but we are passing options to sub make command in a different way, so it isn't working
<pitillo>
perfect
<pitillo>
you can just change directly the Makefile for raspberrypi4 optimization and manually change prt.get.conf to check that the collection is the first one and correct core-arm to core-arm64 and it must go ahead
<pitillo>
may be a touch on rootfs-stage1 directory is needed too
<pitillo>
about the 32b container, I see one problem. If you check $MACHTYPE or uname -a you'll notice that it's an armv7
<pitillo>
building using this machtype probably will break older devices, so any of the armv5 won't run the release right
<pitillo>
I feel rebuilding toolchain and core ports collection will make it work, but I'm not sure if we'll get a good result
<pitillo>
we'll be capping all those device > armv5te and < armv7 (all the armv6* will be out of support)
<jaeger>
hrmm, good to know
<jaeger>
yeah, looks like --platform linux/arm and --platform linux/arm/v7 both produce armv7
<pitillo>
yes
<jaeger>
so does --platform linux/arm/v5, heh... so I guess that's not really a thing it knows
<jaeger>
Well, I have some more rpis (3, 4, zero 2w), a la frite, and an original pinebook I could run some builds on if it would help
<pitillo>
the pinebook....
<jaeger>
32- or 64-bit?
<pitillo>
that could be very interesting device to install crux-arm there.... because its kernel should be pretty new or updated.... not like the chromebook which its kernel is old (3.8) and there are some problems with glibc
<jaeger>
I'll have to charge it up and see if I can figure out its u-boot
<pitillo>
which distro runs by default?
<jaeger>
I don't remember if I have arch or debian on it but it's one of those
<pitillo>
ummmm good enought
<pitillo>
not like chromeos...
<pitillo>
xD
<jaeger>
Presumably I can reuse their boot.scr/boot.cmd
<pitillo>
currently rpi4 is the aim
<pitillo>
of course... and kernel + modules
<pitillo>
I like a lot crux-arm performance on the chromebook... it was running really well 3.5... now with 3.7 there are a lot of problems due to the old kernel (first one I saw was glibc, but openssl has too)
<jaeger>
Will have to use an external keyboard but that's fine :) I have extras
<jaeger>
The pinebook has the worst keyboard ever designed
<pitillo>
jajajajajaa
<pitillo>
I like the feeling of the chomebook's kbd, but it's GB layout and for the first hour makes me go crazy
<jaeger>
I haven't used any chromebook, myself
<beerman>
the pinebook costs as much as a half decent keyboard so.. 😄
<pitillo>
xD
<jaeger>
Looks like the challenge will be in finding the pinebook's power brick
<jaeger>
... and I found it as soon as I typed that
<pitillo>
I know that feeling xD
<pitillo>
I took me a bit more to find the chromebook one... until I realized that it had a very tiny connector and it was easier to find
<jaeger>
OK, I was wrong, it's ubuntu rather than debian... 3.10.105 kernel but it should be the same hardware as a pine64 of some model, I think... so can probably run newer
<pitillo>
I think they have mainline support (6.1) but I'm on the way trying to compile a good one for the pine64 (I haven't gotten it to boot.... some mmc problems on 5.15 and haven't checked 6.1 error yet)
<beerman>
i am currently compiling the first pi4 as a desktop, then the other to have both as a distcc buildfarm, should be easier from there
<pitillo>
another interesting toy, the pinephone... but smells hard to get a fully working phone with crux... it could be a nice project (if the gsm part could be done)
<pitillo>
could you please check the version jaeger ?
<beerman>
dude, using it as a phone is hard
<jaeger>
The version of what?
<pitillo>
beerman: yeah... we had some htc and the gsm part wasn't possible due to blobs
<pitillo>
jaeger: kerbel version
<jaeger>
on the pinebook ubuntu install? I mentioned above, it's 3.10.105
<pitillo>
beerman: we didnt deep into UI for phone... just the gsm communication
<jaeger>
If you mean the gitlab fork, it looks like their default branch is 5.19.something
<beerman>
gsm is not the problem, 5g/lte is working fine. just performance is.. not what you expect from a todays phone
<pitillo>
I mean on gitlab, sorry
<jaeger>
pine64-kernel-ppp-5.16.yt
<jaeger>
pine64-kernel-ppp-5.16.y
<pitillo>
interesting, I need to check it.... that could be the good stary point instead of going on by my own....
<pitillo>
beerman: which WM/DE/UI is used? and which distro?
<pitillo>
(moving home, I'll check later from there)
<beerman>
pitillo: i currently run postmarket os with sway on it
<beerman>
uhm
<beerman>
it has a codename
<beerman>
their site is down 😐️well. its alpine edge under the hood, with phone additions.
<beerman>
they offer phosh (gnome), plasma (kde) and sxmo (i think that was the name, which is sway with a few scripts, so pretty barebone)
<beerman>
and i think there is a few more flavors, but yeah. plasma runs the worst but looks the nicest. phosh is a little bit weird imo, for a phone ui. and well, sxmo runs the smoothest but is the weirdest to wrap around.
<beerman>
its best used as a mobile linux device that you can hook up to a usb docking station to get a minimal desktop experience
<beerman>
at least imo
<beerman>
and as such its super handy
<pitillo>
interesting combos beerman, the alpine one seems light
<jaeger>
Apparently there's even a slackware image as recently as 2 months ago for the pinebook, neat. Might give that a try as a starting point to research
<pitillo>
and that point about connecting it to a dock, being a mobile device that can be converted toba desktop device... spunds amazong really
<pitillo>
that sounds pretty well jaeger
<beerman>
how is the battery life for the pinebook? the phone is mostly holding up well, can go for 2 days or more in idle on battery