Package: release.debian.org Severity: normal X-Debbugs-Cc: libr...@packages.debian.org, ru...@packages.debian.org, debian-m...@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