612600 - windows build not updating

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: updates.xml

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre
Built from http://hg.mozilla.org/mozilla-central/rev/8cbe83542596

the about dialog tells me that 4.0b8pre is up to date

The last thing in the update log (from which I can't copy, and which is app-modal via prefs!!!) is from Aug 21:

http://grab.by/grabs/2a72db90a6b43ce77b279015ec1e4d29.png

updates.xml has a timestamp of 11/07, and contains the above data as well, I'll attach it.  last-update has the same timestamp, and indicates a successful update. backup-update has a timestamp of 08/21. updates/0 is empty, directory timestamp is the same 11/07 one.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

What is the Error Console Output if you set app.update.log to true beforehand?

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Error console, first to last:

AUS:SVC getLocale - getting locale from file: C:\Program Files (x86)\Minefield\update.locale, locale: en-US

AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101107042528/WINNT_x86-msvc/en-US/default/Windows_NT%206.1/default/default/update.xml?force=1

AUS:SVC gCanCheckForUpdates - able to check for updates

AUS:SVC Checker:checkForUpdates - sending request to: https://aus3.mozilla.org/update/3/Firefox/4.0b8pre/20101107042528/WINNT_x86-msvc/en-US/default/Windows_NT%206.1/default/default/update.xml?force=1

AUS:SVC Checker:onLoad - request completed downloading document

AUS:SVC Checker:onLoad - number of updates available: 0

AUS:SVC UpdateService:removeDownloadListener - no downloader!

Is that the right URL?  It sure is an empty "<updates> </updates>" for me.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

That URL is on the "default" channel, but about:buildconfig says

--enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-tests

so maybe we are not substing appropriately?  Where does that show up in the product itself?

Comment 4

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

The parameter following the build locale (e.g. en-US) is default and should be nightly.

This was caused by omnijar and was fixed in bug 591866. The fix was not left in the update mar per bug 591866 comment #33 which is why you didn't get the fix.

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

in backup-update.log from 08/21 I have

PREPARE REMOVE defaults/pref/channel-prefs.js
file does not exist; skipping

so how did I get to 11/07 build?

I wonder if there are others who are also stuck, and if we should just point default at nightly for that date range or something, hrm.

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Oh, that was the date of the _previous_ update, which was moved to backup-update when I brought this machine back online after 2 months in transit.  I guess.  No, that still doesn't make sense.

Comment 7

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

Because the build you were using didn't have channel-prefs.js due to it having it removed by omnijar. It needed to be added back by the update mar which was done by nthomas per bug 591866 but it was not left that way permanently. You then updated to a mar that no longer had the instruction to add back the channel-prefs.js since it was only left in temporarily.

I am not not sure if aus is flexible enough to point urls that are on the default channel and are obviously a nightly build based on the app version to the latest nightly but I suspect it can. Nick should be able to answer that.

Comment 8

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

We can actually address users on default quite precisely, by version & buildID like releases rather than the 'everyone gets the latest' style of nightlies. Just need to ensure we only do it for the exact buildIDs we've produced and exclude developer/homemade builds. Once we have AUS metrics back (613009) we can see how big the issue is.

Comment 9

[Dave Townsend [:mossop]]

If I'm reading this right this only affects a small class of nightly users and while we've potentially lost them from our nightly base I don't think that blocks the release unless it is a lot of people. Please re-nominate if I've missed something.

Comment 10

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Agree that it's not a blocker.  When we get the data from 613009, we can see if we need to put a specific catch-up update in place.

Comment 11

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

We now have the channel-prefs.js file in all updates and if the file doesn't exist it is added.