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

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch



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.

We can also avoid these in the future by always bumping rustc to the
current version in point releases...

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


Reply to: