update.php script not returning correct update information

RESOLVED FIXED

Status

Calendar
Build Config
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: ssitter, Assigned: martinschroeder)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Checking for Lightning updates seem to be broken since at least 2013-05-06 (assuming because this is the build id of the last installed Lightning build)

The requested URL 
> https://calendar.mozilla.org/update.php?buildID=20130506004001&appABI=x86-msvc&appOS=WINNT&locale=en-US&appVersion=22.0a2&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}
returns only empty update information.

It should provide update link to latest-comm-aurora/lightning-2.4a2.en-US.win32.xpi
(Reporter)

Comment 1

5 years ago
It seems that something is broken in the version matching. A check on comm-central using Thunderbird 23.0a1 using the URL

> https://calendar.mozilla.org/update.php?buildID=20130510114800&appABI=x86-msvc&appOS=WINNT&locale=en-US&appVersion=23.0a1&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}

returns a download link to a non-existing comm-aurora build for non-existing Thunderbird 23.0a2: https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-aurora/lightning-2.5a2.en-US.win32.xpi
Summary: update.php script not returning update information → update.php script not returning correct update information
(Reporter)

Comment 2

5 years ago
Still doesn't work. But now it throws SSL error instead of creating wrong information:

> LOG addons.updates: Requesting https://calendar.mozilla.org/update.php?buildID=20130524030633&appABI=x86-msvc&appOS=WINNT&locale=en-US&appVersion=24.0a1&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}

> calendar.mozilla.org:443 uses an invalid security certificate.
> The certificate is only valid for tbpl.mozilla.org
> (Error code: ssl_error_bad_cert_domain)

> Warning: WARN addons.updates: HTTP Request failed for an unknown reason
> Source file: resource://gre/modules/AddonUpdateChecker.jsm Line: 521
Summary: update.php script not returning correct update information → update.php script not returning correct update information; SSL error "calendar.mozilla.org:443 uses an invalid security certificate"
SSL error is gone now, I still haven't found time to fix the script though. Anyone want to take a look what needs to be changed?
Summary: update.php script not returning correct update information; SSL error "calendar.mozilla.org:443 uses an invalid security certificate" → update.php script not returning correct update information
(Assignee)

Comment 4

4 years ago
Philipp: Where can I find the source of the PHP script?
(Assignee)

Updated

4 years ago
Assignee: nobody → mschroeder
Status: NEW → ASSIGNED
(Reporter)

Comment 6

4 years ago
Check for today returns nothing:
> https://calendar.mozilla.org/update.php?buildID=20140302004002&appABI=x86-msvc&appOS=WINNT&locale=en-US&appVersion=29.0a2&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}

From a quick look it seems the script operates on the date (referenceStartTime). If I recall correctly several releases were shifted e.g. due to winter holidays. Maybe script is out of sync with release cycle?

Lightning version number is calculated from Thunderbird version number. Why not use the same algorithm to determine the Lightning version to download based on the passed appVersion? But this would not work for SeaMonkey, ... Maybe we could use the Gecko version in addition?
I just did a quick check, changing the date to 2013-12-10 and version 2.8 seems to work. 

I don't quite remember why I chose the date based approach, but I think it should be possible to calculate it from a combination of appVersion and appID. If the appID is Thunderbird, use the same algorithm as in lightning's makeversion.py. If its Seamonkey, we need to add 0.3 and transfer the alpha suffix. Or am I missing something?
(Assignee)

Comment 8

4 years ago
It seems Philipp and Stefan have an idea how to solve the problem, therefore unassigning.
Assignee: mschroeder → nobody
Status: ASSIGNED → NEW
OS: Windows 7 → All
Hardware: x86_64 → All
Oh I was hoping you could create the patch :-)
(Assignee)

Comment 10

4 years ago
Talked to Philipp over IRC, and taking over again. ;-)
Assignee: nobody → mschroeder
Status: NEW → ASSIGNED
(Reporter)

Comment 11

4 years ago
(In reply to Philipp Kewisch [:Fallen] from comment #7)
> I just did a quick check, changing the date to 2013-12-10 and version 2.8
> seems to work. 

Do you think you could apply this quick fix? Update are already broken again on comm-aurora because the script already tries to serve Lightning 3.3a2 for Thunderbird 31.0a2 but there are still two weeks until merge day for this versions.
(Assignee)

Comment 12

4 years ago
I can attach my script as soon as I have access to my other computer later this evening.
(Assignee)

Updated

4 years ago
Blocks: 899069
(Assignee)

Comment 13

4 years ago
Created attachment 8409850 [details]
update php script v1

This is the first version of my refactoring/rewrite. It considers the application version when looking for the matching Lightning version and generates correct URLs for l10n builds.
Attachment #8409850 - Flags: review?(philipp)
Comment on attachment 8409850 [details]
update php script v1

The code looks much better, thanks! You say first version, is there anything else you'd like to change before this is pushed?

We probably have to disable comm-beta builds before pushing.
Attachment #8409850 - Flags: review?(philipp) → review+
(Assignee)

Comment 15

4 years ago
Created attachment 8409868 [details]
update php script v1.1

with beta disabled.

Philipp, what is the deploy process for the update script?
Deploy process:
1. Push to my users repo at http://hg.mozilla.org/users/mozilla_kewis.ch/calendar-buildconfig/
2. File a bug like bug 769647.
(Assignee)

Updated

4 years ago
Depends on: 999681
(Assignee)

Comment 17

4 years ago
Please, everyone test the update for nightly and alpha Lightning builds as a new update logic is live now.
(Assignee)

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.