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

Re: [Pkg-rust-maintainers] Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch



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-maintainers@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


Reply to: