genpaku has quit [Remote host closed the connection]
genpaku has joined #crux-arm
<pitillo>
Stalevar: yeah, we are on the way
<pitillo>
it takes some time... more when we have migrated our main server
<pitillo>
you can check github crux-arm project to see what-s going on
<pitillo>
atm I-m still fighting with bsdtar locale problem to build generic gcc port...
<beerman>
oh
<beerman>
just switch pkgmk to use some utf-8 locale
<beerman>
3.7 glibc will provide C.UTF-8 by default
<beerman>
pitillo: ^
<pitillo>
yeah, I'm trying it without success... LC_ALL="en_US.UTF-8" fakeroot pkgmk -d
<pitillo>
same problems with bsdtar
<pitillo>
we have glibc ready (and another buch of ports) but currently I'm stuck with gcc
<Stalevar>
pitillo, I was trying to use fakeroot to make slackware packages, but somehow they didn't change ownership to root in created tar files (packages), do you have any ideas how to fix that, except building slackware packages under real root?
<Stalevar>
Also it seems that crux-arm only provides root tarball so what is the solution for the bootloader and kernel?
<Stalevar>
I wanted a very specific thing, I don't know if crux-arm could help. I want a kernel+initrd for arm64 which have complete system working from RAM, so I can load it and replace the boot media
<pitillo>
Stalevar: I'm using this setup for prt-get.conf to use fakeroot: makecommand sudo -H -u pkgmk fakeroot pkgmk
<Stalevar>
The reason for that was to test the speed of a new microSD card, while the arm64 machine only can boot from microSD, it seems
<pitillo>
yes, we provide only rootfs and core ports for releases. Kernel and bootloaders are device dependent, so we can provide some of them (for devices we have)
<Stalevar>
What about rPi400 ?
<Stalevar>
or orangepi4
<pitillo>
which device are you using? I believe you can do that (initrd boot for sure if you can manage your boot device)
<Stalevar>
I plan to use exiting install of Armbian
<pitillo>
we don-t have any of them, but we were using an initrd on rpi3 without problems (we started with it on the efikaMX)
<Stalevar>
pitillo, do you have an initrd with complete crux-arm64?
<Stalevar>
Yeah, it will be several hundred megs but it should fit in 4G ram, I guess
<pitillo>
let me check all those changes... I'm currently using 3.6 glibc version to start preparing the generic 3.7 release
<pitillo>
I didn't want to change the POSIX spec on pkgmk....
<pitillo>
$ pkginfo -i|grep pkgutils
<pitillo>
$ locale -a
<pitillo>
C
<pitillo>
pkgutils 5.40.7-1
<pitillo>
C.utf8
<pitillo>
POSIX
<pitillo>
POSIX.utf8
<pitillo>
en_US
<pitillo>
en_US.iso88591
<pitillo>
en_US.utf8
<pitillo>
es_ES
<pitillo>
es_ES.iso88591
<pitillo>
es_ES.utf8
<pitillo>
I've rebuilt locales... and tried to build C.utf8.... exporting them or passing them to the pkgmk command gives always the same result
<pitillo>
I'll try to speak with sepen, who is currently working on arm generic release (I'm on the way with arm64)
<beerman>
it won't work with glibc from 3.6
<beerman>
the updated is needed
<beerman>
you can unpack gcc with a custom unpack_source like inside the Pkgfile to bootstrap but its not needed once you have the correct locale on the system
<pitillo>
I think I'll go ahead with the unpack_source... I don-t like it but it's the less invasive method I feel
<beerman>
its just for the meantime really
<beerman>
you don't need to push that
<beerman>
if people update from source by just changing the repos from 3.6 to 3.7 they should get pkgutils and glibc before gcc anyway
<pitillo>
yes, that's true... but for use is a bit ugly this situation (or at least for me from my POV)
<pitillo>
btw, let's see if I can go ahead building and preparing packages...
<beerman>
it is, but it shouldn't be needed at all with C.UTF-8
<beerman>
in the past versions we had problems with a few ports that shipped files which had utf8 glyphs in their names
<beerman>
we can clean those out now
<pitillo>
yeah, but for me is strange why generating locales for C.UTF-8 didn't solve the problem exporting it on LC_ALL
<pitillo>
may be I generated them wrong
<beerman>
which glibc version do you have?
<beerman>
because they just added that with 2.35 or something
<pitillo>
$ pkginfo -i|grep glibc
<pitillo>
glibc 2.32-4
<pitillo>
current 3.6 version if I'm right
<beerman>
yeah
<beerman>
that won't work in one easy step
<beerman>
update the chain towards glibc first, then glibc with the locales
<beerman>
its quite a change, but afterwards its all good
<pitillo>
yeah, but in our process... we can-t update local 3.6 ports (we use them to build the 3.7 ports...)
<beerman>
mh
<pitillo>
a bit messy, but well, we need to go ahead bit by bit to build the stage0 rootfs
<pitillo>
then inside the jail using the stage0, these things will be fixed
<pitillo>
gcc is on the way... let's see if lto doesn't break anythin or I'll revert to original without lto support
<beerman>
lto is actually enabled by default, i just added it explicitly
<beerman>
for visibility reasons basically
<beerman>
but true, some software does not support lto on arm, which is kinda sad, but oh well
<pitillo>
I think I disabled for some reason, don-t remember quite well... but we'll see how it goes and if needed, it will be disabled
<beerman>
i know for a fact that pipewire will not build on the rpi4 armv7 (32bit) with lto enabled..
<beerman>
in cases like those i'd be willing to adopt a line in the pkgfile to disable lto if it finds that it runs on arm platform
<pitillo>
it should give a performance bump at link time... so I hope ARM support is beaing activelly maintained and give lto support
<pitillo>
not like some years ago, when ARM wasn't maintained or wasn't in the aim of developers/maintainers
<beerman>
it should give a perfomance boost at runtime, linking actually takes longer
<pitillo>
link time and runtime, or only at runtime? because gcc should be the responsible of managing ldd at build time too
<beerman>
only at runtime
<pitillo>
interesting
<beerman>
performance gains that is
<pitillo>
I must read a bit deeper
<beerman>
lto will do some smart thinks during linking which take longer to optimize paths
<pitillo>
yeah, that-s what I thought to be related at buildtime too... I thought lto will optimize paths for final link stage building binaries
<beerman>
yep 👍️
<pitillo>
I'm not an expert... but my first thought from what I-ve read was more related to build time... but runtime has sense too
<pitillo>
I'll try to read a bit more to understand it right
<pitillo>
xD
<pitillo>
I'm still a linux n00b
<beerman>
as if haha
<pitillo>
xD
<Stalevar>
did anybody run crux-arm on apple m1 machines yet btw?
<pitillo>
not here... my wife can hit me hard if I touch her mac.... xD
<pitillo>
do you own a m1? or m2?
<beerman>
you never want to fiddle with the authorities hardware
<Stalevar>
pitillo, I thought about it. but it would be easier to install archlinux-arm because there is an exiting fully-automated installer
<Stalevar>
and no, I don't have it, I thought about getting one
<pitillo>
yeah, arch has done an amazing job for ARM...
<pitillo>
very nice procedures and a very nice knowledge base too
<pitillo>
but probably they aren't 2 persons xD
<pitillo>
7h usage of samsung-chromebook with CRUX-ARM 3.3 ... wifi and USB harddisk... currently running mate... amazing
<Stalevar>
You mean first chromebook?
<Stalevar>
pitillo, do you run it off 16M ssd or off external SD / USB?
<Stalevar>
also it's out of production so it's surprising your battery isn't dead yet
<Stalevar>
Also why 3.3 and not 3.6 /
<Stalevar>
* 16G
<pitillo>
yes, first gen chromebook running from sd
<pitillo>
3.3 because I hadn't time to create optimizations
<pitillo>
it runs like a charm
<Stalevar>
pitillo, what do you think about running it from the internal flash?
<Stalevar>
Do you still have chrome OS on it? Did you unlock the bootloader by unscrewing a screw from inside?
<Stalevar>
also what do you do with chrome OS? It doesn't update anymore
<Stalevar>
do you use it?
<pitillo>
not thinking in running it from emmc really, from SD runs great
<pitillo>
I still have chrome OS on emmc and not unlocked the bootloader, just running from developer mode
<pitillo>
my wife started using chrome OS to do some online tasks... when they become bigger, the toy wasn't enought, so she moved again to mac
<jaeger>
When we have a generic rootfs for 3.7, would you like me to build rpi4 64-bit stuff?
<pitillo>
of course jaeger, if it's possible
<jaeger>
sure
<jaeger>
It's connected to a 3d printer but I can put a pi 3 in its place
<pitillo>
that sounds great
<pitillo>
we are changing the way we were building rootfs and optimizations
<pitillo>
sepen is still doing some magic
<pitillo>
there is a repo at github which I believe will be
<pitillo>
interesting for all who wants to build his own generic rootfs and/or optimizations for devices