bug 458014 made some significant changes to l10n repack code. During 3.1b2 I discovered that this has completely broken MAR generation for l10n builds. We generate MARs as follows: make -C tools/update-packaging full-update DIST=`pwd`/dist/l10n-stage AB_CD=whatever MOZ_PKG_PRETTYNAMES=1 This will still generate a valid MAR but it will be missing a bunch of files, as our update_verify test found out: calling QuitProgressUI Only in target/Firefox/chrome: be.jar Only in target/Firefox/chrome: be.manifest Only in target/Firefox/defaults/pref: firefox-l10n.js Only in target/Firefox/defaults/profile: bookmarks.html Only in target/Firefox/defaults/profile/chrome: userChrome-example.css Only in target/Firefox/defaults/profile/chrome: userContent-example.css Only in target/Firefox/defaults/profile: localstore.rdf Only in target/Firefox/defaults/profile: mimeTypes.rdf diff -r source/firefox/removed-files target/Firefox/removed-files 521a522 > modules/JSON.jsm Only in target/Firefox/searchplugins: be.wikipedia.org.xml Only in target/Firefox/searchplugins: be-x-old.wikipedia.org.xml Only in target/Firefox/searchplugins: google.xml Only in target/Firefox/searchplugins: ru.wikipedia.org-be.xml Only in target/Firefox/searchplugins: tut.by.xml Only in target/Firefox/searchplugins: yahoo.xml Only in target/Firefox/searchplugins: yandex.ru-be.xml This is blocking Firefox 3.1b2.

bhearsum says Axel's working on a fix.

Tested this with: unbranded nightly build branded official 3.1 b2 build 1 en-US bits on OS/X. The good news is, once I had the initial paths worked out, it worked out of the box for the official builds, too. I removed the comment about the mars needing the repackage-zip target, as I apparently broke that. Sorry for that. But I think that having the mars being part of this makefiles is a good thing, even if the timing is bad as can be.

Comment on attachment 350231 [details] [diff] [review] call into mar for MOZ_MAKE_MARS, set the appropriate paths Testing this out now. I don't know that passing PACKAGE_BASE_DIR will do anything - tools/update-packaging/Makefile.in doesn't seem to look for it being passed - it just sets it based on a few rules. You and ted both know Makefiles better than me though, so we should probably get his review, too.

Variables passed via the commandline overrule those set in the Makefile. See http://www.gnu.org/software/make/manual/make.html#Overriding and siblings.

Comment on attachment 350231 [details] [diff] [review] call into mar for MOZ_MAKE_MARS, set the appropriate paths This patch worked great for me. My only nit is that MOZ_MAKE_MARS should be MOZ_MAKE_MAR or MOZ_MAKE_COMPLETE_MAR -- since that's what full-update does.

New patch with MOZ_MAKE_COMPLETE_MAR for the relbranch. Gonna land this on trunk once Ted has reviewed this, too.

Comment on attachment 350329 [details] [diff] [review] updated patch for MOZ_MAKE_COMPLETE_MAR Landed on the release branch: changeset: 21996:ad29715677b4

Comment on attachment 350329 [details] [diff] [review] updated patch for MOZ_MAKE_COMPLETE_MAR >diff --git a/browser/locales/Makefile.in b/browser/locales/Makefile.in >+ STAGEDIST="$(_ABS_DIST)/install" \ I don't see that variable being used in the update-packaging Makefile at all, I think this is unused and should be removed.

Ah, yeah. You're right. That Makefile uses STAGE_DIR -- but we don't need to pass it. It only controls the output location of the MAR and IMHO dist/$(PKG_UPDATE_PATH) is preferable to dist/install/$(PKG_UPDATE_PATH)

Updated patch that I landed, http://hg.mozilla.org/mozilla-central/rev/dfbbf5cf98c2. Requesting approval 1.9.1

Requesting blocking, too. We'll need this patch to actually create mars for releases. For 3.1 Beta 2, we had a similar patch on the relbranch, http://hg.mozilla.org/mozilla-central/rev/ad29715677b4.

Comment on attachment 351873 [details] [diff] [review] updated patch without STAGEDIST [checked-in] a191 and blocking+=beltzner

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4fce7f31b7e5, fixed1.9.1 and FIXED.