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.
Hello,
On Sat, 8 May 2021, Roman Shaposhnik wrote:
> 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
Very good!
> 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.
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.
> 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?
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
On Sun, May 9, 2021 at 8:35 AM Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hello,>> On Sat, 8 May 2021, Roman Shaposhnik wrote:>> > 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>> Very good!
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> > 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.>> When we first got mips64 bootstrapped, I just blocked packages on mips> 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> their packages be portable across architectures and will work to fix them> when they notice arch="all !riscv64" in their APKBUILDs.
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)?
> > 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?>> Yes, please open MRs for packages which need modifications for the RISC-V> port.
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.
> 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).
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.
Hi,
On Mon, 10 May 2021, Roman Shaposhnik wrote:
> On Sun, May 9, 2021 at 8:35 AM Ariadne Conill <ariadne@dereferenced.org> wrote:>>>> Hello,>>>> On Sat, 8 May 2021, Roman Shaposhnik wrote:>>>>> 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>>>> Very good!>> 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>>>> 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.>>>> When we first got mips64 bootstrapped, I just blocked packages on mips>> 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>> their packages be portable across architectures and will work to fix them>> when they notice arch="all !riscv64" in their APKBUILDs.>> 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)?
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.
>>> 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?>>>> Yes, please open MRs for packages which need modifications for the RISC-V>> port.>> 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.>>> 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).>> 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.
Yep, we could do something like that.
Ariadne
On Mon, May 10, 2021 at 7:06 PM Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hi,>> On Mon, 10 May 2021, Roman Shaposhnik wrote:>> > On Sun, May 9, 2021 at 8:35 AM Ariadne Conill <ariadne@dereferenced.org> wrote:> >>> >> Hello,> >>> >> On Sat, 8 May 2021, Roman Shaposhnik wrote:> >>> >>> 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> >>> >> Very good!> >> > 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> >> >>> 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.> >>> >> When we first got mips64 bootstrapped, I just blocked packages on mips> >> 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> >> their packages be portable across architectures and will work to fix them> >> when they notice arch="all !riscv64" in their APKBUILDs.> >> > 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)?>> 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> 100 packages total. So lets avoid doing that. You can use buildrepo -k> to keep going on build failure.
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.
Hi,
On Mon, 10 May 2021, Roman Shaposhnik wrote:
> On Mon, May 10, 2021 at 7:06 PM Ariadne Conill <ariadne@dereferenced.org> wrote:>>>> Hi,>>>> On Mon, 10 May 2021, Roman Shaposhnik wrote:>>>>> On Sun, May 9, 2021 at 8:35 AM Ariadne Conill <ariadne@dereferenced.org> wrote:>>>>>>>> Hello,>>>>>>>> On Sat, 8 May 2021, Roman Shaposhnik wrote:>>>>>>>>> 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>>>>>>>> Very good!>>>>>> 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>>>>>>>> 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.>>>>>>>> When we first got mips64 bootstrapped, I just blocked packages on mips>>>> 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>>>> their packages be portable across architectures and will work to fix them>>>> when they notice arch="all !riscv64" in their APKBUILDs.>>>>>> 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)?>>>> 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>> 100 packages total. So lets avoid doing that. You can use buildrepo -k>> to keep going on build failure.>> 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).
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