Closed Bug 486182 Opened 15 years ago Closed 15 years ago

Land NSS 3.12.3 final in mozilla-central (the experimental firefox trunk)

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

NSS 3.12.3 will be released soon.
Once that happened, it should be delivered to mozilla-central.
Blocks: 481968, 485052
Isn't this a duplicate of bug 481968 ?
(In reply to comment #1)
> Isn't this a duplicate of bug 481968 ?

Well, usually we use a single bug to perform a task in multiple target Mozilla branches, and use the overall state for Mozilla trunk, and use keywords like fixed1.9.x to mark it fixed for branches.

But given that we already had a branch-specific version of this task (bug 481968 for mozilla-1.9.1 equiv. Firefox 3.1/3.5) I decided not to morph that bug but have a separate one...
(In reply to comment #1)
> Isn't this a duplicate of bug 481968 ?

This is a precursor to that.  Bug 481968 is about taking the 3.12.3 tag on the FF3.5 release branch, whereas this bug is about taking it on the mozilla-central development trunk. Nothing can land on the branch until it's landed on trunk to "bake" for a day or two, so the landings can't be handled simultaneously by one bug.
Any progress here?
There is no release tag, and no release candidate tag yet.
We have release candidate tag NSS_3_12_3_RC0

Nelson or Bob, can you please confirm (r+ in a comment) that we want to give this tag to Mozilla?
I'm running a local verification build of mozilla-central with this new NSS tag. Once it succeeds I'll land this tag (and afterwards bug 485052) into mozilla-central (Firefox trunk).
(In reply to comment #6)

> Nelson or Bob, can you please confirm (r+ in a comment) that we want to give
> this tag to Mozilla?

Please see the comments to this effect in bug 481968.  Thanks.
(In reply to comment #8)
> (In reply to comment #6)
> 
> > Nelson or Bob, can you please confirm (r+ in a comment) that we want to give
> > this tag to Mozilla?
> 
> Please see the comments to this effect in bug 481968.  Thanks.

I take this as r+ for landing.
I pushed NSS 3.12.3 rc0 as http://hg.mozilla.org/mozilla-central/rev/e4c0eed67bf9

Afterwards I realized we better trigger a full NSS rebuild (non-depend), so I pushed a change to file coreconf.dep, http://hg.mozilla.org/mozilla-central/rev/8ab63b55444a
Tinderbox cycled OK on all 3 platforms, resolving as fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I looked into a wrong column when declaring victory...
There was a build failure due to come code only being built in the Mozilla client.
Temporarily disabled building this code (r=nelson) and filed bug 487162 to get it right.
Depends on: 487162
Depends on: 487673
This broke mobile -- needs either a fix or needs to be backed out ASAP.  The mobile and other bustage is tracked in 487673, I think?
See bug 487673 and bug 487712 for the wince landing fix.
I see a graph with no legend, and apparently using only color coding, which 
doesn't help me, to identify the lines.  

Are you talking about the number that went from 906092 somethings to 
921849 somethings (+1.7%) at ~7 PM on 6 April?  

This is the subject of Bug 487394, is it not ?
Maybe.

The units are bytes.
(In reply to comment #16)
> I see a graph with no legend, and apparently using only color coding, which 
> doesn't help me, to identify the lines.  
> 
> Are you talking about the number that went from 906092 somethings to 
> 921849 somethings (+1.7%) at ~7 PM on 6 April?  
> 
> This is the subject of Bug 487394, is it not ?

Almost certainly - see bug 485052 comment 21 and below for the backstory that led to bug 487394 being opened to track this leak.
No longer depends on: 487673
You need to log in before you can comment on or make changes to this bug.