Closed
Bug 600000
Opened 15 years ago
Closed 14 years ago
Partial update for SeaMonkey nightly builds doesn't work
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mcsmurf, Unassigned)
Details
Attachments
(2 files, 1 obsolete file)
Currently the partial nightly updates for SeaMonkey do not work due to a failing CRC check, see Attachment 478670 [details] for an update log. The full update does work fine.
Comment 1•15 years ago
|
||
![]() |
||
Comment 2•15 years ago
|
||
Congratulations! timeless didn't file the 600000th bug this time! ;)
Reporter | ||
Comment 3•15 years ago
|
||
He can try Bug 7000000 then again, I estimate January 2014 :)
Reporter | ||
Comment 4•15 years ago
|
||
Whoa, Bug 700000 even
Reporter | ||
Comment 5•15 years ago
|
||
and actually I meant 2012 :o
Comment 6•15 years ago
|
||
Because the world ends when the bug count gets to high, in dec 2012 ;)
Comment 7•15 years ago
|
||
Comment 8•15 years ago
|
||
Attachment #478887 -
Attachment is obsolete: true
Cannot confirm on my end.
Today's partial .mar updated without incident.
Win 7 x86.
Update from 20100926 to 20100927.
Don't really know how .mar's work, but am I to take it that the sha512 hash (from updates.xml) of the .mar would have been valid (so it was not a download issue).
> That looks to be the case.
And that when scanning the files (existing files, I presume, not from within the .mar itself, as that would be kind of redundant if the sha512 hash verified?) that it then came up with an error in chatzilla.jar (from your log)?
> Ditto.
If cZ, would a Profile install of cZ (in addition to, or in place of a SeaMonkey installation directory install) have any bearing?
> No.
If you were to manually download the partial .mar (& manually verify the sha512 hash of same) will a manual update from same complete?
https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
> Shouldn't have to.
Instead:
1. download:
ftp://ftp.mozilla.org/pub/seamonkey/nightly/2010/09/2010-09-26-01-comm-central-trunk/seamonkey-2.1b1pre.en-US.win32.installer.exe
2. install
3. check for updates & apply.
You should get a partial .mar download & it should work.
(Appears you can only be one day old, or else you will get a full .mar instead of partial. So if you were attempt this tomorrow you would need to start with an installer of the 27th. ZIP should work just as well.)
Appears your error indicates just what it says:
> \SeaMonkey\extensions\{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}\chrome\chatzilla.jar
(the existing version on disk) is either corrupt or was modified & that is all that is needed to generate the CRC error.
I can duplicate it, basically.
Follow steps 1 & 2 above.
Use a hex editor to modify chatzilla.jar, changing the first two bytes from "PK" to "XX". (Do not change the file size.)
Continue with stop 3.
You should get the same CRC failure & subsequent .mar failure.
Comment 10•15 years ago
|
||
Compare your existing chatzilla.jar to (some other relatively recent) version.
(Note that while the jar itself may differ the contents within can still be the same. That would be due to differences in the packing. And then there are other times when the contents /did/ change, like when the change from "menu" to "menupopup" landed. Even so, the version number did remain the same, 0.9.86.)
Comment 11•15 years ago
|
||
Just tried it with linux and it worked. Will try what therube wrote in the previous comments later.
Comment 12•15 years ago
|
||
Together with Frank I found out why it fails. The 20100927 .zip-build has a slightly different chatzilla.jar than the installer-build (different date of contents.rdf). For the installer-build the updated worked, for the .zip-build it failed.
So the update from a fresh .zip-build fails the first time. After the fallback installation of the full update we are back in a state where the next partial update applies again (it did so for the build 20100926 I've updated with the complete .mar to 20100927 yesterday).
Reporter | ||
Comment 13•15 years ago
|
||
The problem is probably the .zip build gets packaged first and after that it repackages the extensions again (with the en_US locale) and so recreates all the extensions folders again. In that step it seems to recreate the contents.rdf inside the .jar file.
Comment 14•15 years ago
|
||
This also affects updates from 2.1a3 .zip builds to 2.1b1, I got the same CRC error for the partial update on betatest. Full update worked afterwards.
Comment 15•15 years ago
|
||
This seems related to bug 404340.
Reporter | ||
Comment 16•14 years ago
|
||
Partial updates certainly work again :)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•