Bug#907626: release.debian.org: Release status of non-Rust architectures?

Simon McVittie smcv at debian.org
Thu Aug 30 11:05:46 BST 2018


Package: release.debian.org
Severity: normal
X-Debbugs-Cc: librsvg at packages.debian.org, rustc at packages.debian.org, debian-mips at lists.debian.org
Affects: src:librsvg

The librsvg package in testing/unstable is currently lagging behind
upstream by 1 year (2.40.x vs. 2.44.x) and I'm concerned that if there
are security vulnerabilities in the lifetime of buster, we will not
necessarily be able to fix them. Since 2.40.20, the 2.40.x branch is no
longer supported by its upstream developer "except for emergencies".

After 2.40.x, upstream started converting the internals of librsvg from
C to Rust, for better memory-safety in the many interlocking parsers
involved in interpreting SVGs. However, Debian still has release
architectures that do not have cargo/dh-cargo/rustc (namely the 32-bit
mips ports, mips and mipsel), so we cannot update to 2.42 or 2.44.
Many of the ports architectures also don't have Rust available.

Debian's default web browser, firefox-esr, also requires Rust and is
also unbuildable on the 32-bit mips ports.

What's the plan for non-Rust architectures? Are mips and mipsel intended
to be supported for the lifetime of buster?

Would it be acceptable to the release team to do architecture-specific
removals of librsvg and its (many) reverse dependencies from testing on
mips and mipsel?

Another possible solution would be to upload a separate librsvg-2.40
source package that only builds binaries for mips and mipsel (and any
other non-Rust-capable ports that want it). However, the GNOME team
do not have enough developer time or mips expertise to maintain such
a package, it would become useless as soon as dependent packages start
requiring features of newer librsvg versions, and it would have the same
security, bug and upstream maintenance concerns as the current librsvg
2.40.x in unstable.

I've been doing some triaging, and a lot of open librsvg bugs are present
in unstable but fixed in experimental, so I'm keen to update to the new
upstream release if we can. Lack of Rust on mips and mipsel is not the
only blocker, but it is the main blocker. (We also have a FTBFS during
"make check" on ppc64el, reported upstream, and endianness-related test
failures on s390x, which will be selectively ignored in the next upload
because the bug exhibited by those tests does not seem RC.)

Thanks,
    smcv



More information about the pkg-gnome-maintainers mailing list