<jaeger>
yes, those changes appear to be in the 3.7 branch... but curl and openssl are still required
<jaeger>
ok, I'm going to start from scratch and see if I missed something. I should b eusing the 3.7 branch, yes?
<pitillo>
which is the first port requiring any of them?
<pitillo>
yes, 3.7 branch should be the good one
<jaeger>
ok, will report back when it fails, started from a fresh checkout
<jaeger>
So I guess that issue where you guys removed curl and openssl is in conflict with my recent PR/issue that adds openssl back (and isn't sufficient anyway because it doesn't add curl)
<pitillo>
but curl and openssl should be built earlier on stage1 with all sources downloaded
<jaeger>
They weren't, that's why I added them to the stage0 ports list... but obviously I'm missing something here
<jaeger>
I really don't understand how this works at all
<jaeger>
New stage0 is building now... after that finishes I'll test download-stage1-sources
<pitillo>
it should be a minimal rootfs built with host tools (compiler+libs), then we prepare sources to avoid curl dependency to build ports and finally we jail stage0-rootfs to start building the entire ports collection (using overlays in case of optimizations)
<jaeger>
I understand the *intent* behind that but I don't understand how it works for you guys but not for me, yet
<pitillo>
I used the bootstrap option and got some problems on stage1 with some footprint mismatches
<pitillo>
are you running stage by stage?
<beerman>
ah, final link failed after 2.5h for bad value, fun
<jaeger>
Can you describe exactly how your build environment is set up and what commands you used?
<pitillo>
can you try to run directly a bootstrap?
<jaeger>
Yes, I tried bootstrap first and it failed, that's why I dove into stage0 and stage1 individually
<jaeger>
What is the intended way to run this from a fresh clone? bootstrap by itself?
<jaeger>
Are the stage0/stage1 targets not meant to be used individually?
<pitillo>
I usually do DEVICE_OPTIMIZATION=yourdevice make bootstrap
<jaeger>
Only bootstrap and no others?
<pitillo>
the aim should be to use the bootstrap option to build all, then make release to create the final rootfs
<pitillo>
when I got problems with mismatches, I used make stage1
<jaeger>
OK... the readme or 'make help' should probably reflect that :)
<pitillo>
just removing old footprints, rebuilding and creating a new one
<pitillo>
that sounds fine and fair
<jaeger>
I'll test bootstrap specifically and see if/when it fails for me
<pitillo>
perfect
<jaeger>
What's your build host/environment? Is it a container, VM, dedicated host?
<jaeger>
I'm still using the generic 3.7 container I built, for what that's worth
<pitillo>
I still have the same container (got 2 snapshots on the way to keep it updated)
<jaeger>
packages.stage0.tar.xz: POSIX tar archive (GNU)
<jaeger>
rootfs.stage0.tar.xz: POSIX tar archive (GNU)
<jaeger>
@tar cf $(PACKAGES_STAGE0_TAR_FILE) `find ports -type f -name "*.pkg.tar.$(PKGMK_COMPRESSION_MODE)"` <-- for example, does not specify any compression to the tar command, just in the filename
<jaeger>
Would need J or a added
<beerman>
final link failed again. which sources are you guys using? kernel.org or raspberrys own fork? I've been trying the latter
<beerman>
of course i only half arsed it today. tomorrow and the day after i am away for work so can't keep looking into it
<beerman>
i'll keep poking over the weekend i guess
<pitillo>
good catch jaeger, that compression option must be fixed
<pitillo>
so coreutils is the real problem. ports.stage1 file must have all the pprts to build the release/rootfs and the order is important
<pitillo>
in this case, coreutils from stage0 is broken
<pitillo>
let's see if I can check it tomorrow
<pitillo>
beerman: I usually build Image and modules, I've never used the all target
<pitillo>
do you have a lognto check which module breaks the build?
<pitillo>
how much ram has the rpi4? 2gb?
<jaeger>
So, aside from crux-arm-release, there's still the issue of the REPO file in crux-ports-raspberrypi4-arm64 not being updated properly for some reason