Closed Bug 612600 Opened 11 years ago Closed 4 years ago

windows build not updating


(Toolkit :: Application Update, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- -


(Reporter: shaver, Unassigned)



(1 file)

Attached file updates.xml
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre
Built from

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:

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.
blocking2.0: --- → ?
Version: unspecified → Trunk
What is the Error Console Output if you set app.update.log to true beforehand?
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:

AUS:SVC gCanCheckForUpdates - able to check for updates

AUS:SVC Checker:checkForUpdates - sending request to:

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.
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?
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.
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.
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.
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.
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.
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.
blocking2.0: ? → -
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.
We now have the channel-prefs.js file in all updates and if the file doesn't exist it is added.
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.