Closed Bug 487012 Opened 11 years ago Closed 11 years ago
License file not found for nightly update
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.
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.
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?
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.
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.
(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.
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?
Depends on: 473337
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.
> 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.
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?
(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.
Attachment #372423 - Flags: review? → review?(kairo)
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?
Attachment #372423 - Flags: review?(kairo) → review?(robert.bugzilla)
Attachment #372423 - Flags: review?(robert.bugzilla) → review+
Assignee: installer → nobody
Component: Installer → Application Update
Product: SeaMonkey → Toolkit
QA Contact: xpi-packages → application.update
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/0ff7df5ccda2
Assignee: nobody → ddahl
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #372423 - Flags: approval1.9.1?
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.
Attachment #372423 - Flags: approval1.9.1? → approval1.9.1+
Comment on attachment 372423 [details] [diff] [review] added NSINSTALL -D for icon path a191=beltzner
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...
Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/300fca604d16
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 :-/
You will need a build after the patch has landed
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?
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.
Adds the icon to the packaging file.
Attachment #374471 - Flags: review?(kairo)
Comment on attachment 374471 [details] [diff] [review] Patch Pushed to comm-central, changeset ef0afa0249b2
robert, can you verify this fix against seamonkey on the latest 1.9.1 branch and trunk nightly? Please mark it verified then. Thanks.
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.
Updating 20090425 to 20090427 worked for me too -> VERIFIED
Status: RESOLVED → VERIFIED
Howdy, I'm still having this problem with Seamonkey. I'm not sure about firefox since I have stopped using it. George...
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.
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...
You need to log in before you can comment on or make changes to this bug.