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)
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?
Comment 1•13 years ago
|
||
Testing using the steps from Bug 481815 Comment 388 now.
Reporter | ||
Comment 2•13 years ago
|
||
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
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
(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.
Comment 5•13 years ago
|
||
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)
Reporter | ||
Comment 6•13 years ago
|
||
I tried to find it, but failed. What's building security/nss in the regular builds?
Comment 7•13 years ago
|
||
make -C security/manager builds security/nss as well as security/manager/*
Reporter | ||
Comment 8•13 years ago
|
||
Is there a makefile target that's more specific to what we need?
Comment 9•13 years ago
|
||
I don't think so.
Reporter | ||
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
> 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.
Comment 12•13 years ago
|
||
:s/could/would
Comment 13•13 years ago
|
||
CC'ing bhearsum and catlee to make sure these repackaged MARs get re-signed.
Assignee | ||
Comment 14•13 years ago
|
||
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
Comment 15•13 years ago
|
||
Thanks for the steps in Comment 5.
If we want to adjust these steps what file in what repo would we change?
Assignee | ||
Comment 16•13 years ago
|
||
(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.
Comment 17•13 years ago
|
||
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.
Comment 19•13 years ago
|
||
The part of the work that I can do was done in Bug 730862 - Provide the ability to disable signmar when building modules/libmar
Comment 20•13 years ago
|
||
(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?
Comment 21•13 years ago
|
||
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.
Assignee | ||
Comment 22•13 years ago
|
||
I don't think I'll have time to fix this today. It's #1 on my list for tomorrow though.
Assignee | ||
Comment 23•13 years ago
|
||
The latest patch from bug 730862 (https://bugzilla.mozilla.org/attachment.cgi?id=601035&action=edit) seems to fix this.
Comment 24•13 years ago
|
||
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.
Comment 25•13 years ago
|
||
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.
Assignee | ||
Comment 26•13 years ago
|
||
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.
Assignee | ||
Comment 28•13 years ago
|
||
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.
Comment 29•13 years ago
|
||
Marking this as resolved, but please re-open if it is broken after tomorrow morning.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Comment 30•13 years ago
|
||
FWIW, I still can not auto-update my Linux x86 build. https://aus3.mozilla.org/update/3/Firefox/13.0a1/20120224031039/Linux_x86-gcc3/ru/nightly/Linux%203.0.0-16-generic%20%28GTK%202.24.6%29/default/default/update.xml?force=1 doesn't contain link to update.
Comment 31•13 years ago
|
||
Alexander, I posted about your report here: bug 732075
Updated•7 years ago
|
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.
Description
•