Simon McVittie <s...@debian.org> 于2018年8月30日周四 下午6:09写道: > > 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. >
rust should work on 32bit mips. The only work is bootstrap. I am working on it. > 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 > -- YunQiang Su