[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Simon McVittie <smcv@debian.org> 于2018年8月30日周四 下午6:09写道:
>
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: librsvg@packages.debian.org, rustc@packages.debian.org, debian-mips@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


Reply to: