Closed Bug 1061975 Opened 5 years ago Closed 5 years ago

Sign and dev deploy the Firefox update hotfix (v20140527.01)

Categories

(Release Engineering :: Release Requests, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: gps, Assigned: spohl)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxgrowth])

Attachments

(17 obsolete files)

Attached file hotfix-v20140527.01.xpi (obsolete) —
+++ This bug was initially created as a clone of Bug #1038561 +++

We're planning a minor v2 release of the Firefox update hotfix to address issues discovered with the first. Please sign the attached XPI and deploy to the *dev* server only.
Attached file signed hotfix (obsolete) —
Here's the signed XPI. I'm not sure who deploys these, but it's not RelEng...
Jorge, are you still involved with staging hotfixes?
Flags: needinfo?(jorge)
(In reply to Ben Hearsum [:bhearsum] from comment #2)
> Jorge, are you still involved with staging hotfixes?

Yup. The add-on is now available on staging.
Flags: needinfo?(jorge)
Attached file hotfix-v20140527.01.xpi (obsolete) —
We just had a last-minute addition to the hotfix over in bug 1062926. Please sign and deploy version 20140527.01.6.
Attachment #8483097 - Attachment is obsolete: true
Attachment #8483699 - Attachment is obsolete: true
Attached file hotfix-v20140527.01.signed.xpi (obsolete) —
Here's the signed xpi, whether we want to use it now that we've shipped 32.0.1 is another question.
The signed XPI is now published on -dev.
I've been asked to see this bug through to completion.

My understanding is that I need to follow these steps:
  1) Verify that the signed XPI published on -dev is the same as the one attached to this bug
  2) Get QA sign-off (similar to bug 1038561 comment 6) on the published XPI
  3) File a bug similar to bug 1039605 to get this hotfix deployed in production


(In reply to Nick Thomas [:nthomas] from comment #5)
> Here's the signed xpi, whether we want to use it now that we've shipped
> 32.0.1 is another question.

I'm new to hotfixes, could you describe the issue here and what alternate steps I could take now that we've shipped 32.0.1?
Status: NEW → ASSIGNED
Flags: needinfo?(nthomas)
Summary: Sign and dev deploy the Firefox update hotfix (v20140527.01.5) → Sign and dev deploy the Firefox update hotfix (v20140527.01.6)
Assignee: nobody → tabraldes
We're shipping 32.0.3 and so we should update the hotfix to use the new installer. You should file a new bug for that: you can probably clone https://bugzilla.mozilla.org/show_bug.cgi?id=1052530 and follow the steps there: IIRC gps has a script which updates this and checks the signatures.
We will need QA signoff of the changes in v2, and specifically the one that needs manual verification is bug 1052519. See https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.
Flags: needinfo?(nthomas)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> We're shipping 32.0.3 and so we should update the hotfix to use the new
> installer. You should file a new bug for that: you can probably clone
> https://bugzilla.mozilla.org/show_bug.cgi?id=1052530 and follow the steps
> there:

Filed bug 1072615 (Install Firefox 32.0.3 from hotfix) as a clone of bug 1061927 (Install Firefox 32 from hotfix).

> IIRC gps has a script which updates this and checks the signatures.

I was lead to believe that gps is unavailable on PTO; does anyone else know where that script lives?

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> We will need QA signoff of the changes in v2, and specifically the one that
> needs manual verification is bug 1052519. See
> https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.

OK I'll request QA signoff after bug 1072615 is resolved and we've published the new XPI on -dev
Attachment #8484233 - Attachment is obsolete: true
Attachment #8489791 - Attachment is obsolete: true
Attached file Unsigned hotfix-v20140527.01.xpi (obsolete) —
I created this by pulling the changes from bug 1072615 and then:
  HOTFIX=v20140527.01 make package

I think the next step is to sign and dev deploy
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
Attached file signed version of latest hotfix (obsolete) —
Flags: needinfo?(bhearsum)
Deployed on dev.
Flags: needinfo?(jorge)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> We will need QA signoff of the changes in v2, and specifically the one that
> needs manual verification is bug 1052519. See
> https://hg.mozilla.org/releases/firefox-hotfixes/ for the changelog.

OK it's time for QA signoff.

:rail are you the right person for this?
:pauly I also needinfo'd you because you did the signoff in bug 1038561 comment 6

QA please verify what :bsmedberg mentioned in comment 9 and also that the hotfix correctly upgrades to 32.0.3
Flags: needinfo?(rail)
Flags: needinfo?(paul.silaghi)
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #15)
> OK it's time for QA signoff.
> 
> :rail are you the right person for this?

Sorry, this is not me.

in bug 1028388 :pauly was involved. Maybe he knows...
Flags: needinfo?(rail)
I'll take care of this
QA Contact: rail → paul.silaghi
The hotfix doesn't seem to work on versions 10-17.
In browser console I see:
"Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
Source File: resource://firefox-hotfix/update.jsm
Line: 1135"

Works fine on FF 18-28.
Thoughts?
Flags: needinfo?(paul.silaghi) → needinfo?(tabraldes)
To me that looks like a transient filesystem issue (Windows sometimes gets cranky when you try to delete files that you've recently been using), but if it happened consistently in FF10 through FF17 maybe there's more to it. Could you test once more on one of the versions that failed previously?

If it's not a transient issue, someone who understands the hotfix might be able to debug. :gps are you back from your long leave?
Flags: needinfo?(tabraldes)
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(gps)
Attached file FF 10 update log (obsolete) —
(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #20)
> Could you test once more on one of the versions that failed previously?
I've tried on a different machine and the hotfix worked fine, although the above error still occurred.
I still reproduced the problem on the affected machine, same OS (Win 7 x64). The hotfix seems to be installed, the installer is downloaded, but the new version doesn't get installed. I'm attaching the update log, perhaps :gps finds something interesting in it.
Flags: needinfo?(paul.silaghi)
(In reply to Paul Silaghi, QA [:pauly] from comment #18)
> The hotfix doesn't seem to work on versions 10-17.
> In browser console I see:
> "Error: [Exception... "Component returned failure code: 0x80004005
> (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
> Source File: resource://firefox-hotfix/update.jsm
> Line: 1135"
> 
> Works fine on FF 18-28.
> Thoughts?

That could be a legitimate regression from bug 1052519, as line 1135 is calling Services.dirsvc.get("UpdRootD") and that appears to be throwing. Did UpdRootD not exist until Firefox 18? Let's investigate this in bug 1052519.
Flags: needinfo?(gps)
This sounds a bit similar to bug 1037649, the problem is the update isn't always done.
(In reply to Gregory Szorc [:gps] from comment #22)
> (In reply to Paul Silaghi, QA [:pauly] from comment #18)
> > The hotfix doesn't seem to work on versions 10-17.
> > In browser console I see:
> > "Error: [Exception... "Component returned failure code: 0x80004005
> > (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005
> > (NS_ERROR_FAILURE)"  location: "JS frame ::
> > resource://firefox-hotfix/update.jsm :: <TOP_LEVEL> :: line 1135"  data: no]
> > Source File: resource://firefox-hotfix/update.jsm
> > Line: 1135"
> > 
> > Works fine on FF 18-28.
> > Thoughts?
> 
> That could be a legitimate regression from bug 1052519, as line 1135 is
> calling Services.dirsvc.get("UpdRootD") and that appears to be throwing. Did
> UpdRootD not exist until Firefox 18? Let's investigate this in bug 1052519.

For clarity, did you mean that you will investigate the cause of this and update your patch? Or that I should take over in that bug? I assumed the former but perhaps that was wishful thinking ;)
Flags: needinfo?(gps)
I thought the hotfix handoff was complete. I think someone who isn't me should look at this.

I'm still here to provide support as needed. Needinfo me if you get stuck.
Flags: needinfo?(gps)
OK I filed bug 1079439 as a follow-up to bug 1052519 and assigned it to myself. I'll see if I can fix the issue there and then report back on this bug when I've got a new XPI to sign, dev deploy, and QA
Attached file Unsigned hotfix-v20140527.01.xpi v2 (obsolete) —
Updated XPI with fix for bug 1079439. Please sign (:bhearsum) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release.

Thanks!
Attachment #8495485 - Attachment is obsolete: true
Attachment #8496219 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
Pete is going to do the XPI signing a bit later.
Flags: needinfo?(bhearsum) → needinfo?(pmoore)
I've tried, but got stuck - I could not find the xpi signing key. I'm going to have to leave this for tonight as I have appointments, I can come back in the morning, but if someone else can help, that might be a better idea if this is urgent. Sorry!
Flags: needinfo?(pmoore)
Found the key on signing4 (wasn't on signing5) so I will proceed...
Attached file Signed hotfix-v20140527.01.xpi v2 (obsolete) —
Attachment 8509122 [details], signed with "Mozilla Corporation - DigiCert Inc" key.
Please note in the comment above, I referred to the unsigned attachment in the comment body - and I see now it could be easy to download the unsigned version, thinking it is the signed version. i.e.:

unsigned: attachment 8509122 [details]
signed:   attachment 8510245 [details]

Both are linked from comment 31 - so beware! :D
AMO doesn't handle repeated versions well, so I need the version number to be bumped up to 20140527.01.8 so I can stage it.
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #33)
> AMO doesn't handle repeated versions well, so I need the version number to
> be bumped up to 20140527.01.8 so I can stage it.

Gah, my bad! I haven't mastered the various details involved in releasing a hotfix. For whoever works on this next; the next step is to do a version bump like this:
  http://hg.mozilla.org/releases/firefox-hotfixes/rev/410e5fef2253
The following steps are:
  - Build the XPI
  - Attach the XPI here and request for it to be signed, dev-deployed, QA-signoff'ed
  - Once that is all done, request that the signed XPI be production-deployed

Reassigning to :rstrong so that this doesn't get lost as I transition out of Windows platform land.
Assignee: tabraldes → robert.strong.bugs
I'm happy to resign when it is ready. Are we still going ahead with this?

Thanks,
Pete
Meanwhile we keep building new releases the woes with graphics/OMTC, so lets make sure we're up to date with the current release when we do this again.
Is there are a target milestone for this V2 hotfix?
Hey folks. Just checking on the status here. The initial hotfix was a big success and we're just looking to close the loop.
I'm slowly chipping away at this, but keep getting sidetracked by more urgent work. I'm still hoping to have a fresh hotfix (that updates to 33.1) ready for signing by end of week, or early next.
Depends on: 1098559
Flags: needinfo?(paul.silaghi)
Given that Firefox 34 is right around the corner (11/25) would we *not* want to release this to close to release date? I assume it doesn't really matter since these are legacy users, but just thought about the scenario of a user upgrading and then a few days later 34 is released.
Whiteboard: [fxgrowth]
This shouldn't wait for any particular release. Let's just get it out the door.
Attached file Unsigned hotfix-v20140527.01.xpi (obsolete) —
I'm basically repeating comment 27 here, so hopefully the same people are still the right ones to ask for help here:

Please sign (:bhearsum) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release.

Thanks!
Assignee: robert.strong.bugs → spohl.mozilla.bugs
Attachment #8509122 - Attachment is obsolete: true
Attachment #8510245 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bhearsum)
I should be able to do the signing tomorrow, in lieu of ben.
Flags: needinfo?(bhearsum) → needinfo?(bugspam.Callek)
Attached file Signed hotfix-v20140527.01.xpi (obsolete) —
This is my first attempt at signing an xpi, so any/all verification that can be done would be appreciated.
Flags: needinfo?(bugspam.Callek)
The add-on is now approved on staging. Please verify it's working so we can push to production.
Flags: needinfo?(jorge)
Paul, it'd be great if you could also verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!
(In reply to Jorge Villalobos [:jorgev] from comment #45)
> The add-on is now approved on staging. Please verify it's working so we can
> push to production.
Works fine on staging, old FF versions are updated to 33.1.1.
Tested on Win 7 on FF 10, 17, 24, 28 and Win XP on FF 13.0.1, 16.0.2, 17.0.1, 23, 27.0.1.
Note that the hotfix applies only to FF 10-28.

(In reply to Stephen Pohl [:spohl] from comment #46)
> Paul, it'd be great if you could also verify that the hotfix does not get
> applied if app.update.url.override is set to
> "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug
> 1098559 comment 10 for more detail). Thanks!
FF 10-16 still get updated with the pref set.
FF 17-28 don't get updated with the pref set.
I also notice that after the update was dropped due to the above pref, the hotfix still doesn't work if I remove the pref in about:config (using the same FF profile).
Flags: needinfo?(paul.silaghi)
(In reply to Paul Silaghi, QA [:pauly] from comment #47)
> (In reply to Stephen Pohl [:spohl] from comment #46)
> > Paul, it'd be great if you could also verify that the hotfix does not get
> > applied if app.update.url.override is set to
> > "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug
> > 1098559 comment 10 for more detail). Thanks!
> FF 10-16 still get updated with the pref set.
> FF 17-28 don't get updated with the pref set.
> I also notice that after the update was dropped due to the above pref, the
> hotfix still doesn't work if I remove the pref in about:config (using the
> same FF profile).

Paul, you mentioned in bug 928173 comment 36 that the devices were being switched to the most recent version. In light of this, do you have any concerns about the hotfix still being applied to FF 10-16?
Flags: needinfo?(paul.cuthbert)
Yes we do. The issue is that there are still a large number of USB devices being used with FF 14.0.1. These are being replaced over time with new hardware and the latest FF version, and will be maintained via software update. However, the old devices are not remotely updated so will continue to be affected.
I can't seem to apply the hotfix to a local Firefox 14.0.1 installation ("could not be installed because it is not compatible with Firefox 14.0.1"). :pauly, would you be able to either walk me through this or refer me to a document that explains how I can test this?
Flags: needinfo?(paul.silaghi)
Robert, does bug 919033 comment 12 mean that we'll be applying a different hotfix to a 14.0.1 install first before installing the latest hotfix posted here? Do you think this might be the reason why Paul found that Firefox versions between 10-16 still get updated despite app.update.url.override being set?
Flags: needinfo?(robert.strong.bugs)
(In reply to Stephen Pohl [:spohl] from comment #50)
> :pauly, would you be able to either walk me through this or refer me to a
> document that explains how I can test this?
Steps:
1. Start FF with a new profile
2. Go to about:config and set:
   - extensions.logging.enabled=TRUE
   - in the pref "extensions.update.background.url" (extensions.update.url for Firefox < 13), change the "versioncheck-bg.addons.mozilla.org" part from the string with "addons-dev.allizom.org"
3. Restart FF
4. Open Addons Manager
5. Open the Browser Console and clear it so you can see the update requests
6. Open Scratchpad and run (3 times for FF 10-16) the following code snippet:
var obj = {};
Cu.import("resource://gre/modules/AddonManager.jsm", obj);
obj.AddonManagerPrivate.backgroundUpdateCheck();
7. Wait a bit until the update is applied, then restart FF
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(paul.cuthbert)
(In reply to Stephen Pohl [:spohl] from comment #51)
> Robert, does bug 919033 comment 12 mean that we'll be applying a different
> hotfix to a 14.0.1 install first before installing the latest hotfix posted
> here?
3 hotfixes are used for FF 10-16.0.1:
hotfix version 20121019.01
hotfix version 20130826.01
hotfix version 20140527.01.8

Starting with FF 16.0.2, only the last 2 are used.
But I don't understand why FF 16.0.2 is still updated with the app.update.url.override set and FF 17 is not.
(In reply to Stephen Pohl [:spohl] from comment #51)
> Robert, does bug 919033 comment 12 mean that we'll be applying a different
> hotfix to a 14.0.1 install first before installing the latest hotfix posted
> here?
I think it means that profiles that have applied the fingerprint hotfix will be able to apply a later hotfix.

> Do you think this might be the reason why Paul found that Firefox
> versions between 10-16 still get updated despite app.update.url.override
> being set?
I don't see how though possibly.
Flags: needinfo?(robert.strong.bugs)
(In reply to Paul Silaghi, QA [:pauly] from comment #52)
> (In reply to Stephen Pohl [:spohl] from comment #50)
> > :pauly, would you be able to either walk me through this or refer me to a
> > document that explains how I can test this?
> Steps:
> 1. Start FF with a new profile
> 2. Go to about:config and set:
>    - extensions.logging.enabled=TRUE
>    - in the pref "extensions.update.background.url" (extensions.update.url
> for Firefox < 13), change the "versioncheck-bg.addons.mozilla.org" part from
> the string with "addons-dev.allizom.org"
> 3. Restart FF
> 4. Open Addons Manager
> 5. Open the Browser Console and clear it so you can see the update requests
> 6. Open Scratchpad and run (3 times for FF 10-16) the following code snippet:
> var obj = {};
> Cu.import("resource://gre/modules/AddonManager.jsm", obj);
> obj.AddonManagerPrivate.backgroundUpdateCheck();
> 7. Wait a bit until the update is applied, then restart FF

When I run this with Firefox 14.0.1 and I have no app.update.url.override set, a restart still shows 14.0.1, but opening the Firefox About dialog starts downloading 33.1.1. Clicking the "Restart" button will apply 33.1.1 and restart Firefox.

If I have app.update.url.override set to "https://update.commbiz.commbank.com.au", all the hotfixes get downloaded and installed (according to the Error Console). However, when I restart Firefox and launch the About dialog, I'm told that 14.0.1 is up to date.

Paul, it seems like I'm still missing a step to reproduce what you're seeing...
Flags: needinfo?(paul.silaghi)
(In reply to Stephen Pohl [:spohl] from comment #55)
> When I run this with Firefox 14.0.1 and I have no app.update.url.override
> set, a restart still shows 14.0.1, but opening the Firefox About dialog
> starts downloading 33.1.1. Clicking the "Restart" button will apply 33.1.1
> and restart Firefox.
If you're opening the Help/About dialog then the hotfix will have no job anymore, cause FF will upgrade anyway.
In the step 7 comment 52, FF 33.1.1 should be downloaded and installed automatically in the background (no Help/About needed). Just wait ~1 min (may take longer on slow internet connections) and then restart. After this you should see the new version. Type about: in the location bar to check the version.
Just checked on FF 14.0.1 and the update is still applied with app.update.url.override set.
Flags: needinfo?(paul.silaghi)
Here is a screencast showing the problem: http://screencast.com/t/RFnuywr4
(In reply to Paul Silaghi, QA [:pauly] from comment #57)
> Here is a screencast showing the problem: http://screencast.com/t/RFnuywr4

Thank you! I'm now able to reproduce the problem. Unfortunately, I have no idea why this isn't working yet. If somebody happens to know where the log calls from update.jsm are going, or how I can enable it, please let me know.
Once I found where the logs were written to (hotfix-update directory in user profile, but directory will get deleted if browser is restarted after update), this turned out to be a pretty silly problem. A new patch is awaiting review in bug 1098559 and I'll be posting a new hotfix for signing and QA signoff here once the patch has been reviewed and landed.
Attachment #8524107 - Attachment is obsolete: true
Attachment #8524705 - Attachment is obsolete: true
Attachment #8497359 - Attachment is obsolete: true
Attachment #8496856 - Attachment is obsolete: true
Attached file Unsigned hotfix-v20140527.01.xpi (obsolete) —
Ok, let's try this again.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!

Thanks!
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bugspam.Callek)
Comment on attachment 8528505 [details]
Unsigned hotfix-v20140527.01.xpi

Hmm, comment 33 makes me think that I need to bump the version number. :jorgev, let me know if that's not the case.
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(bugspam.Callek)
Attached file Unsigned hotfix-v20140527.01.xpi (obsolete) —
Bumped version number to 20140527.01.9.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail). Thanks!

Thanks!
Attachment #8528505 - Attachment is obsolete: true
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(bugspam.Callek)
Attached file hotfix-v20140527.01-signed.xpi (obsolete) —
Flags: needinfo?(bugspam.Callek)
(In reply to Stephen Pohl [:spohl] from comment #61)
> Hmm, comment 33 makes me think that I need to bump the version number.
> :jorgev, let me know if that's not the case.

Yes, a version bump is necessary if the previous version was uploaded to stage or prod.

The new version is now available on staging.
Flags: needinfo?(jorge)
The hotfix is not working at all, tested on FF 10, 28.
Browser console log:
"A required certificate was not present. CertUtils.jsm:77
WARN addons.manager: The hotfix add-on was not signed by the expected certificate and so will not be installed. AddonManager.jsm:1100
LOG addons.xpi: Cancelling download of https://addons-dev-cdn.allizom.org/user-media/addons/354399/mozilla_firefox_hotfix-20140527.01.9-fx.xpi"
Flags: needinfo?(paul.silaghi)
:jorgev, based on the checksums it looks like the unsigned hotfix was uploaded to staging. Can it be replaced by the signed one, or do we need another version bump?
Flags: needinfo?(jorge)
(In reply to Stephen Pohl [:spohl] from comment #66)
> :jorgev, based on the checksums it looks like the unsigned hotfix was
> uploaded to staging. Can it be replaced by the signed one, or do we need
> another version bump?

Ugh, sorry about that. Yes, we'll need another version bump :(
Flags: needinfo?(jorge)
Summary: Sign and dev deploy the Firefox update hotfix (v20140527.01.6) → Sign and dev deploy the Firefox update hotfix (v20140527.01)
Attachment #8528514 - Attachment is obsolete: true
Attachment #8528511 - Attachment is obsolete: true
Attached file Unsigned hotfix-v20140527.01.xpi (obsolete) —
Bumped version number to 20140527.01.10.

Please sign (:Callek) and dev deploy (:jorgev).

:pauly - once the signed XPI has been dev deployed, please verify it so that we can release. In particular:
1. Please verify comment 9.
2. Please verify that the hotfix does not get applied if app.update.url.override is set to "https://update.commbiz.commbank.com.au" (see bug 928173 comment 32 and bug 1098559 comment 10 for more detail).

Thanks!
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(jorge)
Flags: needinfo?(bugspam.Callek)
I'm based out of the usa. Punting to ben.
Flags: needinfo?(bugspam.Callek) → needinfo?(bhearsum)
What's the urgency on this?
Flags: needinfo?(bhearsum) → needinfo?(spohl.mozilla.bugs)
It seems like this should ship before we release FF34, or we'll have to do this over (again) and change the hotfix to update to FF34 instead of FF33.1.1. Also note comment 41.
Flags: needinfo?(spohl.mozilla.bugs)
(In reply to Stephen Pohl [:spohl] from comment #71)
> It seems like this should ship before we release FF34, or we'll have to do
> this over (again) and change the hotfix to update to FF34 instead of
> FF33.1.1. Also note comment 41.

Aren't we going to have to do that anyways after Fx34 ships?
(In reply to Ben Hearsum [:bhearsum] from comment #72)
> (In reply to Stephen Pohl [:spohl] from comment #71)
> > It seems like this should ship before we release FF34, or we'll have to do
> > this over (again) and change the hotfix to update to FF34 instead of
> > FF33.1.1. Also note comment 41.
> 
> Aren't we going to have to do that anyways after Fx34 ships?

As long as we get the hotfix out the door before FF34 ships we should be good to go. If we decide to ship another hotfix, it will update to whatever is the current version at that time.
Arguably, the FF34 release on 12/1 is coming up very shortly (I thought it was later). Benjamin, do you think we should hold off on releasing the hotfix for 33.1.1 and change it to update to FF34 instead?
Flags: needinfo?(benjamin)
(In reply to Stephen Pohl [:spohl] from comment #73)
> (In reply to Ben Hearsum [:bhearsum] from comment #72)
> > (In reply to Stephen Pohl [:spohl] from comment #71)
> > > It seems like this should ship before we release FF34, or we'll have to do
> > > this over (again) and change the hotfix to update to FF34 instead of
> > > FF33.1.1. Also note comment 41.
> > 
> > Aren't we going to have to do that anyways after Fx34 ships?
> 
> As long as we get the hotfix out the door before FF34 ships we should be
> good to go. If we decide to ship another hotfix, it will update to whatever
> is the current version at that time.

Right...but if everyone updates to 34 this next, many people wouldn't have had time to get this hotfix, right?
Don't wait.
Flags: needinfo?(benjamin)
(In reply to Ben Hearsum [:bhearsum] from comment #75)
> (In reply to Stephen Pohl [:spohl] from comment #73)
> > (In reply to Ben Hearsum [:bhearsum] from comment #72)
> > > (In reply to Stephen Pohl [:spohl] from comment #71)
> > > > It seems like this should ship before we release FF34, or we'll have to do
> > > > this over (again) and change the hotfix to update to FF34 instead of
> > > > FF33.1.1. Also note comment 41.
> > > 
> > > Aren't we going to have to do that anyways after Fx34 ships?
> > 
> > As long as we get the hotfix out the door before FF34 ships we should be
> > good to go. If we decide to ship another hotfix, it will update to whatever
> > is the current version at that time.
> 
> Right...but if everyone updates to 34 this next, many people wouldn't have
> had time to get this hotfix, right?

The hotfix is for people who are stuck on old versions, so will still be relevant. Per comment 76, let's get this signed and out the door.
The signed version is now staged. Please test.
Flags: needinfo?(jorge)
Works fine on staging.
Tested on FF 10, 14.0.1, 16.0.1, 17, 20, 24, 28 both with/without the "app.update.url.override" pref.
Flags: needinfo?(paul.silaghi)
:jorgev, is it you who typically pushes this live? Anything else we need to do before releasing?
Flags: needinfo?(jorge)
(In reply to Stephen Pohl [:spohl] from comment #81)
> :jorgev, is it you who typically pushes this live? Anything else we need to
> do before releasing?

Yes, it's just a matter of pushing it live. Are we good to go?
Flags: needinfo?(jorge)
Yes and thanks!
Flags: needinfo?(jorge)
The signed add-on is now available on AMO.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(jorge)
Resolution: --- → FIXED
This hot fix directly links to ftp.m.o rather than bouncer. It is hard coded. 
from whine @3:10p pst that this hot fix has been pulled.
See Also: → 1107156
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 1107156
Attachment #8529971 - Attachment is obsolete: true
Attachment #8529837 - Attachment is obsolete: true
The new version is now available on AMO.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
(In reply to Jorge Villalobos [:jorgev] from comment #86)
> The new version is now available on AMO.

gps created a new xpi and I signed it (over in Bug 1107156)
(In reply to Paul Silaghi, QA [:pauly] from comment #80)
> Works fine on staging.
> Tested on FF 10, 14.0.1, 16.0.1, 17, 20, 24, 28 both with/without the
> "app.update.url.override" pref.
Works fine in production too.
Status: RESOLVED → VERIFIED
Blocks: 1110340
You need to log in before you can comment on or make changes to this bug.