1347932 - Land NSPR 4.14 into FF 54

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Kai Engert (:KaiE:)]

Against the usual NSPR release rules, local patches have been landed into the Mozilla tree.

- parts of the changes requested in bug 1313612 have already been landed
  with bug 1288308, and have been released with Firefox 52 already.

- bug 1331810 was landed into unreleased FF 54

We should clean this up, by creating a NSPR 4.14 release, which gets landed into FF aurora 54.

This seems to be the safest approach.

I don't what happens if Linux distributions use Firefox 52 with an NSPR system package, that lacks the NSPR commits from bug 1288308.

At worst, those branches might have to pick up this newer NSPR for correctness.

I hope that uplifting the UDP bugfix would be safe for the FF 52 and FF 53 branches, too, if it turns out to be required.

Comment 1

[Kai Engert (:KaiE:)]

Marking all branches as affected, that received an unreleased NSPR.
We can later decide, if any of those need to get the uplift.

For now, let's target FF 54.

Started a try build for NSPR_4_14_BETA2
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d7c9cd923c4f18cfdc412f30c5974018fadfae66

Comment 2

[Kai Engert (:KaiE:)]

Franziskus agreed to land that NSPR snapshot into m-c. I'll do that if the try build looks good.

Comment 3

[Kai Engert (:KaiE:)]

Actually, there isn't much point in the try build. The net effect is the removal of two PR_ASSERT statement, which we apparently aren't hitting.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3f8e4d46c656
uplift NSPR_4_14_BETA2, r=franziskus

Comment 5

[Kai Engert (:KaiE:)]

Attachment: uplift-nspr-4.14.txt

Approval Request Comment

[Feature/Bug causing the regression]:
bug 1288308 and bug 1331810

[User impact if declined]:
Linux distributions could use Firefox without required NSPR base patches.

[Is this code covered by automated tests?]:
yes

[Has the fix been verified in Nightly?]:
yes

[Needs manual test from QE? If yes, steps to reproduce]: 
no

[List of other uplifts needed for the feature/fix]:
none

[Is the change risky?]:
No.

[Why is the change risky/not risky?]:
We're effectlvy removing two asserts (for consistency), which aren't being reached in released versions, obviously.

[String changes made/needed]:
none

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3f8e4d46c656

Comment 7

[Kai Engert (:KaiE:)]

Reopening, because RTM hasn't landed yet.

(No more code changes planned for RTM, I just wanted to wait until tests are green.)

Comment 8

[Mike Hommey [:glandium]]

How about adding automated tests on beta/release that check that there's no difference between nspr/nss and the tag they're supposed to be coming from?

Comment 9

[Masatoshi Kimura [:emk]]

And/or commit hooks to prevent local changes from landing accidentally.

Comment 10

[Kai Engert (:KaiE:)]

(In reply to Mike Hommey [:glandium] from comment #8)
> How about adding automated tests on beta/release that check that there's no
> difference between nspr/nss and the tag they're supposed to be coming from?

Good idea, but would prevent us from ever landing any temporary fixes, if ever required (e.g. in the past it had happened that someone really needed to land a build fix to NSPR, to allow everyone to continue their work).

Maybe it's also a lot of bandwidth to do a full checkout of NSPR with every build.

Comment 11

[Kai Engert (:KaiE:)]

(In reply to Masatoshi Kimura [:emk] from comment #9)
> And/or commit hooks to prevent local changes from landing accidentally.

I like this idea. I've filed bug 1348852 to request it.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/207b3f2c43c7
land NSPR_4_14_RTM, no code change, reusing r=franziskus

Comment 13

[Kai Engert (:KaiE:)]

This is now ready for branch uplifting.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b18beab0cf4
bump configure requirement to NSPR 4.14, forgotten when uplifting NSPR_4_14_RTM, no code change

Comment 15

[Kai Engert (:KaiE:)]

Julien, could you please help with getting aurora approval?

Maybe you could discuss with the relevant decision makers, if this should target the other older branches, too?

Comment 16

[Julien Cristau [:jcristau]]

Comment on attachment 8848132 [details]
uplift-nspr-4.14.txt

bump nspr to 4.14 in aurora54

The change that landed in 52/53 on top of 4.13.1 (in bug 1288308) is windows only so likely users of external nspr (linux distros) should be fine, as far as I can tell.

Comment 17

[Kai Engert (:KaiE:)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7145a7655e18e809812776f4b5511df35a9138f4

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/207b3f2c43c7
https://hg.mozilla.org/mozilla-central/rev/8b18beab0cf4