Debian GNU/Linux riscv64 port in mid 2019
It's been a while since last post (Talk about the Debian GNU/Linux riscv64 port at RISC-V workshop), 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
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
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
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!
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
page 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
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 :-)