600000 - Partial update for SeaMonkey nightly builds doesn't work

Status: RESOLVED WORKSFORME

(SeaMonkey :: Build Config, defect)

Description

[Frank Wein [:mcsmurf]]

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

[Sean Martell]

Attachment: 600,000!

Comment 2

[Frédéric Buclin]

Congratulations! timeless didn't file the 600000th bug this time! ;)

Comment 3

[Frank Wein [:mcsmurf]]

He can try Bug 7000000 then again, I estimate January 2014 :)

Comment 4

[Frank Wein [:mcsmurf]]

Whoa, Bug 700000 even

Comment 5

[Frank Wein [:mcsmurf]]

and actually I meant 2012 :o

Comment 6

[Tyler Downer [He/Him]]

Because the world ends when the bug count gets to high, in dec 2012 ;)

Comment 7

[Jennifer Morrow [:Boriss] (UX)]

Attachment: 600,000?

Comment 8

[Jennifer Morrow [:Boriss] (UX)]

Attachment: 600,000?

Comment 9

[therube]

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

[therube]

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

[Bruno 'Aqualon' Escherl]

Just tried it with linux and it worked. Will try what therube wrote in the previous comments later.

Comment 12

[Bruno 'Aqualon' Escherl]

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).

Comment 13

[Frank Wein [:mcsmurf]]

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

[Bruno 'Aqualon' Escherl]

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

[Florian Quèze [:florian]]

This seems related to bug 404340.

Comment 16

[Frank Wein [:mcsmurf]]

Partial updates certainly work again :)