Last Comment Bug 808668 - Upgrade update.php script with new locations and re-enable automatic nightly updates by adding em:updateURL to install.rdf
: Upgrade update.php script with new locations and re-enable automatic nightly ...
Status: VERIFIED FIXED
:
Product: Calendar
Classification: Client Software
Component: Build Config (show other bugs)
: Lightning 2.1
: All All
: -- normal (vote)
: 2.3
Assigned To: Philipp Kewisch [:Fallen]
:
:
Mentors:
: 826750 (view as bug list)
Depends on: 793628 815991
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-05 10:18 PST by Stefan Sitter
Modified: 2013-02-21 12:00 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Add mozconfig - v1 (2.77 KB, patch)
2012-11-28 00:59 PST, Philipp Kewisch [:Fallen]
standard8: review+
philipp: checkin+
Details | Diff | Splinter Review
Remove exports, hardcode lightning update path - v1 (7.29 KB, patch)
2013-02-11 11:20 PST, Philipp Kewisch [:Fallen]
no flags Details | Diff | Splinter Review
Remove exports, hardcode lightning update path - v2 (7.37 KB, patch)
2013-02-11 11:31 PST, Philipp Kewisch [:Fallen]
standard8: review+
Details | Diff | Splinter Review

Description Stefan Sitter 2012-11-05 10:18:44 PST
After fixing Bug 793628 the produced Lightning nightly builds are now stored in a different location on the ftp server. 

Example old location:
> https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/win32-xpi/lightning.xpi

Example new location:
> https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/lightning-2.1a1.en-US.win32.xpi

Please upgrade the https://calendar.mozilla.org/update.php script with the new download locations and re-enable automatic updates by adding em:updateURL to install.rdf.
Comment 1 Philipp Kewisch [:Fallen] 2012-11-08 04:42:49 PST
I'd suggest waiting until we have aurora building on the tb machines, otherwise the code in update.php will get very ugly.
Comment 2 Peter Lairo 2012-11-20 12:22:48 PST
This bug is preventing auto-updates of Lightning nightly builds. (I wished the bug's Subject or Description would more clearly describe the user-facing effect of the bug - so I can recognize it when I get the "FIXED" e-mail)
Comment 3 Philipp Kewisch [:Fallen] 2012-11-28 00:59:32 PST
Created attachment 686026 [details] [diff] [review]
Add mozconfig - v1

This adds the update location to the mozconfigs, see dependent bug for the script change.

I never really found out what causes the env vars to be set. For the calendar infra we set this in the env in config.py. 

If someone can tell me in what cases setting things in the mozconfig works and in what cases it doesn't, I'd appreciate (for example, I always try to export JS_READLINE in my builds, but xpcshell never has editline compiled in until I make clean in the directory and then make again with that env var set)

Nevertheless, export DISABLE_LIGHTNING_INSTALL=1 seems to work, so I assume this will work too.
Comment 4 Philipp Kewisch [:Fallen] 2012-11-28 14:19:36 PST
Unfortunately I asked for the deploy before pushing the above patch. I've had the deploy backed out in bug 815991, we need to land the mozconfig changes first.

Some users might have received updates in the 5 hour window, those will not receive further updates until they manually install a newer nightly.

Mark, I'd appreciate if you could review this tomorrow or Friday so I can push the nightly builds and blog about it so users know whats going on.
Comment 5 Philipp Kewisch [:Fallen] 2012-11-29 00:32:56 PST
comm-central changeset e27059fc2753
Comment 6 Mark Banner (:standard8) 2012-11-29 00:34:15 PST
Comment on attachment 686026 [details] [diff] [review]
Add mozconfig - v1

a=me for comm-aurora.
Comment 7 Philipp Kewisch [:Fallen] 2012-11-29 00:41:02 PST
comm-aurora changeset d918883e2b72
Comment 8 Stefan Sitter 2012-12-08 10:06:44 PST
The patch doesn't seem to work. 
Neither comm-central nor comm-aurora Lightning builds have the em:updateURL set.
Comment 9 Stefan Sitter 2013-01-04 10:00:01 PST
*** Bug 826750 has been marked as a duplicate of this bug. ***
Comment 10 Stefan Sitter 2013-02-10 03:54:32 PST
Any other idea on how to re-enable nightly updates?
Comment 11 Philipp Kewisch [:Fallen] 2013-02-11 02:50:11 PST
Sorry for the delay. I've requested build vpn access again and will investigate the logs to see why this is not being picked up.
Comment 12 Philipp Kewisch [:Fallen] 2013-02-11 11:04:14 PST
Looks like its not that easy. It seems the environment variables set by the mozconfig are not picked up. I see two options here:

1) Add those exported variables to whatever build config sets up the environment for Thunderbird'd buildbot.

2) Hardcode the upgrade location and add in depending on another var that is set like:
   * IS_NIGHTLY=1
   * MOZ_UPDATE_CHANNEL=nightly


The other variable we set is DISABLE_LIGHTNING_INSTALL, which was used to make it not be installed into dist/bin for the stock Thunderbird package, but I guess thats being taken care of by the packager that just doesn't include Lightning.
Comment 13 Philipp Kewisch [:Fallen] 2013-02-11 11:09:33 PST
bug 759079 seems to be removing IS_NIGHTLY, so that leaves us with MOZ_UPDATE_CHANNEL
Comment 14 Stefan Sitter 2013-02-11 11:19:41 PST
How about using LIGHTNING_PRERELEASE_VERSION? 

But in this case all custom builds would have the URL too. Maybe combine e.g. LIGHTNING_PRERELEASE_VERSION with some other flag specific to the official Mozilla builds?

By the way: If DISABLE_LIGHTNING_INSTALL is specified via mozconfig and working why can't we specify LIGHTNING_UPDATE_LOCATION in the same location?
Comment 15 Philipp Kewisch [:Fallen] 2013-02-11 11:20:20 PST
Created attachment 712544 [details] [diff] [review]
Remove exports, hardcode lightning update path - v1

This patch would take care of option (2).
Comment 16 Philipp Kewisch [:Fallen] 2013-02-11 11:24:14 PST
(In reply to Stefan Sitter from comment #14)
> How about using LIGHTNING_PRERELEASE_VERSION? 
> 
> But in this case all custom builds would have the URL too. Maybe combine
> e.g. LIGHTNING_PRERELEASE_VERSION with some other flag specific to the
> official Mozilla builds?

I don't think using MOZ_UPDATE_CHANNEL is such a bad idea. After all, we only want this for nightly builds, and they will always have the update channel set to nightly or aurora (which is missing in the patch, I missed that)

> 
> By the way: If DISABLE_LIGHTNING_INSTALL is specified via mozconfig and
> working why can't we specify LIGHTNING_UPDATE_LOCATION in the same location?
I believe it is not working. See for example the logs at: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2013-02-11-03-04-58-comm-central/comm-central-linux-nightly-bm12-build1-build5.txt.gz

You will see DISABLE_LIGHTNING_INSTALL is not in the environment.
Comment 17 Philipp Kewisch [:Fallen] 2013-02-11 11:31:32 PST
Created attachment 712546 [details] [diff] [review]
Remove exports, hardcode lightning update path - v2
Comment 18 Mark Banner (:standard8) 2013-02-13 10:04:42 PST
Comment on attachment 712546 [details] [diff] [review]
Remove exports, hardcode lightning update path - v2

Given the previous comments, I can't see any issues with this.
Comment 19 Philipp Kewisch [:Fallen] 2013-02-13 15:35:14 PST
Pushed to comm-central changeset 9a7f8ded61c8
Comment 20 Philipp Kewisch [:Fallen] 2013-02-13 15:41:56 PST
Waiting to see how this works out. The next merge is on the 18th, so its probably fine to just wait for this to merge down.

I recall there was a shift of release/merge dates? I will probably have to change the update.php script a bit if this is true...
Comment 21 Philipp Kewisch [:Fallen] 2013-02-20 10:20:08 PST
This seems to be working, WaltS was nice enough to verify this on IRC. The merge just happened, so this should be down on aurora now.

<em:updateURL>https://calendar.mozilla.org/update.php?buildID=20130220030629&amp;appABI=%APP_ABI%&amp;appOS=%APP_OS%&amp;locale=%APP_LOCALE%&amp;appVersion=%APP_VERSION%&amp;appID=%APP_ID%</em:updateURL>
Comment 22 Peter Lairo 2013-02-20 11:19:14 PST
How can we verify this on Thunderbird Daily + Lightning Trunk? 

There seems to be no way to find out the build date of Lightning Trunk:

- Tools / Add-ons / Lightning only shows the version number (2.4a1). 

- Help / Troubleshooting Information / Extensions / Lightning also only shows the version number (and some weird ID number). 

Please help or fix.
Comment 23 Stefan Sitter 2013-02-21 10:19:37 PST
Update doesn't work because update.php is returning the wrong, old download locations:

> LOG addons.updates: Requesting https://calendar.mozilla.org/update.php?buildID=20130220042019&appABI=x86-msvc&appOS=WINNT&locale=en-US&appVersion=21.0a2&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}
> LOG addons.updates: Found an update entry for {e2fda1a4-762b-4020-b5ad-a41df1933103} version 2.3a3nightly
> LOG addons.xpi: Download of https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-aurora/win32-xpi/lightning.xpi completed.
> Warning: WARN addons.xpi: Download failed: 404 Not Found

Maybe due to the update.php backout in Bug 815991?
Comment 24 Philipp Kewisch [:Fallen] 2013-02-21 12:00:05 PST
Ah right, totally forgot about that one, thanks! Requested push in that bug.

Note You need to log in before you can comment on or make changes to this bug.