915614 - Firefox 24 ESR nightly builds don't get updates while newer build exists

Status: RESOLVED WORKSFORME

(Release Engineering :: General, defect)

Description

[Cosmin Malutan, [:cosmin-malutan]]

Attachment: pre.xml

http://mozmill-daily.blargon7.com/#/update/report/dc3d4d2f66af31b9e75e291fa0173dd2
http://mozmill-daily.blargon7.com/#/update/report/dc3d4d2f66af31b9e75e291fa017866c

Comment 1

[Cosmin Malutan, [:cosmin-malutan]]

The test failure reproduces locally.
Manually I just get "Nightly it's up to date", but still newer build exists.

Comment 2

[Cosmin Malutan, [:cosmin-malutan]]

Build

https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/09/2013-09-11-00-05-01-mozilla-esr24/
dose not update to 
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/09/2013-09-12-00-05-00-mozilla-esr24/

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This has originally found by our Mozmill tests as reported on bug 915161. Can we please get this fixed?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ups, not sure why the component has been changed.

Comment 5

[u279076]

RelEng, please correct me if I am wrong.

I believe we are not providing updates for the first Firefox 24 ESR (as was the same with 17.0.0esr).

In a nutshell:
 * 17esr will update to 17esr for 12 weeks at which point it will start getting 24esr updates (24.0.2esr I believe)
 * 24esr will not receive an update until 24.0.1esr is released in 6 weeks

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

That mostly true for released builds, except that the versioning is going to be different (24.3esr instead of 24.0.2eser for scheduled releases, use the last .x for chemspills). Whimboo & Cosmin are talking about nightly builds though.

That said, the xml files linked from the reports currently has an update in it.

General Automation is the right component.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

I didn't do very well on the precise values of the versioning, so don't take that as correct. We can discuss that elsewhere if you want, or ask lsblakk about it.

AFAICT, the test ran within a few minutes of the job finishing, but the update server didn't return the update. It would be really awesome if MozMill could capture the xml that was returned. I can't find anything on the update server which would explain why the update wasn't served so my only option is to WFM this.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Nick, the problem here is a different one. It looks like that for Sep 11th the final release has been put into the nightly folder:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-11-00-05-01-mozilla-esr24/

Compare it with the lastest mozilla-24esrpre build from yesterday:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-12-00-05-00-mozilla-esr24/

Not sure what went wrong, but please check that this doesn't happen again.


Btw. our Mozmill tests will start passing again once we get a new esr24 nightly.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As Nick mentioned over on bug 915161 the following changeset should have been fixed that:
http://hg.mozilla.org/releases/mozilla-esr24/rev/8766c4204836

If that's the case we can close this bug as fixed. Thanks.

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

If you check carefully we had two '24.0' nightlies:
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-10-00-06-22-mozilla-esr24/
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-11-00-05-01-mozilla-esr24/

The actual 24.0esr build started about 10am PT on the 11th, landing this http://hg.mozilla.org/releases/mozilla-esr24/rev/78a7b4a14be6 in the process.

Subsequent nightlies have '24.0esrpre' for the version:
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-12-00-05-00-mozilla-esr24/
 http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-15-00-05-01-mozilla-esr24/

The versioning might be something else that needs to get changed when the code is copied over from mozilla-beta (CC lsblakk, added to https://etherpad.mozilla.org/firefox24esr-worry-list).


I don't know why you've brought bug 915161 up here. The two reports in comment #0 are on linux, so the channel-id issue in bug 915161 is not connected (only the windows maintenance service is checking the id on the mar file, this will change in future).