Subject: Progress on Alpine for RISC-V (and BeagleV)

From: Roman Shaposhnik <[email-masked]>
Date: Sat, 8 May 2021 19:50:47 -0700

Hi!

A few updates for anyone interested in Alpine bringup on the board:

I’ve bootstrapped quite a bit of Alpine packages and published updated
aports here https://github.com/rvs/aports

A growing collection of packages is now available under
   https://eve-alpine-packages.s3.amazonaws.com/edge/{main,community}

It is enough to generate basic images, so for example, here’s a minirootfs
published that can be used to bootstrap your own containers
   https://eve-alpine-packages.s3.amazonaws.com/edge/images/alpine-minirootfs-210509-riscv64.tar.gz

I still need TONS of help to fix/bootstrap more packages — and for that
I published a builder environment — so if you (on a latest Docker for Mac
or docker + qemu-user-riscv64) do:
         $ docker build -t alpine-riscv64
https://eve-alpine-packages.s3.amazonaws.com/edge/images/Dockerfile
         $ docker run -it --rm alpine-riscv64
         builder$ cd aports
You will end up in an environment that I’m using to build all of these
packages and can help me with:
          cd <YOUR FAVORITE PACKAGE>
          hack APKBUILD (or not)
          abuild -r

Now, for the most perplexing question of all: it is pretty clear that
it may be a bit overwhelming for a single person (like me) to make
sure that we do ALL of the packages at once to support RISC-V.

So I'm wondering if there's any way to do it steps -- where we bring
up progressively more and more packages into the release, but at
least the ones that are already supported are not allowed to bitrot
anymore on RISC-V. Is there any process around Alpine releases
that would allow us to do that?

Thanks,
Roman.

---

From: Ariadne Conill <[email-masked]>
Date: Sun, 9 May 2021 09:35:00 -0600 (MDT)

Hello,

>   https://eve-alpine-packages.s3.amazonaws.com/edge/images/alpine-minirootfs-210509-riscv64.tar.gz

Very good!

> sure that we do ALL of the packages at once to support RISC-V.

When we first got mips64 bootstrapped, I just blocked packages on mips 
that were non-essential that didn't build.  Most maintainers want to see 
their packages be portable across architectures and will work to fix them 
when they notice arch="all !riscv64" in their APKBUILDs.

> that would allow us to do that?

Yes, please open MRs for packages which need modifications for the RISC-V 
port.

I'm willing to operate a qemu-user builder for riscv64 (I'm quite 
convinced this is the only way we're going to make progress with the 
current build system, but ncopa is planning a new one out).

Ariadne

---

From: Roman Shaposhnik <[email-masked]>
Date: Mon, 10 May 2021 18:45:12 -0700

> >   https://eve-alpine-packages.s3.amazonaws.com/edge/images/alpine-minirootfs-210509-riscv64.tar.gz

There's also binary install images available now:
    https://eve-alpine-packages.s3.amazonaws.com/edge/images/alpine-riscv-210511-riscv64.tar.gz
and
    https://eve-alpine-packages.s3.amazonaws.com/edge/images/alpine-netboot-210511-riscv64.tar.gz

> that were non-essential that didn't build.

Aha! Quick question: from that experience -- do you remember what were
the packages that were deemed a MUST for the port?

> Most maintainers want to see

For sure! But are you saying that it would be acceptable to first bulk update
all the APKBUILD files with arch="all !riscv64" (sans those that actually
compile just fine)?

> Yes, please open MRs for packages which need modifications for the RISC-V

I plan to start doing it next week -- once I get a chance of running with Alpine
as my default distribution on this board for a few days more.

> current build system, but ncopa is planning a new one out).

That's what I've been doing so far and I must say -- the performance
was REALLY decent (I just used my beefy laptop). On top of that I've
been thinking of trying to see how it flies on the biggest boxes available
on Packet.net.

Thanks,
Roman.

---

From: Ariadne Conill <[email-masked]>
Date: Mon, 10 May 2021 20:06:37 -0600 (MDT)

Hi,

> all the APKBUILD files with arch="all !riscv64" (sans those that actually

At least with mips, most compiled just fine.  I only had to block about 
100 packages total.  So lets avoid doing that.  You can use buildrepo -k 
to keep going on build failure.

> been thinking of trying to see how it flies on the biggest boxes available

Yep, we could do something like that.

Ariadne

---

From: Roman Shaposhnik <[email-masked]>
Date: Mon, 10 May 2021 19:38:29 -0700

On Mon, May 10, 2021 at 7:06 PM Ariadne Conill <[email-masked]> wrote:
> At least with mips, most compiled just fine.

I think here it will be less "out of the box" experience (I actually expect
a LOT of packages to compile with just tiny tweaks to APKBUILD tho --
but those tweaks add up and I don't think I can do it in one go -- hence
this thread).

> I only had to block about

This brings up a good question -- if I spin a beefy box on Packet, what's
the easiest way for me to try and build it all? Basically just to see what
happens (sorry -- not super familiar with buildrepo -- been mostly using
abuild directly).

Thanks,
Roman.

---

From: Ariadne Conill <[email-masked]>
Date: Tue, 11 May 2021 14:00:59 -0600 (MDT)

Hi,

> happens (sorry -- not super familiar with buildrepo -- been mostly using

From a chroot inside your minirootfs + toolchain, you can do:

$ abuild-apk add lua-aports
$ buildrepo -k main

Assuming that aports is checked out to $HOME/aports.

Ariadne