In bug 381420, a new aus2-community server was created for community projects using the automatic update service (AUS). We now need to make SeaMonkey work with AUS2, using this server.

So, ause from the Sunbird team (who are using aus2-community already) is telling me the first step we need is to create full .mar files in tinderboxes, which should be just a tinder-config change, I'll look into that. Partial .mar updates need bug 404768 fixed, ause has a review pending there. The next step after generating the full .mar files will be to figure out uploading - "the user, the key, the tree and so on" as ause calls it.

FYI, status of this is as follows: I added those settings to tinder-config.pl (only platform varies between win/linux/mac): ------------------------------------------- $update_package = 1; $update_product = "SeaMonkey"; $update_version = "trunk"; $update_platform = "Linux_x86-gcc3"; $update_hash = "sha1"; $update_filehost = "ftp.mozilla.org"; $update_ver_file = 'suite/config/version.txt'; $update_pushinfo = 0; # override tinder-defaults.pl to use community server $update_aus_host = 'aus2-community.mozilla.org'; ------------------------------------------- Those additions were made to mozconfigs (MOZ_CO_MODULE has been extended where it was already defined): ------------------------------------------- mk_add_options MOZ_CO_MODULE="mozilla/tools/update-packaging" ac_add_options --enable-update-channel=nightly ac_add_options --enable-update-packaging ------------------------------------------- Additionally, the following line had to be added to mozilla/suite/confvars.sh: ------------------------------------------- MOZ_UPDATER=1 ------------------------------------------- With this, we hopefully should have complete MARs for the nightlies the first time in a few hours, but the info is not pushed to the AUS server yet, that's the next thing to figure out when this first step is confirmed complete.

Ah, we just found out that we also needed to add mozilla/suite/locales/en-US/updater/updater.ini

The first builds that include updater have been generated now, as well as the first complete MARs. All that can't be really used yet though, as we need to figure out the server side and push info there (see $update_pushinfo in comment #2) - and I guess we also need some client-side integration of updater in the SeaMonkey app as well.

Here's what we need for the client-side integration - at least for starters. Obviously I haven't tested this fully yet, but it should be reasonable. Still need to find the correct place for the styling (DOMI won't show the icon on the menuitem when loading an update) - possibly in a new utilityOverlay.css?

Fixes some bitrot hopefully.

blocking-seamonkey2.0a1+ per Council agreement on http://home.kairo.at/blog/2008-01/seamonkey_2_alpha_criteria

Comment on attachment 294339 [details] [diff] [review] Client integration v2 >Index: suite/common/utilityOverlay.js >=================================================================== >+ // If there's an update ready to be applied, show the "Update Downloaded" >+ // UI instead and let the user know they have to restart the browser for >+ // the changes to be applied. >+ if (um.activeUpdate && um.activeUpdate.state == "pending") >+ prompter.showUpdateDownloaded(um.activeUpdate, false); This should now lose the "false" argument per bug 391598

i found an already existing user "seabld" on aus2-community and set up some directories for uploads. try to enable pushing and we'll find out what i missed

ause, thanks for looking into that, I just checked in a change to set $update_pushinfo = 1; on the SeaMonkey tinderboxen, let's see how it works out.

General note for when we do get this enabled, kb already has a page listing some information/problems & resolutions with software update: http://kb.mozillazine.org/Software_Update

Adds the generation of the app.update.channel preference in a channel-prefs.js file. I'm assuming FF does it this way to make it easy for testers to modify the value if they want to. Note that toolkit reads the default pref branch, so changes in about:config won't apply here (see also the kb.mozillazine.org link I just posted). I've put it in suite/browser alongside browser-prefs.js as I though that was most sensible, as we don't have <foo>/app/profile etc like the rest do.

Updated patch for the menus/preferences etc. Fixes a few bugs from the previous version, also removes the throbber from the menu as the text should be enough (note I left the attributes in, just in case someone wants to play around with it in an extension).

(In reply to comment #12) > I've put it in suite/browser alongside browser-prefs.js as I though that was > most sensible, as we don't have <foo>/app/profile etc like the rest do. I'd prefer to have it in common/ instead of browser/ if possible...

Comment on attachment 297069 [details] [diff] [review] Client integration v3 >@@ -179,18 +179,10 @@ Different bug ;-) >+ // Disable the UI if the update enabled pref has been locked by the >+ // administrator or if we cannot update for some other reason Nit: trailing space. I found another reason we cannot update, which isn't covered here ;-) I'd better file a bug on the updater... >+ // If there's an active update, substitute its name into the label >+ // we show for this item, otherwise display a generic label. What about accesskeys? >+<!ENTITY updateCmd.label "Check for Updates…"> We're not on ellipses yet...

It looks like aus2-community is now offering update info for SeaMonkey nightlies, see e.g. https://aus2-community.mozilla.org/update/1/SeaMonkey/2.0a1pre/2008011501/Linux_x86-gcc3/en-US/nightly/update.xml

FYI, bug 302721 comment #43 explains why channel-prefs.js is a separate file and not part of a bigger prefs file.

I've just been trying to get this to work - it helps if we include the updater{,.exe} in our packages.

Updated client integration patch. Addresses Neil's comments, also removes redundant warning about updates being disabled...

Comment on attachment 297752 [details] [diff] [review] [checked in] Client integration v4 >+function buildHelpMenu() Badly named (although I guess updateUpdateItem() isn't much better). >+ if (!gUtilityBundle) >+ gUtilityBundle = document.getElementById("bundle_utilityOverlay"); File a bug on fixing the other users of utilityOverlay.properties? >+updatesItem_downloading=Downloading %S… ... >+updatesItem_pendingAccessKey=A Can't use A (About &brandShortName;); U perhaps?

Comment on attachment 297752 [details] [diff] [review] [checked in] Client integration v4 (In reply to comment #20) > (From update of attachment 297752 [details] [diff] [review]) > >+function buildHelpMenu() > Badly named (although I guess updateUpdateItem() isn't much better). I went with updateCheckUpdatesItem(). > >+ if (!gUtilityBundle) > >+ gUtilityBundle = document.getElementById("bundle_utilityOverlay"); > File a bug on fixing the other users of utilityOverlay.properties? Will do in a bit. Patch checked in.

(In reply to comment #21) > > >+ if (!gUtilityBundle) > > >+ gUtilityBundle = document.getElementById("bundle_utilityOverlay"); > > File a bug on fixing the other users of utilityOverlay.properties? > > Will do in a bit. I don't know if it's the same kind of issue, but I'm getting [ Error: activeUpdate is not defined Source File: chrome://communicator/content/utilityOverlay.js Line: 479 ] when hovering/opening the Help menu while an update is hidden (suspended or in-progress). Code is [ if (um.activeUpdate && um.activeUpdate.name) checkForUpdates.label = gUtilityBundle.getFormattedString("updatesItem_" + key, [activeUpdate.name]); ] Missing |um.| on the last line !?

>+ // If we're downloading an update at present, show the text: >+ // "Downloading Firefox x.x..." otherwise we're paused, and show >+ // "Resume Downloading Firefox x.x..." I don't think we are downloading Firefox. Otherwise something is seriously wrong.

I have reports from Windows and Linux nightly users at least that they have/had the update dialog popping up on the screen, so I guess this bug is fixed, and we can defer further work to followups.

(In reply to comment #25) > I have reports from Windows and Linux nightly users at least that they have/had > the update dialog popping up on the screen, so I guess this bug is fixed, and > we can defer further work to followups. > Ok, I've heard a few good reports as well. Marking as fixed.

Comment on attachment 298284 [details] [diff] [review] [checked in] Fix Menu display for um.activeUpdate {{ 2008-01-22 09:09 bugzilla%standard8.plus.com mozilla/suite/common/utilityOverlay.js 1.108 }} This part is V.Fixed in [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008012202 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) (Confirming that I got the "popup" and an update (20080125xx) was automatically downloaded then installed on next application startup.) *** V.Fixed. (although there may still be 1-2 nits to fix.)

*Attachment 297752 [details] [diff] comment fix, per comment 24. *(whole file) Space/Tab cleanup, while we're there.

Checking in suite/common/utilityOverlay.js; /cvsroot/mozilla/suite/common/utilityOverlay.js,v <-- utilityOverlay.js new revision: 1.109; previous revision: 1.108 done

(In reply to comment #20) > >+ if (!gUtilityBundle) > >+ gUtilityBundle = document.getElementById("bundle_utilityOverlay"); > File a bug on fixing the other users of utilityOverlay.properties? That's now bug 445790.