487012 - License file not found for nightly update

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Bruno 'Aqualon' Escherl]

Since 20090403 I can't autoupdate SeaMonkey anymore.

SeaMonkey was downloading the nightly, but after the restart I still had the
build from 20090402. "Check for updates..." said, that the license file could
not be found (same issue as in TB bug 466187).

I made a manual update to 20090403, but the update to today's build (20090405) still won't work. I've also tried it with a clear profile, so that shouldn't be the problem.

Comment 1

[Bruno 'Aqualon' Escherl]

I've tried to update from 2.0a2 to 2.0a3 and that worked without a problem. Also an update from 2.0a2 to Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b4pre) Gecko/20090406 SeaMonkey/2.0b1pre worked fine after changing the update channel.

Comment 2

[Bruno 'Aqualon' Escherl]

I checked some older builds, updating works for SeaMonkey until 20090401, with 20090402 and newer I get the license file not found error.

I haven't found any changeset from that range, that could have resulted in that behaviour.

Kairo: where there any tinderbox problems/changes at that time, that could result in this?

Comment 3

[David Dahl :ddahl]

Just curious if SeaMonkey uses 'packages-static' for media files that should be part of the build? I am a build nob, but I know Rob Strong (rs) was telling me that other products like SeaMonkey and Thunderbird may use a different mechanism for copying media into the build.

My patch in 473337 adds a new icon for the updater and displays a frame around the updater progress ui - pretty basic. I had more trouble with the build than anything else.

Comment 4

[Bruno 'Aqualon' Escherl]

I've found the problem, SeaMonkey is missing the updater.png icon, that was introduced in but 473337, because we don't create a icons/ folder during packaging like Thunderbird and Firefox do.

We probably need something like the code in http://mxr.mozilla.org/mozilla1.9.1/source/browser/app/Makefile.in#301 et seq, even I don't understand, what exactly happens there.

Comment 5

[Robert Kaiser]

(In reply to comment #3)
> Just curious if SeaMonkey uses 'packages-static' for media files that should be
> part of the build?

That's probably where the problem lies. SeaMonkey and Thunderbird are using their own packages(-static) files and those probably need to be updated to include this file.

Comment 6

[Robert Kaiser]

Actually, no, packages stuff isn't involved here, it's just dist/bin/icons that matters, as it doesn't exist in SeaMonkey (I actually don't understand for what reason it even exists in the other apps).

David, is there any special reason this wasn't put into dist/bin/chrome/icons/default/ where all other icons are usually placed?

Comment 7

[Robert Kaiser]

Oh, forgot to mention that either putting it into the above-mentioned dir or adding a nsinstall -D for the directory into http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/mozapps/update/src/updater/Makefile.in#122 should both fix the problem.

Comment 8

[David Dahl :ddahl]

> David, is there any special reason this wasn't put into
> dist/bin/chrome/icons/default/ where all other icons are usually placed?

perhaps because the icons are specific to the updater application and not the base application. I remember speaking with Robert Strong (rs) about that, he may have a better rationalization, as I am so new to non front-end code.

Comment 9

[Robert Strong (they/them - no direct email)]

David, I'm tempted to just put the png in dist/bin since this is an issue for SeaMonkey in order to avoid this anywhere else and simplify the copy routine. Would you be cool with doing that?

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to comment #8)
> > David, is there any special reason this wasn't put into
> > dist/bin/chrome/icons/default/ where all other icons are usually placed?
> 
> perhaps because the icons are specific to the updater application and not the
> base application. I remember speaking with Robert Strong (rs) about that, he
> may have a better rationalization, as I am so new to non front-end code.
This is what I was trying to avoid with bug 473337 comment #47 since I didn't know that SeaMonkey didn't have a dist/bin/icons dir like Firefox, Thunderbird, and Sunbird.

(In reply to comment #9)
> David, I'm tempted to just put the png in dist/bin since this is an issue for
> SeaMonkey in order to avoid this anywhere else and simplify the copy routine.
> Would you be cool with doing that?
Scratch that... just use nsinstall -D since we are getting close to release.

Comment 11

[David Dahl :ddahl]

Attachment: added NSINSTALL -D for icon path

Comment 12

[Robert Kaiser]

Comment on attachment 372423 [details] [diff] [review]
added NSINSTALL -D for icon path

Sorry, I'm no toolkit peer, it looks like the right fix, but a toolkit person should review. Rob?

Comment 13

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/0ff7df5ccda2

Comment 14

[Robert Strong (they/them - no direct email)]

Comment on attachment 372423 [details] [diff] [review]
added NSINSTALL -D for icon path

Drivers, this is a very safe / simple fix which creates the dist/bin/icons directory on linux for the update icon. Turns out SeaMonkey doesn't have that directory so this is necessary.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 372423 [details] [diff] [review]
added NSINSTALL -D for icon path

a191=beltzner

Comment 17

[George R. Goffe]

Howdy,

If you guys want me to test anything just let me know.

Otherwise I'll keep looking for this "bug" to be distributed.

Regards,

George...

Comment 18

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/300fca604d16

Comment 19

[Bruno 'Aqualon' Escherl]

I tried to update from 20090423 to 20090424 and it didn't work. The patch changed the issue so far, that I don't get the "license file not found" popup after the restart, but a popup that tells me I have to restart SeaMonkey and after this restart I still have 20090423. Manually copying updater.png into /icons still helps.

So this fix doesn't seem to be enough :-/

Comment 20

[Robert Strong (they/them - no direct email)]

You will need a build after the patch has landed

Comment 21

[Bruno 'Aqualon' Escherl]

According to the tinderbox, 20090423 was built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/82172f146af3 and that was after this patch landed on 1.9.1. Or do I interpret something wrong when looking at http://hg.mozilla.org/releases/mozilla-1.9.1/log/24984?

Comment 22

[Robert Kaiser]

I think we actually need to add the icon to the suite/installer/unix/packages file. Firefox has a wildcard there for packaging all icons from that directory, so they didn't need a special addition, I'd rather go for explicitly referring to that icon in our file though.

Comment 23

[Frank Wein [:mcsmurf]]

Attachment: Patch

Adds the icon to the packaging file.

Comment 24

[Frank Wein [:mcsmurf]]

Comment on attachment 374471 [details] [diff] [review]
Patch

Pushed to comm-central, changeset ef0afa0249b2

Comment 25

[Tony Chung [:tchung]]

robert, can you verify this fix against seamonkey on the latest 1.9.1 branch and trunk nightly?   Please mark it verified then.  Thanks.

Comment 26

[Tobias Fischer]

I run the Autoupdate with SeaMonkey 2009042500 Nightly-Build and have successfully updated to the 2009042600 Nightly-Build on OpenSUSE 11.1, so I can verify that this Issue was fixed now in the current 1.9.1 branch Builds. 

But before I have tried to update the 2009042300 Nightly to 2009042600, and it was still failing.

Comment 27

[Bruno 'Aqualon' Escherl]

Updating 20090425 to 20090427 worked for me too -> VERIFIED

Comment 28

[George R. Goffe]

Howdy,

I'm still having this problem with Seamonkey. I'm not sure about firefox since I have stopped using it.

George...

Comment 29

[Robert Strong (they/them - no direct email)]

This bug is verified fix and there are no other reports of this happening. Please file a new bug under toolkit -> application update with the appropriate details.

Comment 30

[George R. Goffe]

Robert,

Thanks for responding to my request.

The bug report I filed was marked closed as a dup of this bug.

By the way, I tested firefox (minefield) and it behaved the same way.

This is on my CentOS 5.3 system.

Regards,

George...