Closed
Bug 673501
Opened 14 years ago
Closed 14 years ago
Aurora win32 Auto/Manual update does not work since 20110720
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: alice0775, Unassigned)
Details
Build Identifier:
http://hg.mozilla.org/releases/mozilla-aurora/rev/ef4909389600
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110720 Firefox/7.0a2 ID:20110720225139
Reproducible: Always
Comment 1•14 years ago
|
||
Are you using a 64-bit or 32-bit build?
![]() |
Reporter | |
Comment 2•14 years ago
|
||
32-bit build
See Build Identifier
Comment 3•14 years ago
|
||
Did that changeset come from about:buildconfig? The date on it and your buildid doesn't match up...
![]() |
Reporter | |
Comment 4•14 years ago
|
||
(In reply to comment #3)
> Did that changeset come from about:buildconfig? The date on it and your
> buildid doesn't match up...
Yes, about:buildconfig
Comment 5•14 years ago
|
||
This is probably the intentional change made in bug 650258 but if you could set app.update.log = true in about:config, then start Firefox from a console, then open the open window and paste the "https://aus3.mozilla.org" URL that shows up in the console we can try to debug this a bit further.
![]() |
Reporter | |
Comment 6•14 years ago
|
||
*** AUS:SVC getLocale - getting locale from file: D:\MyDownload\firefox-aurora.en-US.win32\update.locale, locale: e
n-US
*** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/7.0a2/20110720225139/WINNT_x86-
msvc/en-US/aurora/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/7.0a2/20110720225139
/WINNT_x86-msvc/en-US/aurora/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
Comment 7•14 years ago
|
||
That's helpful, thanks. We seem to have an excess of nightlies on the 20th/21st:
[DIR] 2011-07-20-22-50-07-mozilla-aurora-l10n/ 21-Jul-2011 04:13 -
[DIR] 2011-07-20-22-50-07-mozilla-aurora/ 21-Jul-2011 04:10 -
[DIR] 2011-07-20-22-51-21-mozilla-aurora-l10n/ 21-Jul-2011 07:29 -
[DIR] 2011-07-20-22-51-21-mozilla-aurora/ 21-Jul-2011 03:16 -
[DIR] 2011-07-20-22-51-30-mozilla-aurora-l10n/ 21-Jul-2011 07:25 -
[DIR] 2011-07-20-22-51-30-mozilla-aurora/ 21-Jul-2011 03:24 -
[DIR] 2011-07-20-22-51-39-mozilla-aurora-l10n/ 21-Jul-2011 07:29 -
[DIR] 2011-07-20-22-51-39-mozilla-aurora/ 21-Jul-2011 02:44 -
[DIR] 2011-07-20-22-51-48-mozilla-aurora-l10n/ 21-Jul-2011 06:56 -
[DIR] 2011-07-20-22-51-48-mozilla-aurora/ 21-Jul-2011 02:30 -
[DIR] 2011-07-20-22-51-57-mozilla-aurora/ 21-Jul-2011 02:49 -
You've got one of them, with a fairly old changeset: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-07-20-22-51-39-mozilla-aurora/firefox-7.0a2.en-US.win32.txt
Not exactly sure what's going on here, we're still investigating.
Comment 8•14 years ago
|
||
bhearsum: dougt triggered at least 5 new nightly builds for
https://bugzilla.mozilla.org/show_bug.cgi?id=672787#c12
Comment 9•14 years ago
|
||
(In reply to comment #8)
> bhearsum: dougt triggered at least 5 new nightly builds for
> https://bugzilla.mozilla.org/show_bug.cgi?id=672787#c12
I think we're hitting some sort of race condition with the update logic here. I'm going to trigger a new set, which should fix everybody up.
Comment 10•14 years ago
|
||
(In reply to comment #9)
> (In reply to comment #8)
> > bhearsum: dougt triggered at least 5 new nightly builds for
> > https://bugzilla.mozilla.org/show_bug.cgi?id=672787#c12
>
> I think we're hitting some sort of race condition with the update logic
> here. I'm going to trigger a new set, which should fix everybody up.
Done. The Windows update _should_ be ready in about 3 hours.
Comment 11•14 years ago
|
||
Actually, Aki pointed out that I can fix things up now by moving away the bad snippets. I did that and your update URL seems to be working now:
https://aus3.mozilla.org/update/3/Firefox/7.0a2/20110720225139/WINNT_x86-msvc/en-US/aurora/Windows_NT%206.1/default/default/update.xml?force=1
(I also did it for the other platforms.)
I'm letting the existing nightlies I triggered run, no reason to kill them.
Thanks for reporting this!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
![]() |
Reporter | |
Comment 12•14 years ago
|
||
(In reply to comment #11)
> Actually, Aki pointed out that I can fix things up now by moving away the
> bad snippets. I did that and your update URL seems to be working now:
> https://aus3.mozilla.org/update/3/Firefox/7.0a2/20110720225139/WINNT_x86-
> msvc/en-US/aurora/Windows_NT%206.1/default/default/update.xml?force=1
>
> (I also did it for the other platforms.)
>
> I'm letting the existing nightlies I triggered run, no reason to kill them.
>
> Thanks for reporting this!
Aurora updated now
But, the build is not 0722 nightly.
What is going on?
http://hg.mozilla.org/releases/mozilla-aurora/rev/9a3234ac5c1c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110720 Firefox/7.0a2 ID:20110720225148
![]() |
Reporter | |
Comment 13•14 years ago
|
||
log:
*** AUS:SVC getLocale - getting locale from file: D:\fuku\MyDownload\firefox-aurora.en-US.win32\update.locale, locale: e
n-US
*** AUS:SVC Checker:getUpdateURL - update URL: https://aus3.mozilla.org/update/3/Firefox/7.0a2/20110720225148/WINNT_x86-
msvc/en-US/aurora/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/7.0a2/20110720225148
/WINNT_x86-msvc/en-US/aurora/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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 14•14 years ago
|
||
This is correct. bug 650258 changed our build systems so that we don't generate nightly builds unless changes have been made to a repository. We didn't have any changes on Aurora after the 20th until today: http://hg.mozilla.org/releases/mozilla-aurora/.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
![]() |
Reporter | |
Comment 15•14 years ago
|
||
(In reply to comment #14)
> This is correct. bug 650258 changed our build systems so that we don't
> generate nightly builds unless changes have been made to a repository. We
> didn't have any changes on Aurora after the 20th until today:
> http://hg.mozilla.org/releases/mozilla-aurora/.
However, On Linux i386 build, The latest Aurora Nightly is as follows.
http://hg.mozilla.org/releases/mozilla-aurora/rev/08ce839b81cc
Mozilla/5.0 (X11; Linux i686; rv:7.0a2) Gecko/20110722 Firefox/7.0a2 ID:20110722042002
Can you explain this?
![]() |
Reporter | |
Comment 16•14 years ago
|
||
(In reply to comment #14)
> didn't have any changes on Aurora after the 20th until today:
> http://hg.mozilla.org/releases/mozilla-aurora/.
See Pushlog bettween the 9a3234ac5c1c 0720 and 08ce839b81cc 0722 build,
There are many change( include for win32).
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=9a3234ac5c1c&tochange=08ce839b81cc
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•14 years ago
|
||
I see what you mean. Investigating.
Comment 18•14 years ago
|
||
Things are a bit screwy because the Windows nightly from 2011072104 failed. That, combined with all the extra nightlies that happened later that night got those snippets in a weird state. I think I got the right snippets in place now, can you try to update again?
![]() |
Reporter | |
Comment 19•14 years ago
|
||
Update is successfully performed now.
http://hg.mozilla.org/releases/mozilla-aurora/rev/08ce839b81cc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a2) Gecko/20110722 Firefox/7.0a2 ID:20110722042002
Thanks.
Comment 20•14 years ago
|
||
Thanks again for reporting. Just to be clear: You'll be getting another update in a couple of hours (that's the one I triggered in comment #10), and possibly one tomorrow, if someone lands.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
![]() |
Reporter | |
Updated•14 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•