firefox 65 #54504
firefox 65 #54504
Conversation
infinisil
added
the
2.status: wait-for-upstream
|
It seems that Firefox65 will require an additional NSS version bump. The version isn't released yet thought :/ https://hg.mozilla.org/mozilla-unified/rev/3c3a040d5e3f This PR will have to bump the NSS version once it is released. So much for trying to prepare for a release ahead of time... |
|
It seems that Firefox65 will require an additional NSS version bump. The version isn't released yet thought :/
An enthusiastic optimist could try also packaging the current tip-of-the-branch NSS just to check NSS isn't requiring some other bumps…
(I am not passing value judgements on ethusiastic optimism, though)
|
|
That is what I tried so far. I am running into issues with the PEM support we've been patching in. The patch (https://dev.gentoo.org/~polynomial-c/mozilla/nss-3.15.4-pem-support-20140109.patch.xz) doesn't apply anymore. I plan to invest some time this evening to figure out why and what has to be changed. |
Firefox >=65 will depend on icu >=63. All the older firefox versions (and derived packages) seem to work fine with this change. Also the system path environment patch will fail to apply since there was a trivial whitespace change in the source file. By adding `-l` to patch we can avoid having to track two patches that do basically the same. Having patchFlags per file without resorting to pre-/postPatch would be nicer but there doesn't seem to be a facility for that right now.
There have been some more changes to the source tree which broke the buildconfig patch. This commit adds another patch that can be used for the future versions. Once all the flavors are based off a new(ish) firefox release we can remove the old patch.
GrahamcOfBorg
added
10.rebuild-darwin: 501+
10.rebuild-linux: 501+
and removed
10.rebuild-darwin: 1-10
10.rebuild-linux: 11-100
labels
|
Now that I had the chance to look into this it turned out the release tarball just works fine with our patches. This branch is ready to merge. The question is if we still want to merge it into staging or not... @vcunat stated that the rebuild times (on amd64) aren't that bad anymore. Any opinions? |
infinisil
removed
the
2.status: wait-for-upstream
|
It is an attractive idea that all Firefox bumps are security fixes and we are better off putting them in master if at all feasible; does it make any sense / does it create too much work to split NSS versions in master, and push the full switch to the new one into staging? |
|
For the unstable/master case I hesitate with staging since it could take a while until that hits. There are commonly bigger mass-rebuilds on The idea to "split" it could work. At the same time one could argue that using the bundled nss would work just as well for that case. Why even bother packaging the dependencies then? I am mostly worried about darwin and aarch64 rebuild speeds. We should not waste days(?) of recompiling everything that happend on a staging branch just because amd64 is sufficiently fast right now. For the case of stable branches (e.g. 18.09) I do not hesitate to put it into staging there since those are very low noise and (usually) do not carry other high(er) risk changes that could delay the whole process. |
|
Last year we had the case of a few weeks for a requirement to bump FireFox. That feels wrong.
Sure.
The idea to "split" it could work. At the same time one could argue that using the bundled nss would work just as well for that case. Why even bother packaging the dependencies then?
Well, we split a lot of things for various reasons. The difference is a clear path to restoring convergence (hopefully without even any extra rebuilds)
I am mostly worried about darwin and aarch64 rebuild speeds. We should not waste days(?) of recompiling everything that happend on a staging branch just because amd64 is sufficiently fast right now.
From the point of view of combining rebuilds, staging sounds more promising target for the full nss upgrade, or am I missing something?
|
|
I completely agree with you. It is just the question about how fast staging is in regards to how urgent an upgrade might be. Not saying this one is particular urgent. There is at this very moment a discussion on IRC (#nixos-dev) regarding what amount of rebuilds might be okay for hitting master. By those rules this would be too large for master and must go through a staging process. (I omitted values here since they might change). |
|
This PR is actually what motivated me to start the discussion initially (in #nixos-borg). #nixos-borg logs, #nixos-dev logs @LnL7 counted ~25k packages for x86_64-linux. I think as a general rule, above 5k packages should go to staging. By this logic (this PR has 2.5k x64_64-linux rebuilds), and because we'd like to have Firefox as fast as possible, I think this can go to master. |
|
As far as I can see this should be all. Firefox(-bin) works just fine. The other packages (tor, esr, …) are being built yet another time. I do not expect any new build failures. Feel free to merge :-) |
|
👍 for your merging directly to master. Staging(-next) certainly didn't seem waiting for Hydra in the past few days. |
Motivation for this change
Preparding the master branch for the upcoming firefox 65 release (scheduled for 2019-01-29). There will be another PR for the 18.03 branch as welll
This is my WIP version for firefox 65. The beta attribute should be
removed and the "normal"
firefoxattribute should be updated afterthe release.
There have been some more changes to the source tree which broke the
buildconfig patch. This commit adds another patch that can be used for
the future versions. Once all the flavors are based off a new(ish)
firefox release we can remove the old patch.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)only executed the firefox binaries, I do not expect any failures of the tor browser though..
nix path-info -Sbefore and after): almost the same, was even smaller by about 100kB