On August 2, 2020 6:21 pm, Moritz Mühlenhoff wrote: > On Tue, Jul 28, 2020 at 10:17:35PM +0200, Emilio Pozuelo Monfort wrote: >> Hi, >> >> On 21/08/2019 07:45, Salvatore Bonaccorso wrote: >> > Hi Holger, hi Emilio, >> > >> > [dropping debian-devel list] >> > >> > On Mon, Aug 19, 2019 at 11:01:13PM +0200, Moritz Mühlenhoff wrote: >> >> On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote: >> >>> Hi, >> >>> Firefox 68 will be the next ESR release series. With the release of >> >>> Firefox 68.2 >> >>> on October 22nd, support for ESR 60 will cease. >> >>> >> >>> ESR 68 will require an updated Rust/Cargo toolchain and build >> >>> dependencies not >> >>> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more). >> >>> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at >> >>> least no >> >>> requirement to bootstrap stage0 builds this time. >> >>> >> >>> If we want to continue to have Firefox/Thunderbird supported in >> >>> oldstable-security >> >>> after October, someone needs to step up to take care of backports to a >> >>> Stretch point >> >>> release before October 22nd (or in case of poor timing, we can also >> >>> release build >> >>> dependency updates via stretch-security). >> >> >> >> There hasn't been any visible movement on this, so unless someone steps >> >> up RSN, >> >> there'll be a headsup about the EOL in the next ESR 60 DSA, so that people >> >> have some advance warning. >> > >> > That would be really bad I guess both for users running stretch on >> > workstations for a while (we are affected for instance at work) and >> > for LTS as there were work so far by emilio to keep up firefox-esr and >> > thunderbird as well updated in jessie LTS. >> >> We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3 >> comes out. We have some time still, but if we want FF and TB to keep being >> supported, we'll have to do some toolchain backports as usual. >> >> Has someone started to look at this? >> >> I have taken a quick look and it looks like we need rustc 1.41 and cargo >> 0.31. >> We currently have: >> >> rustc | 1.34.2+dfsg1-1~deb9u1 | oldstable >> rustc | 1.34.2+dfsg1-1 | stable >> rustc | 1.44.1+dfsg1-1 | unstable >> >> cargo | 0.35.0-2~deb9u2 | oldstable >> cargo | 0.35.0-2 | stable >> cargo | 0.43.1-3 | unstable >> >> We may need other deps after those (such as an updated cbindgen or other >> modules) or some packages in order to build those (possibly LLVM 9, I'm not >> sure >> yet). > > I don't have time to work on this, I'm away for large parts of August, > but I had a look at what is needed: > > We'll need LLVM 9 (which was a straight rebuild on buster in my test), > wasi-libc (also a straight rebuild with LLVM 9) and updated rustc. Updating > rustc will require some intermediate rustc/cargo uploads as we can't build > 1.41 with 1.34.
all of those rustc versions should backport fine from their respective debian/* git tags with a backported LLVM, and as you said, backported wasi-libc for the more recent releases. I did the same for a Buster-based Debian downstream/derivative. 1.45 requires LLVM 10, not sure whether it's possible to build that with 9. LLVM 10 is a straightforward backport as well, so it's probably safer to go down that route if 1.45 is needed in Buster's lifetime. > We can also avoid these in the future by always bumping rustc to the > current version in point releases... building the needed rustc once with the bootstrap profile that downloads stage0, then re-building with that rustc might also be an option depending on policy? > I think we can reuse the same approach as before, by staging uploads > in -proposed-updates (or on stretch-security respectively) and then > configure the security chroots to use -proposed-updates until 10.6 > is eventually released. > > Cheers, > Moritz > > _______________________________________________ > Pkg-rust-maintainers mailing list > pkg-rust-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers >
