Since there seems to be a general consensus that having Alpine 3.15 deliver riscv64 packages is a good idea, we need to start preparing infrastructure for it. So far, all of my work on riscv64 port has been done with qemu-user-static in a OCI container and that works really well so far (especially when run on a 32-core beefy x86 box). The other alternative is a full qemu-system-riscv64 VM that can be done pretty easily as well.
Personally, I'm running my automation around this on GitHub's Actions (using their x86 ubuntu-latest box). This may be a useful starting point for some: https://github.com/lf-edge/eve/blob/master/.github/workflows/publish.yml#L27
Also, here's how I boostrapped a build container by simply running
docker build -t riscv64 https://github.com/lf-edge/eve/blob/master/build-tools/src/scripts/Dockerfile.alpine.bootstrap
Again could be useful.
Even better reason to close it is that it is actually done ;-)
This tiny fix enables bootstrap to function on riscv64 platform again. The logic here is that we need openssl native package as a pre-requisite for the builds we are going to do right around libretls.
This is no longer needed. Closing.
Yeah @kaniini -- the key matches packages that were built later (current theory post-bootstrap)
Hey @tonistiigi -- thanks for reporting this -- it seems that packages built as part of cross-bootstrap suffer from this issue. I'll look into this.
This tiny fix enables bootstrap to function on riscv64 platform again. The logic here is that we need openssl native package as a pre-requisite for the builds we are going to do right around libretls.
Roman Shaposhnik (c3561cc6) at 28 Jun 03:24
Fixing libretls build on riscv64
... and 2473 more commits
Sounds like a plan @nmeum ! Lets wait for the proper m4 release.
Actually when I did my experiments I did them with checks on -- it was only about 200 packages out of 3000 or so I built that required test tweaks. So perhaps it may worth it -- I'll follow up within a bigger plan on a mailing list.
Welp, FWIW: I'm debugging it now. Here's the build environment I'm using https://github.com/rvs/alpine-riscv64/blob/main/Dockerfile note this line apk add abuild curl tar make linux-headers patch g++ git gcc ncurses-dev autoconf file
not sure what other packages that pulls -- but I find it necessary to do.
Hey @nmeum -- judging by the m4 ML responses the fix is available now. Shall we add it as a custom patch into Alpine master?
At this point I need to make sure that whatever is left out of all my MRs is cleanly applicable to the post 3.14 master of Alpine. @kaniini I guess the easiest is to just close these MRs and open new ones (with reduced patch set)?
At this point I need to make sure that whatever is left out of all my MRs is cleanly applicable to the post 3.14 master of Alpine. @kaniini I guess the easiest is to just close these MRs and open new ones (with reduced patch set)?
Seems like two of these MRs collided @sodface -- which kind of points out the fact that scripts/bootstrap.sh doesn't really get tested unless somebody runs it manually (like I did for the RISCV bootstrap). Perhaps we should create a test that actually does run it on all the architectures just to make sure it doesn't bit rot? WDYT @kaniini ?
Roman Shaposhnik (988c4057) at 05 Jun 17:33
This is a pretty simple bootstrap.sh refactoring that mostly just re-arranges the order in which the packets are build and accounts for platforms where libatomic is required.
Roman Shaposhnik (0a568a04) at 02 Jun 15:35
So... what's the verdict here? Somebody's setting up a builder?
Done. @kaniini can you please review again?