<r0ni>
speaking of rootfs, does anyone know the steps to create a valid working rootfs with crux-arm-release ? I'm noticing my stage0 & stage1 are only a few kb diff in size and I feel like something may be missing. yet I'm unsure of the real order to build it, and i generally go until 'make release' doesn't fail, but it feels off to me... like even /etc/ports' don't exist inside the tarball
<r0ni>
my taballs used to be like 160mb and now it makes like 113mb... feels like something has silently failed inside the process
<r0ni>
also the 0kb footprint for python3 causes a failure during building
<pitillo>
jaeger: you are right about flags (march, mtune) as r0ni said. They are avoided on the generic releases but they are usefull when we focus on optimizations
<pitillo>
r0ni: check bootstrap, try to avoid going step by step. The bootstrap option will go ahead over the entire process
<pitillo>
r0ni: if you are creating an optimized release for a specific device, create a nre device/your_device.mk file with you needed options (take any of the files there as template)
<pitillo>
s/nre/new
<pitillo>
jaeger: the native option could be interesting too. Some time ago it gave problems building specific software and flags must be overlayed on Pkgfiles. I'm not sure if currently is a good option to be used for optimez releases (as it must autodetect arch, march and mtune). It could be good to make tests, but they should be intensive in the meaning of buildibg a very big set of ports to be sure it doesn't
<pitillo>
affect ports builds (not sure if I'm explaining it right)
<pitillo>
jaeger: very good reading, thank you so much for sharing
<r0ni>
pitill0 nah i generally just make a standard rootfs, but I come across failures here and there... usually go stage0, stage1, then try make release/bootstrap until it spits out the rootfs and symlinks it... but it feels like i may be messing it up
<r0ni>
i should try and do an install with one... that will clue me in lol
<pitillo>
r0ni: yeah, start from scratch directly with a bootstrap (probably we need to review download sources as it's the main fault usually
<r0ni>
ok i'll try that, i generally wipe and re-clone it when i do it so nothing ends up leftover
<r0ni>
i do sometimes need to be root or a user as well... dont seem consistent
<r0ni>
have fakeroot installed for it... still wishy washy
<r0ni>
i also build from latest git as i keep a clone of the repo in my github and just keep it up to date
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ crux-ports-core-arm64 ] glibc: fixed enable-kernel option (minimum required kernel) from 3.2 to 3.7.0 (Issue #7)
crux-arm-bot has left #crux-arm [#crux-arm]
crux-arm-bot has joined #crux-arm
<crux-arm-bot>
[ crux-ports-opt-arm ]: icu: update to 74.2
crux-arm-bot has left #crux-arm [#crux-arm]
<pitillo>
r0ni: any fix or improvement will be welcome
<pitillo>
it's a bit "meshy" but all releases were built fine on that time
<pitillo>
I had some troubles with optimizations and sub make vars, but forcing them into the Makefile directly fixed it
<pitillo>
other problems were related to sources... the Makefile stops if it get a 404 due to removed sources, vut downloading them and restarting the bootstrap fixed it too, as it begins building from where it stoped
<jaeger>
After some reading and experimenting I'm testing with "-march=armv8.2-a+crc+crypto -mtune=cortex-a76 -O2 -pipe" now
<jaeger>
NOT specifying march= caused at least gcc to fail with a conflict between mcpu and march
<jaeger>
I was able to rebuild all the packages in the container properly with this set so far
<pitillo>
nice
<r0ni>
oh a 'make bootstrap' succeeded, i'm assuming just a 'makek release' is needed to finish it off
<r0ni>
hrm i take that back, it failed dunno how i missed that
<jaeger>
Can you refresh my memory on how crux-arm-release is used?
<pitillo>
r0ni: where did it failed?
<pitillo>
just a make bootstrap to build all ports
<pitillo>
make release to package them
<jaeger>
And it's native, not cross, right?
<pitillo>
the optimizations are defined in .mk files but in my case they gave problems, so editing the Makefile and forcing the cflags there
<jaeger>
side note, my rpi5 just arrived
<pitillo>
yes jaeger, I was using a docker container with fresh clone.... but probably now will be there problems (said above, most odnthem with downloading sources, which should be in the first steps)
<pitillo>
niiiiice
<jaeger>
Need to create a raspberrypi5.mk as well as start repos for it
<pitillo>
so probably no need to use crux-arm-release... just generic release and a full rebuild with those CFLAGS ypu mentioned above
<pitillo>
ofnyou have the device, there is no need to use crux-arm-rlease...
<jaeger>
Fair enough. I already did a full set of package in the container on the m1, I'll try to get a rootfs on the rpi5 soon
<pitillo>
just create/prepare an overlay for specific ports (as other devices, pet-get, pkgmk, ports...)
<jaeger>
yeah
<pitillo>
crux-arm-release is used to prepare something for a device, it's another possibility, but probably not recommended if you have the device
<pitillo>
because all the work is done (generic release) which can be used as a base for an optimized native build release
<jaeger>
Makes sense
<pitillo>
that repo will be used for 3.8/4.0
<pitillo>
in that moment, help will be very welcome
<pitillo>
just to improve it, because it's a ver good repo which can be used for other aims
<pitillo>
reduced set of ports, different libc, customizations....
<pitillo>
at first sight it can be messy, complex... but it's just abMakefile to do some steps/stages
<pitillo>
this is why I personally would like to get you involved
<pitillo>
it's thwre for all people
<pitillo>
the more people looking at it, the more people using it... the best to get it better
<jaeger>
I don't mind helping at all, it just ends up that a lot of time passes between times I look at it
<pitillo>
usually happens jaeger... I take the look back and time passed... 10 years? 15 years? 20?.... and the project is still there because IMHO, it's a good one based on the best distro... the one who engadget me in this world 20 years back
<pitillo>
it's hard for me to re-take again all this stuff between releases
<jaeger>
Well, I don't mind building stuff on my rpi4 or rpi5 any time to help
<pitillo>
more when we have changed one year ago all the infrastructure, moved to a more open world like github, trying to make it easier to other to contribute, to be part of the project, to let it grow....
<pitillo>
it isn't only building, which is an effort too...
<pitillo>
you are the fatjer of the iso prpcess for x86
<pitillo>
check crux-arm-release which should be the same for ARM...
<pitillo>
speaking with sepen some days ago... we took a look back and all this stuff satrted with a bash script
<jaeger>
It's kinda funny to see how it all evolves over the years
<pitillo>
and taking a look outside X86 for me is amazing
<pitillo>
ARM like RiscV... will be in all places very soon
<pitillo>
I know about ARM, it smelled...
<pitillo>
now I can feel the smell pf RiscV
<pitillo>
energy consumption is the key
<pitillo>
and now, energy and capabilities are very steong
<pitillo>
RiscV add another layer.... freedom
<pitillo>
s/add/adds
<pitillo>
it's just an opinion or a feeling xD
<pitillo>
btw, you guys have a lot of knowledge. Put a bit of time checking the repositories
<pitillo>
and improve them if you feel right to do that
<pitillo>
I like Github because now we can see in a public service who and when contributed
<jaeger>
fair enough
<pitillo>
it has good and bad sides.... I try to focus on the good ones
<pitillo>
feel free to do whatever you want, use or don't use it, contribute or don't
<pitillo>
but like I always said... create something is very hard
<pitillo>
maintaining it is harder
<pitillo>
I don't remember if was ukky or r0ni who was checking all the cross stuff (I think ukky). Now all the repos are on github. Feel free to send whatever you think that can improve any of them
<pitillo>
time to rest here, have a good night#&#&#)+@#