313506 - incremental updates missing since 20051020

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Peter van der Woude [:Peter6]]

the last .mar on windows was on 20051020

Comment 1

[Chase Phillips]

Trunk or branch?

I see the last MAR on Windows is 2005102106.  From the 1.8 branch build log:

ignoring remove instruction for directory: defaults/profile/US/
ignoring remove instruction for directory: extensions/{641d8d09-7dda-4850-8228-ac0ab65e2ac9}/
ignoring remove instruction for directory: searchplugins/
ERROR: file not found: update.manifest
mv: cannot stat `/cygdrive/c/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dist/firefox.work/output.mar': No such file or directory

I'll investigate.

Comment 2

[Peter van der Woude [:Peter6]]

(In reply to comment #1)
> Trunk or branch?
both

Comment 3

[Chase Phillips]

Two things:

1. Fix complete packaging on build systems to workaround this issue.
2. Fix build scripts to trigger a build-failed if the complete packaging fails.

Thanks for the heads up, Peter.

Comment 4

[Chase Phillips]

(In reply to comment #3)
> 2. Fix build scripts to trigger a build-failed if the complete packaging fails.

Second thing's first.  This has been implemented to trigger a failed packaging signal.  Respin shortly to verify.

Comment 5

[Chase Phillips]

(In reply to comment #4)
> (In reply to comment #3)
> > 2. Fix build scripts to trigger a build-failed if the complete packaging fails.
> 
> Second thing's first.  This has been implemented to trigger a failed packaging
> signal.  Respin shortly to verify.

This change is now verified.  On to fixing the principal issue.

Comment 6

[Bill Gianopoulos [:WG9s]]

I'm not sure that change is sufficient.  I think if there is a packaging error on the the release nightly build then the next build should be another attempt to make the nightly, otherwise this will still just look like one orange cycle and the next cycle is green so it still might not get action as quickly as it should.

Comment 7

[Chase Phillips]

Short summary: A fix is in-place.  Respin running on pacifica to verify.

Bug background + summary:

When working on MAR complete patches for l10n files 1-2 weeks ago, I modified the build scripts to send DIST to the make instance in tools/update-packaging.  This allowed those MARs to be made on all three platforms even with a non-uniform dist directory (dist/l10n-stage/{firefox,thunderbird}).  The last l10n system to get those MARs built was cerberus, the l10n Windows build system.  (We scrambled to get cerberus in chroma's place after chroma went on Indefinite Leave aka that Big Server Room in the Sky, but I digress.)

cerberus was failing to build its MAR files because the mar executable as-compiled-on-Windows cannot handle paths that are Unix-like (prepended by /cygdrive/c/ instead of c:/) such as those generated by our build scripts.  In previous versions of this patch packaging I was not overriding DIST in tools/update-packaging/Makefile.in and so the build would take the natural OS value (that's why it still works on patrocles -- patrocles is using that older version of these patch packaging scripts).

I fixed this on cerberus by uncommenting some cygpath goodness in post-mozilla-rel.pl.  I didn't check those changes in anticipating verifying they didn't break parts of the build.  (Questions came to mind that I didn't have time to fully investigate like "why was this code commented out in the first place?" and "What random thing may break if I update other systems to use this code?")

Sometime in the past couple of days, post-mozilla-rel.pl was updated on pacifica.  That update pulled in the patch packaging DIST changes but, of course, nothing was changed to use the appropriate path on Windows for the mar executable to function, hence the breakage.

I've now fixed the path issue on the Windows platform.  A respin is already running to verify the fix on pacifica.

The build scripts have been modified to not send a success signal if we fail to create the MAR and we mean to do so.  In those cases the build will fail with the standard "packaging failed" error.  The MAR creation process also now fails sooner if the MAR doesn't exist immediately after the creation command completes.  With these changes future errors in the complete MAR packaging will be more easily caught.

Comment 8

[Chase Phillips]

(In reply to comment #6)
> I'm not sure that change is sufficient.

What's that based on?

> I think if there is a packaging error
> on the the release nightly build then the next build should be another attempt
> to make the nightly,

It already does.  Packaging failed does not signal that the release build completed.  It stops the build process and sends the error message.  The start of every build cycle on the release trees check if a release build is needed.  The next build cycle, seeing a release build needs to be performed, will attempt another one.

Comment 9

[Bill Gianopoulos [:WG9s]]

OK great!  What I was basing htsi on is that in the past, on at least one occaision, when the installer build failed, that jsut made the nightly build be orange and not create an installer build and then did not try to produce a nightly ont he next build so it went green.  If that is no longer the case then I guess this should do the trick.

Comment 10

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

As a followup to this, could the win32 2005102322 build be removed from the update system ? It has the broken accelerators (UNDEFINED everywhere, bug 313565), and update doesn't function (offers version null on startup, Help > Check for updates fails partial and complete on integrity). The 2005102400 build updated without any problems to 2005102404.

Comment 11

[Chase Phillips]

(In reply to comment #10)
> As a followup to this, could the win32 2005102322 build be removed from the
> update system ? It has the broken accelerators (UNDEFINED everywhere, bug
> 313565), and update doesn't function (offers version null on startup, Help >
> Check for updates fails partial and complete on integrity).

Done.

> The 2005102400
> build updated without any problems to 2005102404.

After you updated from 2005102400 to 2005102404 is there still update data in updates/0?  If so, could you add a confirmation to bug 313623?  Thanks.