Closed Bug 463073 Opened 12 years ago Closed 11 years ago

Deliver NSPR_4_7_3_RTM to Mozilla

Categories

(Core :: Security: PSM, defect)

x86
All
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

(Keywords: verified1.9.0.6, verified1.9.1)

Attachments

(2 files, 1 obsolete file)

Wan-Teh has proposed to upgrade Mozilla trunk to NSPr 4.7.3 beta 1.
Attached file proposed action (obsolete) —
Attachment #346281 - Flags: review?(wtc)
The only change in NSPR_4_7_3_BETA1 is a fix for the Solaris
8 and 9 regression introduced in NSPR 4.7.2 (bug 461502).
Comment on attachment 346281 [details]
proposed action

r=wtc.
Attachment #346281 - Flags: review?(wtc) → review+
Wan-Teh, the trunk is currently frozen for FF 3.1 beta 2, if it's urgent we must request approval, otherwise I suggest we simply wait until beta 2 is done.
Summary: Deliver NSPR_4_7_3_BETA1 to Mozilla trunk → Deliver NSPR_4_7_3_BETA1 to Mozilla
We have some chickend-and-egg issue.

We can't deliver nspr 4.7.2 for firefox 3.0.5, because it has a solaris regression.

nspr 4.7.3 has a fix, but isn't yet tested in the wild.

testing nspr 4.7.3 in the wild is blocked until the trunk freeze for ff 3.1 beta 2 is over

by the time 4.7.3 was added to trunk, we will probably have passed Samuel's preferred deadline for landing new a new nspr snapshot (money 2008-11-10).
Samuel, please see comment 5.
Looks good to me, but we'll need an actual makefile-changing patch for the branch.
I will create the NSPR_4_7_3_RTM CVS tag today.

The only difference between NSPR 4.7.2 and 4.7.3 is that the
Solaris patch that introduced the regression was backed out.
So it should be fine to deliver NSPR 4.7.3 to the Firefox 3.0.x
branch without trunk testing, because NSPR 4.7.2 has been tested
on the trunk for a long time.
Duplicate of this bug: 464812
Wan-Teh, Kai: what's the status of this? Did the tag get created? were you going to make a makefile patch? We're running out of time on 1.9.0.5
Dan, sorry about the delay.  The NSPR_4_7_3_RTM tag was created last week,
but we forgot to create this makefile patch.  Here it is.
Attachment #348227 - Flags: superreview?(dveditz)
Attachment #348227 - Flags: approval1.9.0.5?
Comment on attachment 348227 [details] [diff] [review]
Patch for mozilla/client.mk for 1.9.0.5

sr=dveditz

Approved for 1.9.0.5, a=dveditz for release-drivers
Attachment #348227 - Flags: superreview?(dveditz)
Attachment #348227 - Flags: superreview+
Attachment #348227 - Flags: approval1.9.0.5?
Attachment #348227 - Flags: approval1.9.0.5+
I checked in the makefile patch (attachment 348227 [details] [diff] [review]) on the Mozilla CVS trunk
for 1.9.0.5.

Checking in client.mk;
/cvsroot/mozilla/client.mk,v  <--  client.mk
new revision: 1.387; previous revision: 1.386
done

The remaining work is to push NSPR_4_7_3_RTM to mozilla-central.
Keywords: fixed1.9.0.5
Summary: Deliver NSPR_4_7_3_BETA1 to Mozilla → Deliver NSPR_4_7_3_RTM to Mozilla
mozilla-central is currently frozen for 3.1beta2
We should get this landed when mozilla-central reopens
I didn't find an opportunity to get this landed yet.

We should include this in 1.9.1, the branch already uses this newer version, and the only change compared to current mozilla-central is a Solaris regression fix.
Flags: blocking1.9.1?
I wouldn't land this on 1.9.1 until we determine the cause of bug 466531, which seems to be caused by upgrading the branch to NSPR 4.7.3. If that's the case, that bug should be fixed first. (And, really, if that's the case, we're likely to back out NSPR 4.7.3 on the 1.9.0 branch.)
Samuel: 1.9.1 has been using NSPR_4_7_2_RTM since Oct 23, 2008.
NSPR_4_7_3_RTM differs from NSPR_4_7_2_RTM only in the fix for
bug 461502 (a Solaris 8 and 9 only regression).

So it is important that 1.9.1 either use NSPR_4_7_3_RTM to eliminate
the known Solaris regression, or go back to NSPR_4_7_1_RTM.  1.9.1
should not ship with NSPR_4_7_2_RTM.
Comment on attachment 348227 [details] [diff] [review]
Patch for mozilla/client.mk for 1.9.0.5

We'll revisit this for 1.9.0.6, but as it unknowingly caused bug 466531, we need to back it out. The patch for the backout is in that bug.
Attachment #348227 - Flags: approval1.9.0.5+ → approval1.9.0.5-
Removing the fixed1.9.0.5 keyword as well, so we don't try to verify this since it's being backed out.
Keywords: fixed1.9.0.5
independent of any firefox 3.0.x branch actions...

Wan-Teh proposed to upgrade Firefox 3.1 to nspr 4.7.3

so here we go
Attachment #357252 - Flags: review?(wtc)
Comment on attachment 357252 [details]
upgrade action for mozilla-1.9.1 (ff 3.1)

r=wtc.

The only difference between NSPR 4.7.2 and NSPR 4.7.3
that affects Firefox is a fix for a Solaris only
regression introduced in NSPR 4.7.2.  See the NSPR
4.7.3 release notes at
http://www.mozilla.org/projects/nspr/release-notes/nspr473.html
Attachment #357252 - Flags: review?(wtc)
Attachment #357252 - Flags: review+
Attachment #357252 - Flags: approval1.9.1?
I already delivered NSPR_4_7_3_RTM to the Firefox 3.0.x
branch (see bug 466531 comment 114 and bug 466531 comment 115).
It will be in the upcoming Firefox 3.0.6 release.
Keywords: verified1.9.0.6
Attachment #346281 - Attachment is obsolete: true
Flags: blocking1.9.1? → blocking1.9.1+
comm-central is also using NSPR_4_7_2_RTM.  Do I need to
upgrade comm-central to NSPR_4_7_3_RTM, too?
Pushed to mozilla-1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d9b9bc03b4b4
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/27dd5992923f

Leaving the bug open until I know what to do about comm-central.
Keywords: fixed1.9.1
Wan-Teh, as you can see on
  https://developer.mozilla.org/en/Comm-central_source_code_%28Mercurial%29
comm-central does not duplicate mozilla-central, but rather includes it.

In other words:
- mozilla-central is the core mozilla platform and browser code
- comm-central contains the additional code for messaging applications
Thanks.  comm-central seems to be tracking mozilla-1.9.1.  I
verified that the NSPR in comm-central is also NSPR 4.7.3 now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #357252 - Flags: approval1.9.1?
Verified comment 25 and comment 26.  Marking VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.