Hi,
Why is Firefox still not available in the current version 73.0?
For months updates for Firefox have been coming very late. What can be changed?
Thanks for the information
For months updates for Firefox have been coming very late. What can be changed?
Let me first try to tell you what I personally currently do regarding
updating Firefox:
For one it is mostly me and @taku0 working on this. Nobody is paid for
this and we since about 6 months or so my motivation to contribute to
nixpkgs has been going down for various reasons…
Ever since I picked up maintainership of Firefox I try to get everything
in-line for the updates weeks/days ahead of time. The main complication
here is that Firefox is very picky about it’s dependencies. It almost
always requires the latest rustc version, NSS, Sqlite, ….
On unstable that involves sending a bunch of commits throught staging
days before the release so we do not have a mass rebuild on master on
release day. Thankfully a few fellow maintainers are also bumping these
ruglary so I almost never have to touch the whole pack of dependencies
that Firefox insist on.
For the stable branches we used to do it similar to unstables staging
but at least since 19.09 or even 19.03 I am maintaining additional
versions of the libraries that Firefox needs on the stable branch. This
is both easier and also harder. We do no longer rist breaking large
parts of other packages (e.g. stable sqalachemy with a newer sqlite
etc.).
For the FF 73 update we needed a newer version of rustc on 19.09. The
rustc expression on master did change sufficienlty enough so that
backporting a newer rustc is no longer just cherry-picking or copying a
folder. I finally got to do that on Sunday/Monday.
Even with preparing things weeks in advance it might be that Mozilla
releases a new NSS version just the day of the release or the day
before. That then adds a bunch of overhead due to the requirement of a
staging cycle etc… Very often that can be “accelerated” by knowing how
severe the security issues are. Sadly the changelog is often not
available before the evening (EU TZ) of the Tuesday after the release.
Most of the time I’ve to ping someone personally to get a 2nd opinion on
the PR to get it through faster. I hesitate to just push those changes
to any branch without peer-review as the package is of high enough
profile that users would hate us forever if we destroy their profiles 
Regarding timing things so they arrive on time:
I usually have Mozillas Release Calendar
(Firefox Release Calendar) as part of my
private journal so I am reminded when new versions will arrive. That
helps me build up some pressue/motivation to look at it again. I can
also recommend watching the changelog repo
(GitHub - mozilla/release-notes: Release notes and system requirements for our various Firefoxen) to get a slightly earlier
look at what is happening.
What can be improved:
I don’t really know. I would appreciate more people testing early
version of packages. I haven’t gotten around to prepare them early for a
few releases now. I usually try to have the update ready on Sunday
evening so that we can test it. Sadly that doesn’t always work out. For
one the release tarballs might not be there yet and another reason might
be a last minute dependcy bump on Mozllas side causing other packages to
be touched and updated again.
I have also been thinking of simply suggesting not having a non-esr
variant on a stable NixOS release since those tend to cause most of the
work. The ESR releases are mostly just bumping version and hash.
Why is Firefox still not available in the current version 73.0?
- nixos-19.09
- firefox-72.0.2
Looking for feedback since about yesterday when I finally had motivation
again to sit down and tackle the 19.09 variant (and backporting rustc): [19.09] firefox 73 by andir · Pull Request #80327 · NixOS/nixpkgs · GitHub
If someone other then me can confirm that it works for them I am very
happy to merge that.
P.S.: Some feedback suddenly accumulated there so that should go out in
the next 19.09 channel bump.
- nixos-unstable
- firefox-72.0.2
- nixpkgs-unstable
- firefox-72.0.2
Firefox had been updated on master very close the official release:
firefox: 72.0.3 -> 73.0 by andir · Pull Request #79786 · NixOS/nixpkgs · GitHub.
Unfortunately hydra did have a bit of an issue with the master and 20.03
branch: Hydra: nixos/release-20.03 and unstable fails to evaluate · Issue #79907 · NixOS/nixpkgs · GitHub
That probably made us accumulate a few more breakages (at once) then
usual. We have to work through fixing them in order to advance the
channel. You can have a look at the evolution of build failures over the
last couple of days: https://hydra.nixos.org/jobset/nixos/trunk-combined
As we speak there is a new collection of Firefox bumps (73.0 → 73.0.1)
and I’d appreciate any reviewers and testers
Thank you for taking the time to answer in such detail
I see the problem from a user’s point of view and there are several days until the update is available.
Thanks for all the work!
Thanks for the effort @andir. Having seen the last releases along with the NSS and sqlite requierments, convinced me that we should only keep ESR on stable, or at least push for it and have the freedom to mark latest as insecure when its too hard to update (and there indeed is a security issue).
@andir, I want to chime in with the thanks. Every now and then I try to do that work when I notice an update, but you’re usually a lot quicker than me and easily pass me, which is a good thing, especially when I’m busy with my work other stuff I cannot shift around.
I typically use firefox-bin for exactly those backporting reasons, but having a working build is worth a lot.
I also wanted to thank you for your work @andir! I knew that Firefox was a large and complex beast, but I did not know the extent of the work that has to be put into the maintenance of Firefox. I now also understand the motivation to stick with ESR releases for NixOS releases much better.
Maybe something like a team of 5 or so people you could ping could help with that.
I would be willing to compile and test firefox on release and master, for example. I have to build it anyways, because I patch it.
As for why I have not done that those past releases and given you feedback on the PRs: I simply don’t follow all PRs that closely and therefore did not see them. I assume most people don’t, so even if they are willing to help you, they just didn’t see your PRs.
So what I want to say is, thanks a lot for your work @andir and feel free to ping me on future releases.
Since a few people offered to review PRs here is todays update:
I will definitely give it a review later today since I am interested in the hardware-accelerated video playback!
Four weeks later there is another round of PRs to review: