Hi!
so first of all -- thank you all for taking RISCV forward
while I was traveling -- much appreciated! I see that
we now have a builder that produces packages and they
are actually getting deposited at the usual places. E.g.:
https://dl-cdn.alpinelinux.org/alpine/edge/main/riscv64/
Given that, here's my first few infrastructure related questions:
1. what does it take for edge packages to show up on:
https://pkgs.alpinelinux.org/packages ?
2. in general, do we produce the final consumable aritfacts
for the Edge builds? Things like:
https://alpinelinux.org/downloads/
With that out of the way, personally, I'm going to spend this
coming week making sure that:
* bootstrap.sh is back to functional
* we get to produce at least the following artifacts:
* MINI ROOT FILESYSTEM
* VIRTUAL
* see if we can get rid of !tests on builders and selectively
disable tests in those packages that just need it.
Personally, I also have two SBCs I will be testing Alpine on.
Now, the last question I have is this: what would be the criteria
for the # of packages or anything else to officially release RISCV64
as part of Alpine 3.15?
Thanks,
Roman.
Hi,
On Sun, 27 Jun 2021, Roman Shaposhnik wrote:
> Hi!>> so first of all -- thank you all for taking RISCV forward> while I was traveling -- much appreciated! I see that> we now have a builder that produces packages and they> are actually getting deposited at the usual places. E.g.:> https://dl-cdn.alpinelinux.org/alpine/edge/main/riscv64/>> Given that, here's my first few infrastructure related questions:> 1. what does it take for edge packages to show up on:> https://pkgs.alpinelinux.org/packages ?> 2. in general, do we produce the final consumable aritfacts> for the Edge builds? Things like:> https://alpinelinux.org/downloads/>> With that out of the way, personally, I'm going to spend this> coming week making sure that:> * bootstrap.sh is back to functional> * we get to produce at least the following artifacts:> * MINI ROOT FILESYSTEM> * VIRTUAL> * see if we can get rid of !tests on builders and selectively> disable tests in those packages that just need it.
The problem is that building with tests enabled under qemu is really slow.
It would be nice if we can find some actually decent (at least 16 cores)
builder for riscv64.
The chip made by Alibaba looks promising. I wonder if we can source a
board with it, somehow?
> Now, the last question I have is this: what would be the criteria> for the # of packages or anything else to officially release RISCV64> as part of Alpine 3.15?
I'm not comfortable having riscv64 as a release architecture until we are
building on real silicon, but if the qemu stuff proves to be otherwise
solid, then I guess that's fine too if we have real QA happening on real
boards.
Ariadne
On Mon, Jun 28, 2021 at 7:36 AM Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hi,>> On Sun, 27 Jun 2021, Roman Shaposhnik wrote:>> > Hi!> >> > so first of all -- thank you all for taking RISCV forward> > while I was traveling -- much appreciated! I see that> > we now have a builder that produces packages and they> > are actually getting deposited at the usual places. E.g.:> > https://dl-cdn.alpinelinux.org/alpine/edge/main/riscv64/> >> > Given that, here's my first few infrastructure related questions:> > 1. what does it take for edge packages to show up on:> > https://pkgs.alpinelinux.org/packages ?> > 2. in general, do we produce the final consumable aritfacts> > for the Edge builds? Things like:> > https://alpinelinux.org/downloads/> >> > With that out of the way, personally, I'm going to spend this> > coming week making sure that:> > * bootstrap.sh is back to functional> > * we get to produce at least the following artifacts:> > * MINI ROOT FILESYSTEM> > * VIRTUAL> > * see if we can get rid of !tests on builders and selectively> > disable tests in those packages that just need it.>> The problem is that building with tests enabled under qemu is really slow.> It would be nice if we can find some actually decent (at least 16 cores)> builder for riscv64.
Agreed, although when I was building all of aports on 32-way Dell server
I deliberately kept tests on. Aside from half a dozen or so packages (that
yes -- those get REAL slow) everything else wasn't all that horrible frankly.
Would it make sense to reconsider bulk !tests and instead just selectively
turn it off on a few packages for riscv64? By my current count, it would be
around 200 or so packages in all aports where we would have to do that.
We can also do it slowly (as to not overwhelm the current builder).
Will this work?
> The chip made by Alibaba looks promising. I wonder if we can source a> board with it, somehow?
Let me work on that -- but be warned, this maybe 2-3 months kind of
an exercise (at best!). I'll talk to my peeps at RISCV foundation.
> > Now, the last question I have is this: what would be the criteria> > for the # of packages or anything else to officially release RISCV64> > as part of Alpine 3.15?>> I'm not comfortable having riscv64 as a release architecture until we are> building on real silicon, but if the qemu stuff proves to be otherwise> solid, then I guess that's fine too if we have real QA happening on real> boards.
How about the middle ground? We build on qemu with most tests enabled
for now and we test on these two SBCs:
https://beagleboard.org/beaglevhttps://www.indiegogo.com/projects/nezha-your-first-64bit-risc-v-linux-sbc-for-iot/x/13053257#/
I can also pretty trivially add the bigger board:
https://www.sifive.com/boards/hifive-unmatched
but honestly I don't actually see much value in it over the above SBCs.
Thanks,
Roman.