/Debian riscv64 port status

Debian riscv64 port status

It’s been a while since last post (Talk about the Debian GNU/Linux riscv64 port
and sometimes things look very quiet from outside even if the people on the
backstage never stop working. So this is an update on the status of this port
before the release of buster, which
should happen in a few weeks and which it will open the way for more changes
that will benefit the port.

The Big Picture

First, the big picture(s):

Debian-Ports All-time Graph, 2019-06-17

Debian-Ports All-time Graph, 2019-06-17

As it can be seen in the first graph, perhaps with some difficulty, is that the
percent of arch-dependent packages built for riscv64 (grey line) has been
around or higher than 80% since mid 2018, just a few months after the port was
added to the infrastructure.

Given than the arch-dependent packages are about half of the Debian[‘s main,
unstable] archive and that (in simple terms) arch-independent packages can be
used by all ports (provided that the software that they rely on is present,
e.g. a programming language interpreter), this means that around 90% of packages
of the whole archive has been available for this architecture from early on.

Debian-Ports Quarter Graph, 2019-06-17

Debian-Ports Quarter Graph, 2019-06-17

The second graph shows that the percentages are quite stable (for all
architectures, really: the peaks and dips in the graph only represent <5% of the
total). This is in part due to the freeze for buster, but it usually happens
at other times as well (except in the initial bring-up or in the face of severe
problems), and it really shows that even the second-class ports are in quite
good health in broad terms.

Note: These graphs are for architectures in the debian-ports
infrastructure (which hosts architectures not as well supported as the main
ones, the ones present in stable releases). The graphs are taken from the
buildd stats page, which also includes the
main supported architectures.

A little big Thank You

Together, both graphs are also testament that there are people working on ports
at all times, keeping things working behind the scenes, and that’s why from a
high level view it seems that things “just work”.

More in general, aside from the work of porters themselves, there are also
people working on bootstrapping issues that make bringing up ports easier than
in the past, or coping better when toolchain support or other issues deal an
important blow to some ports. And, of course, all other contributors of Debian
help by keeping good tools and building rules that work across architectures,
patching the upstream software for needs of several architectures at the same
time (endianness, width of basic types), many upstream projects are generic
enough that they don’t need specific porting, etc.

Thanks to all of you!

Next Steps

Installation on hardware, VMs, etc.

Due to several reasons, among them the limited availability of hardware able to
run this Debian port and the limited options to use bootloaders during all this
time, the instructions to get Debian running on RISC-V are not the best,
easiest, more elegant or very up to date. This is an area to improve in the
next months.

Meanwhile, there’s a Debian RISC-V’s wiki
with instructions
to get a chroot working in a HiFive Unleashed board as shipped, without
destroying the initial factory set-up.

Specially Vagrant Cascadian and Karsten Merker have been working on the area of
booting the system, and there are instructions to set-up a riscv64 Qemu
boot it with u-boot and
Karsten is also working to get support in debian-installer, the main/canonical
way to install Debian systems (perhaps less canonical nowadays with the use of
OS images, but still hugely important).

Additionally, it would be nice to have images publicly available and ready to
use, for both Qemu and hardware available like the HiFive Unleashed (or
others that might show up in time), but although there’s been some progress on
that, it’s still not ready and available for end users.

The last 10%+ of the archive

So, what’s the remaining work left to have almost all of the archive built for
this architecture? What’s left to port, as such?

The main blockers to get closer to 100% of packages built are basically LLVM and
Rust (which, in turn, depends on LLVM).

Currently there are more than 500 packages from the Rust ecosystem in the
archive (which is about 4%), and they cannot be built and used until Rust has
support for the architecture. And Rust needs LLVM, there’s no Rust compiler
based on GCC or other toolchains (as it’s the case of Go, for example, in which
there’s a gcc-go compiler in addition to their own golang-go), so this is
the only alternative.

Firefox is the main high-level package that depends on Rust, but many packages
also depend on librsvg2 to render SVG images, and this library has been
converted to Rust. We’re still using the C version for that, but it cannot be
sustained in the long term.

Aside from Rust, other packages directly depend or use LLVM to some extent, and
this is not fully working for riscv64 at the moment, but it is expected that
during 2019 the support of LLVM for riscv64 will be completed.

There are other programming language ecosystems that need attention, but they
represent a really low percentage (only dozens of packages, of more than 12
thousand; and with no dependencies outside that set). And then, of course,
there is long tail of packages that cannot be built due to a missing dependency,
lack of support for the architecture or random failures — together they make a
substantial number of the total, but they need to be looked at and solved almost
on a case-by-case basis.

Finally, when the gates of the unstable suite open again after the freeze for
the stable release of buster, we will see tools with better support and
patches can be accepted again to support riscv64, so we can hope that things
will improve at a faster rate soon 🙂