Closed Bug 730618 Opened 13 years ago Closed 13 years ago

Firefox l10n repack nightlies busted in libmar in mar_sign.o

Categories

(Firefox Build System :: General, defect)

11 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Pike, Assigned: bhearsum)

References

Details

(Whiteboard: [fixed by bug 730862])

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-l10n-sk/1330182090.1330182206.17960.gz&fulltext=1 is one of the logs. I bet it's some of the various libmar bugs that landed in the past 24 hours, no idea which. Brian, Rob?
Blocks: 699700
Testing using the steps from Bug 481815 Comment 388 now.
I guess the culprit is more likely that we're building nspr and then libmar, and there's something missing. The builds do configure make tier_nspr make -C modules/libmar
I was able to build a french installer without a problem using the steps in the link above. From the logs it looks like security/nss was not built which is used by signmar. In particular it can't find the header files of NSS which should be in the objdir's dist/include. How exactly can I build in the same way as per that build? Is it a m-c build with specific options? Or something else? I don't think it is a full build which is what I was testing from.
(In reply to Brian R. Bondy [:bbondy] from comment #3) > How exactly can I build in the same way as per that build? Is it a m-c build > with specific options? Or something else? I don't think it is a full build > which is what I was testing from. Ask the localization team. I think they have a special configuration of mozilla-central (pre-built?) that probably does not include NSS. I do not know how it works either.
Using the tinderbox link in comment #0 you can search for BuildStep started for all the 'steps' buildbot does to create a l10n repack. The one called autoconf is the first 'compile' step after the setup for the machine, utils, and getting the source. To summarise though, it's a trimmed down set of build steps, where an objdir isn't used. The sequence (on mac) is autoconf in topsrcdir autoconf in topsrcdir/js/src configure --enable-application=browser --with-l10n-base=../l10n-central --with-macbundlename-prefix=Firefox --enable-update-packaging --enable-update-packaging make config [a bunch of steps getting the en-US build, unpacking, merging l10n strings using compare_locales] make tier_nspr make libmar (fails)
I tried to find it, but failed. What's building security/nss in the regular builds?
make -C security/manager builds security/nss as well as security/manager/*
Is there a makefile target that's more specific to what we need?
I don't think so.
OK, this is pretty heavy payload. tier_base, tier_nspr, tier_js, export_tier_platform, xpcom, security/manager ... and I still fail in xpcom so far. Can we back bug 699700 out until we have an idea how to do this for l10n builds? Not having nightlies at all isn't cool, and I don't see low-hanging fruit to get them back. Not-so-low hanging might be to create a package of just what's needed for update generation from the en-US build, and make our build infrastructure use that, and then land the crypto stuff again.
> Can we back bug 699700 out until we have an idea how to do this for l10n builds? > Not having nightlies at all isn't cool, and I don't see low-hanging fruit to get > them back. I'd prefer to try to find a way to fix this hopefully today. We'd have to backout all of my 15 patches here: http://hg.mozilla.org/mozilla-central/shortlog/2b1a53905350 And I haven't tested going from signed builds -> not signed builds -> signed builds so there could be some surprises.
:s/could/would
CC'ing bhearsum and catlee to make sure these repackaged MARs get re-signed.
I'm not exactly sure where the fix for this is going to be, but Brian and I are looking into it.
Assignee: nobody → bhearsum
Thanks for the steps in Comment 5. If we want to adjust these steps what file in what repo would we change?
(In reply to Brian R. Bondy [:bbondy] from comment #15) > Thanks for the steps in Comment 5. > If we want to adjust these steps what file in what repo would we change? Right now, it's a Buildbot config change. I'm looking to test this out by hand before I go about that, though.
bhearsum realized we don't need signmar for these repacks so I'm making a patch with a specific define that will exclude this functionality that we can just make sure is defined. bhearsum will do the patch to make sure it is defined only in the case of repacks.
Depends on: 730862
The part of the work that I can do was done in Bug 730862 - Provide the ability to disable signmar when building modules/libmar
(In reply to Axel Hecht [:Pike] from comment #10) > OK, this is pretty heavy payload. tier_base, tier_nspr, tier_js, > export_tier_platform, xpcom, security/manager > > ... and I still fail in xpcom so far. Only NSPR is a prerequisite for NSS. We should add a new makefile target that builds NSS without building PSM. Kai, do you have any suggestions for doing so?
It seems we don't need signmar for this and hence don't need NSS. We just have to make sure NO_SIGN_VERIFY is defined.
I don't think I'll have time to fix this today. It's #1 on my list for tomorrow though.
The dependent patch (Bug 730862) was pushed to m-c so I think the problem should be fixed now. If you notice it is working now please mark this bug as Resolved | WFM. If it doesn't work let me know and I'll look into what else is wrong.
On the channel ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/ there are still no new builds, only a large number of text files reporting errors for the various language builds.
Some of them are still running, but even the ones that are finished don't have updates available still....for example Linux 64-bit hy-AM. I think this is the type of problem that fixes itself the next day, but I'm looking into it still.
Indeed, I just manually triggered an additional Linux 64-bit hy-AM nightly and it is now getting an update to the latest version: https://aus3.mozilla.org/update/1/Firefox/13.0a1/2011032403/Linux_x86_64-gcc3/hy-AM/nightly/update.xml?force=1 The rest of the platforms/locales will fix themselves up tomorrow morning with the regularly scheduled ones.
Marking this as resolved, but please re-open if it is broken after tomorrow morning.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Depends on: 732075
Alexander, I posted about your report here: bug 732075
Resolution: WORKSFORME → FIXED
Whiteboard: [fixed by bug 730862]
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.