New architecture: riscv64

Please add support for installing and publishing of the riscv64 architecture. Currently on the snap store it is not available yet:

It would be nice to enable the riscv64 architecture for the node22 and maybe also the edge channel of the snap.

Whoever looks into this, the same process was followed for other arches and documented in https://github.com/nodejs/snap?tab=readme-ov-file#adding-new-release-lines with additional context provided here: #73 (comment)

Thanks

Yeah, I did this already, don't remember when, maybe it was a response to this request and I just never followed up here, but they fail. You might want to follow up on build errors and figure out what needs to be patched to make it work. Here's the latest failed edge build: https://launchpad.net/~openjs/+snap/nodeedge/+build/2876560

Here's the latest failed edge build: https://launchpad.net/~openjs/+snap/nodeedge/+build/2876560

This build failed during a snapcraft pull of something, probably something transient. The riscv64 build that failed before on the same day shows legitimate compilation failures with openssl. Maybe things have improved since then?

@jugmac00

I'm not sure why, but the riscv64 builds on Launchpad appear to be pretty frequently getting that ChunkedEncodingError. I'm not getting that locally (I'm getting different build errors instead), so I wonder if it's based on some interaction with requests, the proxy that Launchpad uses, and nodejs.org.

I've reported the presentation issue that's hiding the details here: canonical/craft-parts#1396

@jugmac00 is there a way for the Launchpad team to examine further what's going on with this network traffic?

daemon.start: the LXD UI not (yet) available on `riscv64`

Drop `ui.enable` config (#1040)

daemon.start: the LXD UI not (yet) available on `riscv64`

@xypron

@xypron this issue is blocking enabling the LXD UI on RISC-V. Maybe you can help us to get this unblocked?

What is the exact issue now?
Reading this thread it seems that the problem was more around Launchpad having network issues building the snap on riscv64 than about riscv64 itself.

Launchpad riscv64 builders are for now emulation VMs running on amd64 hardware, so they can be really slow and have more transient failures.
If we have consistent build issues that are seemingly transient like network errors, maybe it needs a quota adjustment or something similar.

Latest build issue on Launchpad is:

Downloading package: libgcc-s1
[19/Feb/2026:10:31:20 +0000] "GET http://ftpmaster.internal/ubuntu/pool/main/g/gcc-14/libgcc-s1_14.2.0-4ubuntu2%7e24.04.1_riscv64.deb HTTP/1.1" 200 62944 "-" "Debian APT-HTTP/1.3 (2.8.3) non-interactive"
Extracting stage package: libstdc++6
Extracting stage package: libgcc-s1
None
Detailed information: ChunkedEncodingError
Full execution log: '/root/.local/state/snapcraft/log/snapcraft-20260219-102638.197580.log'
Build failed
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lpbuildd/target/build_snap.py", line 325, in run
    self.pull()
  File "/usr/lib/python3/dist-packages/lpbuildd/target/build_snap.py", line 252, in pull
    self.run_build_command(
  File "/usr/lib/python3/dist-packages/lpbuildd/target/operation.py", line 70, in run_build_command
    return self.backend.run(args, cwd=cwd, env=full_env, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/lpbuildd/target/lxd.py", line 735, in run
    subprocess.check_call(cmd, **kwargs)
  File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['lxc', 'exec', 'lp-noble-riscv64', '--env', 'LANG=C.UTF-8', '--env', 'SHELL=/bin/sh', '--env', 'http_proxy=http://10.10.10.1:8222/', '--env', 'https_proxy=http://10.10.10.1:8222/', '--env', 'HTTP_PROXY=http://10.10.10.1:8222/', '--env', 'HTTPS_PROXY=http://10.10.10.1:8222/', '--env', 'GIT_PROXY_COMMAND=/usr/local/bin/lpbuildd-git-proxy', '--env', 'SNAPPY_STORE_NO_CDN=1', '--env', 'LAUNCHPAD_INSTANCE=production', '--env', 'LAUNCHPAD_SERVER_URL=launchpad.net', '--env', 'SNAPCRAFT_LOCAL_SOURCES=1', '--env', 'SNAPCRAFT_SETUP_CORE=1', '--env', 'SNAPCRAFT_BUILD_INFO=1', '--env', 'SNAPCRAFT_IMAGE_INFO={"build-request-id": "lp-106871156", "build-request-timestamp": "2026-02-19T07:30:12Z", "build_url": "https://launchpad.net/~openjs/+snap/nodeedge/+build/3060731"}', '--env', 'SNAPCRAFT_BUILD_ENVIRONMENT=host', '--', '/bin/sh', '-c', 'cd /build/node && linux64 snapcraft pull']' returned non-zero exit status 1.

Reproducing on local hardware, extracting stage package part succeeds. Although that part takes more than 300s.
Afterwards, the build fails around yarn download:

ubuntu@p550:~/Documents/node-snap$ snapcraft pack
Network request error: network request failed (request=<PreparedRequest [GET]>, response=None).
Detailed information: Source: 'https://yarnpkg.com/latest.tar.gz'
Recommended resolution: Check network connection and source, and try again.
Failed to run snapcraft in instance
Full execution log: '/home/ubuntu/.local/state/snapcraft/log/snapcraft-20260220-091113.768083.log'

This is also weird, because I can download that file on my host computer. But that does not seem strictly riscv64 related.

Investigating a bit more, with snapcraft pack --debug, it seems I cannot access the internet inside the container. When I try to curl or ping, it does not work and hangs infinetely. However, I can apt install packages. That seems very weird.

Going a bit further, it seems I only have IPv6 connectivity inside the LXC container. Could that be the root of the issue? My apt locally uses IPv6, but with the proxy on Launchpad it will use IPv4.

snapcraft-node-riscv64-525820 ../project# curl -v https://vhaudiquet.fr
* Host vhaudiquet.fr:443 was resolved.
* IPv6: (none)
* IPv4: 83.113.30.49
*   Trying 83.113.30.49:443...
^C
snapcraft-node-riscv64-525820 ../project# curl -v https://google.com
* Host google.com:443 was resolved.
* IPv6: 2a00:1450:4007:80d::200e
* IPv4: 172.217.22.174
*   Trying 172.217.22.174:443...
*   Trying [2a00:1450:4007:80d::200e]:443...
* Connected to google.com (2a00:1450:4007:80d::200e) port 443

Then something in snapcraft.yaml or somewhere else must be lacking for IPv4 connectivity. This is the first time I see something like this. Maybe it is a misconfiguration on my part too.

I will try to look into it a bit more, but if someone can reproduce and confirm that the root issue is lack of IPv4 in the container, at least we know what we are trying to fix.

EDIT: It appears that this might have been a specific issue with the riscv board I was using to test. So the root issue might not be that. If I have the time, I will try to reproduce locally again using another board.

If you need support from Launchpad, please use the official ways for support, see https://documentation.ubuntu.com/launchpad/help/ (or via Mattermost on the ~launchpad channel for Canonical employees). We have a dedicated engineer on support who can focus on ad hoc help.

When we need to debug a build, you would need to coordinate with us to deactivate the garbage collection of the builder vm after the build failed.

@edlerd

@edlerd Could you, please, indicate what blocks enabling riscv64 builds of the node.js snap.

A local build shows

::   CC(target) /root/parts/node/build/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o
:: gcc-14: error: unrecognized command-line option ‘-m64’
:: make[1]: *** [deps/openssl/openssl.target.mk:1324: /root/parts/node/build/out/Release/obj.target/openssl/deps/openssl/openssl/ssl/bio_ssl.o] Error 1

-m64 is an x86 compiler flag.

Navigation Menu

Repository navigation

New architecture: riscv64 #77

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

New architecture: riscv64 #77

Description

Activity

simondeziel commented on Jun 10, 2025

rvagg commented on Sep 1, 2025

simondeziel commented on Sep 1, 2025

lengau commented on Nov 14, 2025

edlerd commented on Feb 19, 2026

vhaudiquet commented on Feb 20, 2026

jugmac00 commented on Feb 23, 2026

xypron commented on Jun 17, 2026

xypron commented on Jun 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions