Closed Bug 1315530 Opened 8 years ago Closed 8 years ago

Today's(2016-11-06) Aurora51.0a2 updater is 70.1MB ! and would not launch.

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86
Windows 10
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(firefox49 unaffected, firefox-esr45 unaffected, firefox50 unaffected, firefox51 fixed, firefox52 unaffected)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox49 --- unaffected
firefox-esr45 --- unaffected
firefox50 --- unaffected
firefox51 --- fixed
firefox52 --- unaffected

People

(Reporter: alice0775, Unassigned)

References

(Blocks 1 open bug)

Details

[Tracking Requested - why for this release]:

STR
1. Update from 2016-11-05

Actual Results
70.1MB updater
Aurora51.0A2 would not launch
Summary: Today's Aurora51.0a2 updater is 70.1MB ! and would not launch. → Today's(2016-11-06) Aurora51.0a2 updater is 70.1MB ! and would not launch.
The updates are pointing to Firefox-mozilla-aurora-nightly-20161105004017 now.
confirmed.
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51: affected → fixed
tracking-firefox51: ? → ---
Resolution: --- → FIXED
I'll keep the bug open to make sure we enable updates, when the root clause is resolved.

Something tells me that rebuilding would help. Clock change something something UTC something something.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
we're getting feedback on support channels that the newest devedition version is failing to launch with a windows "pgort140.dll is missing" or "Couldn't load XPCOM" error. not sure if that is related to this bug as well...
Reverted the updates and pointed them to Firefox-mozilla-aurora-nightly-latest
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
What was the cause of the increase?
Having the build pend from 00:40 to 01:15, then run from 01:15 to 01:59:59 to 01:00:00 to 03:06. We moved the start time to 00:40 back in 2013 when having the l10n nightlies start running at 08:00 would consume the entire build pool and make us close integration branches every morning. Now that they are only six chunks, we could probably move the start time back to the DST-change-safe 04:20 where they were before, since only the OS X build pool is constrained.
I filed bug 1315695 to investigate if there are any build system issues worth fixing. The real fix (for us) is to have all systems use UTC.
Blocks: 1326460
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.