Bug#907626: release.debian.org: Release status of non-Rust architectures?
On 10/10/2018 12:47, Simon McVittie wrote: > On Wed, 10 Oct 2018 at 10:21:15 +0200, Emilio Pozuelo Monfort wrote: >> Any progress on that? AFAIK the problem is the memory address space limit on >> mips(el). If we can get that fixed I'm afraid we'll have to resort to partial >> removals for buster. > > Would you be willing to consider similar architecture-specific > removals on ppc64el (and the rest of the powerpc family, but the > big-endian flavours are non-release architectures anyway), if > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895723 cannot be > resolved? > > (We also have a librsvg test failure on mips64el, but I think that's > resolvable, even if only by increasing the tolerance for minor rendering > differences.) Thankfully all release architectures now have rust, and the librsvg issue on ppc got solved/worked around, so this bug is moot. Thus closing it. Cheers, Emilio
Bug#907626: release.debian.org: Release status of non-Rust architectures?
On Wed, 10 Oct 2018 at 10:21:15 +0200, Emilio Pozuelo Monfort wrote: > Any progress on that? AFAIK the problem is the memory address space limit on > mips(el). If we can get that fixed I'm afraid we'll have to resort to partial > removals for buster. Would you be willing to consider similar architecture-specific removals on ppc64el (and the rest of the powerpc family, but the big-endian flavours are non-release architectures anyway), if https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895723 cannot be resolved? (We also have a librsvg test failure on mips64el, but I think that's resolvable, even if only by increasing the tolerance for minor rendering differences.) smcv
Bug#907626: release.debian.org: Release status of non-Rust architectures?
On 30/08/2018 16:02, YunQiang Su wrote: > Simon McVittie 于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. Any progress on that? AFAIK the problem is the memory address space limit on mips(el). If we can get that fixed I'm afraid we'll have to resort to partial removals for buster. Cheers, Emilio
Bug#907626: release.debian.org: Release status of non-Rust architectures?
Simon McVittie 于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
Bug#907626: release.debian.org: Release status of non-Rust architectures?
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
