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

Status: VERIFIED FIXED

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

Description

[Gregory Szorc [:gps]]

Attachment: hotfix-v20140527.01.xpi

+++ 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.

Comment 1

[[e-mail] (:bhearsum)]

Attachment: signed hotfix

Here's the signed XPI. I'm not sure who deploys these, but it's not RelEng...

Comment 2

[[e-mail] (:bhearsum)]

Jorge, are you still involved with staging hotfixes?

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

(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.

Comment 4

[Gregory Szorc [:gps]]

Attachment: hotfix-v20140527.01.xpi

We just had a last-minute addition to the hotfix over in bug 1062926. Please sign and deploy version 20140527.01.6.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: hotfix-v20140527.01.signed.xpi

Here's the signed xpi, whether we want to use it now that we've shipped 32.0.1 is another question.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

The signed XPI is now published on -dev.

Comment 7

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

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?

Comment 8

[Benjamin Smedberg]

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.

Comment 9

[Benjamin Smedberg]

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.

Comment 10

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(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

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Maybe https://hg.mozilla.org/releases/firefox-hotfixes/file/410e5fef2253/v20140527.01/import-installers.py.

Comment 12

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: Unsigned hotfix-v20140527.01.xpi

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

Comment 13

[[e-mail] (:bhearsum)]

Attachment: signed version of latest hotfix

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

Deployed on dev.

Comment 15

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(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

Comment 16

[Rail Aliiev [:rail]]

(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...

Comment 17

[Paul Silaghi, QA [:pauly]]

I'll take care of this

Comment 18

[Paul Silaghi, QA [:pauly]]

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?

Comment 19

[Paul Silaghi, QA [:pauly]]

Attachment: FF 10 browser console log.txt

Comment 20

[Tim Abraldes [:TimAbraldes] [: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?

Comment 21

[Paul Silaghi, QA [:pauly]]

Attachment: FF 10 update log

(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.

Comment 22

[Gregory Szorc [:gps]]

(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.

Comment 23

[Paul Silaghi, QA [:pauly]]

This sounds a bit similar to bug 1037649, the problem is the update isn't always done.

Comment 24

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(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 ;)

Comment 25

[Gregory Szorc [: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.

Comment 26

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

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

Comment 27

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: Unsigned hotfix-v20140527.01.xpi v2

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!

Comment 28

[[e-mail] (:bhearsum)]

Pete is going to do the XPI signing a bit later.

Comment 29

[Pete Moore [:pmoore][:pete]]

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!

Comment 30

[Pete Moore [:pmoore][:pete]]

Found the key on signing4 (wasn't on signing5) so I will proceed...

Comment 31

[Pete Moore [:pmoore][:pete]]

Attachment: Signed hotfix-v20140527.01.xpi v2

Attachment 8509122 [details], signed with "Mozilla Corporation - DigiCert Inc" key.

Comment 32

[Pete Moore [:pmoore][:pete]]

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

Comment 33

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 34

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(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.

Comment 35

[Pete Moore [:pmoore][:pete]]

I'm happy to resign when it is ready. Are we still going ahead with this?

Thanks,
Pete

Comment 36

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 37

[Chris More [:cmore]]

Is there are a target milestone for this V2 hotfix?

Comment 38

[Matt Grimes [:Matt_G]]

Hey folks. Just checking on the status here. The initial hotfix was a big success and we're just looking to close the loop.

Comment 39

[Stephen A Pohl [:spohl]]

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.

Comment 40

[Chris More [:cmore]]

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.

Comment 41

[Benjamin Smedberg]

This shouldn't wait for any particular release. Let's just get it out the door.

Comment 42

[Stephen A Pohl [:spohl]]

Attachment: Unsigned hotfix-v20140527.01.xpi

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!

Comment 43

[Justin Wood (:Callek)]

I should be able to do the signing tomorrow, in lieu of ben.

Comment 44

[Justin Wood (:Callek)]

Attachment: Signed hotfix-v20140527.01.xpi

This is my first attempt at signing an xpi, so any/all verification that can be done would be appreciated.

Comment 45

[Jorge Villalobos [:jorgev] (he/him)]

The add-on is now approved on staging. Please verify it's working so we can push to production.

Comment 46

[Stephen A Pohl [:spohl]]

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!

Comment 47

[Paul Silaghi, QA [:pauly]]

(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).

Comment 48

[Stephen A Pohl [:spohl]]

(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?

Comment 49

[Paul]

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.

Comment 50

[Stephen A Pohl [:spohl]]

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?

Comment 51

[Stephen A Pohl [:spohl]]

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?

Comment 52

[Paul Silaghi, QA [:pauly]]

(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

Comment 53

[Paul Silaghi, QA [:pauly]]

(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.

Comment 54

[Robert Strong (they/them - no direct email)]

(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.

Comment 55

[Stephen A Pohl [:spohl]]

(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...

Comment 56

[Paul Silaghi, QA [:pauly]]

(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.

Comment 57

[Paul Silaghi, QA [:pauly]]

Here is a screencast showing the problem: http://screencast.com/t/RFnuywr4

Comment 58

[Stephen A Pohl [:spohl]]

(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.

Comment 59

[Stephen A Pohl [:spohl]]

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.

Comment 60

[Stephen A Pohl [:spohl]]

Attachment: Unsigned hotfix-v20140527.01.xpi

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!

Comment 61

[Stephen A Pohl [:spohl]]

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.

Comment 62

[Stephen A Pohl [:spohl]]

Attachment: Unsigned hotfix-v20140527.01.xpi

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!

Comment 63

[Justin Wood (:Callek)]

Attachment: hotfix-v20140527.01-signed.xpi

Comment 64

[Jorge Villalobos [:jorgev] (he/him)]

(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.

Comment 65

[Paul Silaghi, QA [:pauly]]

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"

Comment 66

[Stephen A Pohl [:spohl]]

: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?

Comment 67

[Jorge Villalobos [:jorgev] (he/him)]

(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 :(

Comment 68

[Stephen A Pohl [:spohl]]

Attachment: Unsigned hotfix-v20140527.01.xpi

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!

Comment 69

[Justin Wood (:Callek)]

I'm based out of the usa. Punting to ben.

Comment 70

[[e-mail] (:bhearsum)]

What's the urgency on this?

Comment 71

[Stephen A Pohl [:spohl]]

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.

Comment 72

[[e-mail] (:bhearsum)]

(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?

Comment 73

[Stephen A Pohl [:spohl]]

(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.

Comment 74

[Stephen A Pohl [:spohl]]

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?

Comment 75

[[e-mail] (:bhearsum)]

(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?

Comment 76

[Benjamin Smedberg]

Don't wait.

Comment 77

[Stephen A Pohl [:spohl]]

(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.

Comment 78

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: hotfix-v20140527.01-signed.xpi

Comment 79

[Jorge Villalobos [:jorgev] (he/him)]

The signed version is now staged. Please test.

Comment 80

[Paul Silaghi, QA [:pauly]]

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.

Comment 81

[Stephen A Pohl [:spohl]]

:jorgev, is it you who typically pushes this live? Anything else we need to do before releasing?

Comment 82

[Jorge Villalobos [:jorgev] (he/him)]

(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?

Comment 83

[Robert Strong (they/them - no direct email)]

Yes and thanks!

Comment 84

[Jorge Villalobos [:jorgev] (he/him)]

The signed add-on is now available on AMO.

Comment 85

[schan]

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.

Comment 86

[Jorge Villalobos [:jorgev] (he/him)]

The new version is now available on AMO.

Comment 87

[Justin Wood (:Callek)]

(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)

Comment 88

[Paul Silaghi, QA [:pauly]]

(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.