could a minimal set of packages be ported to rv64?

[Kreijstal]

maybe just enough to run sbuild

user@starfive:~/git/soar$ ~/.cargo/bin/soar update
Fetching public key from https://meta.pkgforge.dev/bincache/minisign.pub
Fetching public key from https://meta.pkgforge.dev/pkgcache/minisign.pub
[ERROR] Failed to fetch from remote source: https://meta.pkgforge.dev/bincache/riscv64-Linux.sdb.zstd [404 Not Found]
[ERROR] Failed to fetch from remote source: https://meta.pkgforge.dev/pkgcache/riscv64-Linux.sdb.zstd [404 Not Found]
No packages to update.

[Azathothas]

Part of this was discussed here: #148 (comment)

I actually evaluated the logistics of adding loongarch64 & riscv64 as there were numerous requests from users in China, a few months ago.
The discussion was in telegram & not publicized, so I will summarize:

1. Porting existing SBUILDs
   This would be the easiest task, as in most of them I would only need to add a condition to use correct docker images & host-triplets.
   Especially for go/rust packages.

2. Docker Images
   As we use docker builder images, we would need to build these for riscv64, meant to run on a riscv64 host.
   This means https://github.com/pkgforge/devscripts/actions/workflows/build_gh_runner_images.yaml needs to run on riscv64 CI.

3. CI
   This is where everything falls apart.
   We need CI that runs on riscv64 for docker Images, for our ported SBUILDs. If we can, then that would be enough to run sbuilder & setup your own custom repo.
   But this is not yet possible. GitHub took years to finally add native arm64 runner images, I don't see them adding native riscv64 anytime soon.
   This leaves the only alternative: Self Hosted riscv64. But currently no major cloud provider provides riscv64 based VMS either.
   I also wouldn't personally invest in it because I want Package Forge to be financially independent & self sustainable.
   So unless someone sponsors us with riscv64 CI, this will not be possible.

• Why not use QEMU?
  I played around with it but found it too slow. Docker builds already take 4-5 hrs for most of our images, even for native aarch64/x86_64. Adding riscv64 via qemu will always make the action timeout after 6hrs.

---

Unless I get a board myself, or cloud riscv becomes more affordable & available, this will not be possible.

[xplshn]

I think it is far more useful to provide support for kernels other than Linux

But at the same time, if RV64 were supported, bincache/pkgcache would immediately be popular among RiscV enthusiasts, as there aren't much places where they can get prebuilt software for their systems

[Kreijstal]

@alitariq4589 do you think you could sponsor this project with https://cloud-v.co/

[Azathothas]

I would still appreciate if you fill the form for my own record

I filled it with this email: [email protected]

We are scaling our resources as time passes.

Ah, that's great to hear.
I read https://cloud-v.co/blog/risc-v-1/benchmarking-risc-v-milk-v-pioneer-box-with-spec-cpu2017-multicore-intrate-17, I will compare it with github's default runner once I have access to see where it stands.

Additionally, does the CI run on GitHub CI or Jenkins (or something other)?

CI runs on GitHub.
Once we have access to one of your machine, we will likely use: https://github.com/dkurt/github_actions_riscv to provision it as a self-hosted machine for each run.
Unless you already have integrations built-in...?
Like runs-on or ubicloud

[alitariq4589]

Hello @Azathothas ,

Sorry for the delay. I got caught up in some other stuff at work. Will provide u the ssh credentials tomorrow.

I think it will be good if you set the github runner yourself. I am also trying to add a flow for github runner for opensource community access but that will take some time (a few days, or week maybe).

[Azathothas]

Hi @alitariq4589,
I received the ssh credentials. Thank you.
I wanted to ask if it would be possible to run docker there, perhaps a rootless podman if privilege escalation is a concern?
Currently, docker on the host needs root, which my user ajam has no access to.

Also, is there a sponsor brand logo which we can use to put cloud-v as sponsor in our readme?
Similar to homebrew: https://github.com/Homebrew/brew?tab=readme-ov-file#sponsors

I am also trying to add a flow for github runner for opensource community access but that will take some time (a few days, or week maybe).

The most important to-do would be:

• Ephemeral runners (so they are deleted upon completion & booted fresh on next run) similar to GitHub Runners
• root access (through a rootless podman or some other mechanism)
• docker in docker (in case you do go through a rootless podman, this would be easy) support, I don't know if this would be feasible given the performance penalty of riscv

[alitariq4589]

@Azathothas, I have added your user ajam to docker group. You should be able to run docker now.

Also, is there a sponsor brand logo that we can use to put Cloud-V as a sponsor in our readme?
Similar to homebrew: https://github.com/Homebrew/brew?tab=readme-ov-file#sponsors

We do have a brand logo associated with Cloud-V (https://cloud-v.co).

Ephemeral runners (so they are deleted upon completion & booted fresh on next run) similar to GitHub Runners

I was hoping to use Docker (like GitLab allows using running as the docker executors). But GitHub actions runner package doesn't allow any such thing. Security and isolation is a big issue in providing access of runners to users. I am open to any ideas for this. My current idea is to put a note on the website like "Please follow the GitHub security practices while using runners".

root access (through a rootless podman or some other mechanism)

I am thinking to provide root access through lxc server. The main issue is to figure out a way to intercept the github runner API requests to run the runner inside unprivileged lxc container for users.

docker in docker (in case you do go through a rootless podman, this would be easy) support, I don't know if this would be feasible given the performance penalty of riscv

Good idea. I will try this. I am assuming this involves running github runner in Docker and then running Docker for each new job (correct me if I am wrong)

[Azathothas]

I have added your user ajam to docker group. You should be able to run docker now.

Thank you!

We do have a brand logo associated with Cloud-V (https://cloud-v.co/).

Great, I will be adding it under the sponsors section.
I will also write a detailed post once we actually add proper riscv support over @https://blog.pkgforge.dev/
In the meantime, if you use discord, please join: https://discord.gg/djJUs48Zbu
That's where most of our discussions happen.

I am open to any ideas for this

Back when we were smaller, I used to pay for a couple rented compute from Netcup & used them as self-hosted runners.
There's still some old leftover code: https://github.com/pkgforge/devscripts/tree/main/Github/Runners
What I did was, run a podman container with ubuntu-systemd-base (this was 99% same as github's default runner image) with user runner and an autogenerated container id (also similar to github runners).
This not only let me do everything I could on official runners, but also allowed me to use docker/podman inside it (true docker in docker) without risking container escape.
And this podman container would be started/deleted as per request.

Also, I would advise against using docker to do this, because there will be a lot of pain (no proper systemd, and high container escape risks)

[Azathothas]

Superseded by: #198