Closed Bug 313923 Opened 20 years ago Closed 20 years ago

[Mac only] Unable to update on the Mac - 20051025-11 build

Categories

(Toolkit :: Application Update, defect)

1.8.0 Branch
PowerPC
macOS
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: marcia, Assigned: chase)

References

()

Details

(Keywords: verified1.8)

Seeing using 20051025-11 I am using the above build with the following parameters: BuildID = "2005102511", Firefox Mac OSX version 10.3.9, EN-US, nightly channel. I don't get an auto update notification that a new update is available, despite the fact there is one available. Manually checking for updates returns a message that no update is available. Tracy is seeing the same thing using the same build ID.
I saw the same problem with the -11 build. For grins, I downloaded the Firefox 2005-10-25-14 build, changed the channel to nightly and tried to update to get the -19 respin. I also got a no updates available message from the server. Note for readers at home: -19 is our current RC1 candidate build. So that was the last respin from Tuesday.
How did you change the update channel?
If I download the 20051025-03 build, I am able to perform one successful update to the 20051025-11 build. Then when I go to check for updates, I get no updates found, despite the fact that there are additional updates available on that date.
by modifying channel-pref.js by hand in the application package.
Thunderbird does not have this problem. I was able to upgrade from 10/24 through all of the respins from 10/25 and ended up with this morning's 10/26 build.
nominating this to get it on the radar.
Flags: blocking1.8rc1?
I used the live http headers extension and got the following http log: https://aus2.mozilla.org/update/1/Firefox/1.5/2005102515/Darwin_ppc-gcc3/en-US/nightly/update.xml GET /update/1/Firefox/1.5/2005102515/Darwin_ppc-gcc3/en-US/nightly/update.xml HTTP/1.1 Host: aus2.mozilla.org User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: no-cache HTTP/1.x 200 OK Date: Wed, 26 Oct 2005 20:30:39 GMT Server: Apache/2.0.52 (Red Hat) X-Powered-By: PHP/4.3.9 Content-Length: 42 Connection: close Content-Type: text/xml; ---------------------------------------------------------- so it looks like we are talking to AUS2 and getting a response.
Scott, notice that if you load that URL in the browser that it results in an empty XML document. In other words, it looks like this is a bug with AUS.
When I run the update url the Mac build generates: https://aus2.mozilla.org/update/1/Firefox/1.5/2005102515/Darwin_ppc-gcc3/en-US/nightly/update.xml I get back an empty XML file from the server.
FWIW: If you change the build hour to "14" in that URL, then you get an XML file that updates from the "14" hour to the "19" hour. And, if you change it to the "19" hour, then you get an update to the 2005102603 build.
(In reply to comment #10) > When I run the update url the Mac build generates: > > https://aus2.mozilla.org/update/1/Firefox/1.5/2005102515/Darwin_ppc-gcc3/en-US/nightly/update.xml > > I get back an empty XML file from the server. What is the build ID of the build you are running? It should be 2005102514, not 2005102515. (fyi AUS2 has data for 2005102514.) If it's 2005102515, that seems strange given that there was no respin that started in that hour. Even the dated directory has an hour of 14.
Note: Chase just pointed out that the URL I'm trying to run isn't a valid build id. there isn't a build from 20051025-15, the master.ini file for the same build says 2005102514 (which is valid). So where are we getting this -15 id from in the update url?
Build log from that build: http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1130275020.2564.gz&fulltext=1 Somehow *two* build IDs are being compiled in. The first build ID is 2005102514: ... cc -o db.o -c -DOSTYPE=\"Darwin7.9.0\" -DOSARCH=\"Darwin\" -DBUILD_ID=2005102514 -DMEMMOVE ... This is the one that the majority of the app uses, including Talkback and the AUS infrastructure. The second build ID is 2005102515: ... nsGREDirServiceProvider.cpp c++ -o nsGREDirServiceProvider.o -c -DOSTYPE=\"Darwin7.9.0\" -DOSARCH=\"Darwin\" -DBUILD_ID=2005102515 ... Software update in the client must be using this second build ID. We need to unify the build IDs to ensure this doesn't happen in the future, but the shorter term fix is an infrastructure update to ensure the right data appears in the right places for these builds.
Filed bug 313939 on fixing the build ID variance issue.
(In reply to comment #14) > ... but the shorter term fix is an infrastructure update to ensure the right > data appears in the right places for these builds. I've updated the patch info host with the magic incantations. The System will grind for 20-25 minutes as It happens. After, new updates for the appropriate builds should appear. I will keep a watchful eye throughout this period.
Assignee: nobody → chase
Status: NEW → ASSIGNED
Not suprisingly, the regularly scheduled morning branch build from today looks good since it started at a "good" time. It has the same build ID in the software update url request as the value in the master.ini file.
Okay, everything's propagated. Could everyone who's having problems because of this bug try updating now?
update is working for me now on the Mac, Updated from the -14 to the -19 to the 10/26 nightly.
fixed-on-trunk, fixed1.8
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
looks good - i was able to update from the build referenced above (20051025-11) to the BuildID = "2005102603" build. thanks for the hard work chase and scott. adding verified keyword.
Keywords: fixed1.8verified1.8
flag cleanup
Flags: blocking1.8rc1? → blocking1.8rc1+
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.