[Feature]: works on Linux on RISCV64 too ... so mention that too?

[sanderjo]

Prerequisites

• I have searched the existing issues and this feature has not been requested before

Feature Area

Other

Problem Statement

Works on Bianbu Linux on RISCV64 too ... so mention that too?

Bianbu Linux is based on Ubuntu

cd git/
git clone https://github.com/armbian/imager.git && cd imager
# bash scripts/setup/install.sh
sudo apt install libglib2.0-dev libgtk-3-dev libwebkit2gtk-4.1-dev libayatana-appindicator3-dev librsvg2-dev -y
npm install
npm run tauri:dev

Proposed Solution

mention it as working on RISCV64 ... ?

Alternatives Considered

What should I say?

How important is this feature to you?

Nice to have

Use Case

use armbian imager on my Spacemit K3 riscv64 system

Mockups / Examples

Additional Context

No response

[sanderjo]

Ah, yes: bash scripts/setup/install.sh gave Unsupported distribution: bianbu.

So workaround: manual sudo apt install ....

I guess I can change that in scripts/setup/install-linux.sh ... BRB

║                                                            ║
║        Armbian Imager - Dependency Installation           ║
║                                                            ║
╚════════════════════════════════════════════════════════════╝

ℹ Detected OS: linux

⚠ Linux installation requires root privileges (sudo)

Do you want to proceed with installation? [y/N] y

ℹ Starting installation process...

ℹ Requesting root privileges...
ℹ Armbian Imager - Linux Dependencies Installation

ℹ Detected distribution: bianbu
ℹ Updating package list...
⚠ Package update skipped for bianbu
ℹ Installing system dependencies...
✗ Unsupported distribution: bianbu
ℹ Please manually install the following dependencies:
  - libglib2.0-dev (or glib2-devel)
  - libgtk-3-dev (or gtk3-devel)
  - libwebkit2gtk-4.1-dev (or webkit2gtk4.1-devel)
  - libayatana-appindicator3-dev (or libappindicator-gtk3-devel)
  - librsvg2-dev (or librsvg2-devel)

[sanderjo]

with the patch below, bash scripts/setup/install.sh works on Bianbu on RISCV64!

sander@spacemitk3:~/git/imager/scripts/setup$ sed -i.bak 's/\[ "$DISTRO" = "debian" \]/& || [ "$DISTRO" = "bianbu" ]/g' install-linux.sh

sander@spacemitk3:~/git/imager/scripts/setup$ diff install-linux.sh.bak install-linux.sh
58c58
< if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "zorin" ]; then
---
> if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "bianbu" ] || [ "$DISTRO" = "zorin" ]; then
68c68
< if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "pop" ] || [ "$DISTRO" = "linuxmint" ] || [ "$DISTRO" = "zorin" ]; then
---
> if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "bianbu" ] || [ "$DISTRO" = "pop" ] || [ "$DISTRO" = "linuxmint" ] || [ "$DISTRO" = "zorin" ]; then
138c138
<     if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "pop" ] || [ "$DISTRO" = "zorin" ]; then
---
>     if [ "$DISTRO" = "ubuntu" ] || [ "$DISTRO" = "debian" ] || [ "$DISTRO" = "bianbu" ] || [ "$DISTRO" = "pop" ] || [ "$DISTRO" = "zorin" ]; then

[SuperKali]

Hi, it's too early to talk about RISC-V support. For now, we're leaving it out because otherwise we'd have to deal with issues every time something breaks on the GitHub CI side, and their runners are currently based on Spacemit K1 that they're very slow. We'll revisit this as soon as they release K3-based runners.

[gounthar]

Totally fair, and I am not trying to reopen the decision. Waiting for K3 runners makes sense to me, and you have a much better feel for what the CI can realistically absorb than I do.

Just dropping a data point in case it is useful down the line, no rush at all.

@sanderjo nice, I saw you already have it running on the K3. Building on that, I tried the release-packaging side on a Banana Pi F3 and got actual packages out: a .deb (Architecture: riscv64) and a .rpm, with the binary running (OS: linux riscv64).

On the CI-burden side, which is what you flagged: the painful part on riscv64 is the frontend, not the backend. Vite 8 bundles with rolldown, rolldown has no riscv64 native binding, and its wasm fallback crashed for me on riscv64 Node. The Rust backend builds fine. So I did a split build: build the frontend once on a normal x64 runner (where rolldown works) and pass dist/ as an artifact, then only the backend compiles on the riscv64 runner. That keeps the slow and fragile half off the K1 entirely. The riscv64 job is basically npm ci (which pulls the prebuilt @tauri-apps/cli-linux-riscv64-gnu, so no long toolchain compile) plus tauri build --bundles deb rpm. AppImage stays out, since there is no riscv64 AppImage runtime upstream yet.

It is still slower than x64, no argument there, so K3 runners will genuinely help. But if you ever decide it is worth it, I am happy to own the riscv64 job myself so it is not extra maintenance on your side. Whenever the timing is right for you, or not at all.

[SuperKali]

Totally fair, and I am not trying to reopen the decision. Waiting for K3 runners makes sense to me, and you have a much better feel for what the CI can realistically absorb than I do.

I was discussing this with Igor over the past few days, and we agreed to avoid moving forward with it for now. As I explained above, K1 is not powerful enough, and from what Igor told me, the GitHub runners are also problematic. Since I do not want to make things more complicated than they need to be, the best solution is to wait and hope that the K3 runners will actually be a significant improvement over the previous ones and not have the same issues.

On the CI-burden side, which is what you flagged: the painful part on riscv64 is the frontend, not the backend. Vite 8 bundles with rolldown, rolldown has no riscv64 native binding, and its wasm fallback crashed for me on riscv64 Node. The Rust backend builds fine. So I did a split build: build the frontend once on a normal x64 runner (where rolldown works) and pass dist/ as an artifact, then only the backend compiles on the riscv64 runner. That keeps the slow and fragile half off the K1 entirely. The riscv64 job is basically npm ci (which pulls the prebuilt @tauri-apps/cli-linux-riscv64-gnu, so no long toolchain compile) plus tauri build --bundles deb rpm. AppImage stays out, since there is no riscv64 AppImage runtime upstream yet.

I think I figured out who you are. You are the person who wrote the article about bringing the imager to RISC-V, right?

In any case, yes, we are considering integrating the imager with RISC-V as well. It would make sense, especially since we already support that architecture. However, as we have often mentioned, the ecosystem is still quite immature at the moment, especially with the current SoCs available.

I do not even have the Spacemit K3 yet. I am still using the MuseBook, so I do not really have a way to evaluate how fast and efficient these K3 chips actually are.

Regarding the Spacemit K1, I basically put it aside because it is too slow, and I do not want to spend more time on it. The K3, on the other hand, is something I am very interested in testing, but unfortunately nobody wants to send me one :)

It is still slower than x64, no argument there, so K3 runners will genuinely help. But if you ever decide it is worth it, I am happy to own the riscv64 job myself so it is not extra maintenance on your side. Whenever the timing is right for you, or not at all.

Definitely, if I somehow manage to get my hands on a K3 (which I highly doubt, knowing my luck :) ), I will run some tests to understand how long it takes to compile. That would definitely help me get a better idea of what I would be dealing with and what to expect in terms of performance.