After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 154213 - mozilla does not install nss headers correctly causing evo build failures
mozilla does not install nss headers correctly causing evo build failures
Product: jhbuild
Classification: Infrastructure
Component: general
Other Linux
: Normal normal
: ---
Assigned To: James Henstridge
Jhbuild QA
: 168315 (view as bug list)
Depends on:
Reported: 2004-10-01 02:26 UTC by Luis Villa
Modified: 2005-06-13 18:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch against (1.66 KB, patch)
2004-10-01 02:27 UTC, Luis Villa
none Details | Review
updated nss install patch (1.63 KB, patch)
2005-06-12 17:57 UTC, Luis Villa
none Details | Review

Description Luis Villa 2004-10-01 02:26:09 UTC
You can't build evo out of jhbuild against a jhbuilt mozilla because the
mozilla/nss build does not install the mozilla headers correctly, so evolution
will attempt to build with ssl support and fail during the build.

The attached patch is pretty gross, but seems to DTRT thing on my tinderbox. It
basically just overrides the stock do_install with one that (if the build is
successful) makes an /nss/ dir in $PREFIX/includes/ and then copies a mess of
headers into there. Otherwise, it is identical to the stock do_install.
Comment 1 Luis Villa 2004-10-01 02:27:01 UTC
Created attachment 32135 [details] [review]
patch against
Comment 2 James Henstridge 2004-10-01 03:19:35 UTC
I made a few changes to the handling of makeargs (simplifying things a bit), so
that part of the patch will need a small change.

Also, it looks like errors are being ignored for the extra two execute() statements.
Comment 3 Luis Villa 2004-10-01 11:53:45 UTC
Yup. I can look at those problems tomorrow morning. [Though, realistically, as
long as find is installed, everything else should succeed; it's very hard to
think of a scenario where the rest of the build would succeed and this would fail.]
Comment 4 Murray Cumming 2004-10-07 14:44:00 UTC
Isnt't there a mozilla bug for this?
Comment 5 Luis Villa 2005-01-11 12:25:50 UTC
So, I really don't have time to fix up the patch right now, but given that we
just made mozilla a build pre-req for the panel, the priority of this keeps
going up :/ Given that the only likely failures are if 'find' is not installed,
can we go ahead and commit?
Comment 6 James Henstridge 2005-02-25 09:50:48 UTC
*** Bug 168315 has been marked as a duplicate of this bug. ***
Comment 7 Tim Cooijmans 2005-03-13 19:08:15 UTC
I had the same problem, and worked around it with the following command:
cp -RL ~/cvs/gnome2/mozilla/dist/public/nss /opt/gnome2/include/mozilla-1.6.7/
Replace ~/cvs/gnome2 and /opt/gnome2 with your GNOME CVS directory and your
GNOME target directory, respectively.

Patching mozilla and rebuilding that before rebuilding evolution sounded rather
dirty to me, and if I understood correctly, the patch does about the same thing.
Comment 8 Luis Villa 2005-06-09 20:45:18 UTC
So, interestingly this fails with the *full* patch from bug 164564, which when
applied builds firefox. Despite firefox being built,
self.get_mozilla_ver(buildscript)) returns 1.8b2 so I then mkdir
$PREFIX/include/mozilla-1.8b2/, when I should be using something like
$PREFIX/include/firefox-1.0+/ Is there any way I can programatically know
'firefox-1.0+' is the right place to install this stuff?

[Interestingly, it looks like --mozilla-five-home is $PREFIX/lib/mozilla-1.8b2/,
which is also incorrect.]
Comment 9 Christian Persch 2005-06-09 21:23:11 UTC
The right include dir is $prefix/lib/$MOZ_APP_NAME-$MOZ_APP_VERSION . App name
is mozilla/firefox; and `cat $topsrcdir/browser/config/version.txt` will get you
the  version.
Comment 10 Luis Villa 2005-06-09 21:52:10 UTC
The thing is that I assumed I'd be able to programatically access $MOZ_APP_NAME
and $MOZ_APP_VERSION from within the jhbuild mozillamodule. Marco, as far as I
can tell, I can't, but maybe I'm not looking at the right place? If not, where
would be the right place to add those?
Comment 11 Marco Pesenti Gritti 2005-06-10 08:10:00 UTC
>    def get_mozilla_ver(self, buildscript):
>        filename = os.path.join(self.get_builddir(buildscript),
>                                'config', 'milestone.txt')

From chpe comment I guess you need to change this to 'browser/config' and
'version.txt', I dont have a mozilla tree to check though.

>        if buildscript.config.use_lib64:
>            mozilla_path = '%s/lib64/mozilla-%s' \
>                           % (buildscript.config.prefix,
>                              self.get_mozilla_ver(buildscript))
>        else:
>            mozilla_path = '%s/lib/mozilla-%s' \
>                           % (buildscript.config.prefix,
>                              self.get_mozilla_ver(buildscript))

Ideally we would guess the "mozilla-" part of the path from self.projects, which
is not trivial because it's a list of projects. It could be, for example,
"browser,suite" I guess.

For now I guess we could just do something like:

if self.projects == "browser":
  mozilla_app_name = "firefox"
  mozilla_app_name = "mozilla"

and then

mozilla_path = '%s/lib/%s-%s' \
                 % (buildscript.config.prefix,

If you have problems to get this going let me know and I'll try to get a mozilla
tree going...
Comment 12 Christian Persch 2005-06-10 11:44:41 UTC
The $topsrcdir/browser/config/version.txt file is only used on product=browser
btw. So 'mozilla' still needs to use the old way to get the version.

Does someone know the upstream ( bug for this?
Comment 13 Marco Pesenti Gritti 2005-06-10 11:50:34 UTC
Grrr you will have to do the self.projects check in get_mozilla_ver too then.
Comment 14 Marco Pesenti Gritti 2005-06-10 12:12:19 UTC
Bah, I'll fix these issues... give me one day or so.
Comment 15 Marco Pesenti Gritti 2005-06-12 09:11:22 UTC
Luis issue should be fixed in cvs
Comment 16 Luis Villa 2005-06-12 17:56:39 UTC
So, I've updated my patch to use get_mozilla_app(), but at least here,
browser/config/version.txt does not end in a newline, so 
  return line[:-1]
in the new code chops the +, which is broken. doing:
- return line[:-1]
+ return line.strip()

seems to solve the problem (returning 1.0+ and not 1.0), while remaining safe if
a newline is added later. OK to commit that?

Also, will attach updated patch to fix the NSS install. James, people are still
running into this problem all over, and I can't see any way (with the fixed
patch) that mozilla's build can succeed while the nss install step fails. Can I
please commit it?
Comment 17 Luis Villa 2005-06-12 17:57:53 UTC
Created attachment 47659 [details] [review]
updated nss install patch

I'm actually still in the process of testing this patch, but it should work;
I'll update the bug when I've finished testing, and beg for commit privs ;)
Comment 18 Luis Villa 2005-06-12 18:35:04 UTC
Well, dammit; the patch seems to install everything correctly, but
evolution-data-server still isn't picking it up correctly for some reason (and
that is the main user for this), so I'm not yet ready to commit this. fuck and damn.
Comment 19 Luis Villa 2005-06-12 21:06:20 UTC
Actually, this is probably e-d-s's fault, see bug 307418. Given that AFAICT the
patch itself is correct (and certainly no worse than the current situation,
which is guaranteed to fail) may I commit?
Comment 20 James Henstridge 2005-06-13 01:51:45 UTC
Luis: you may as well commit if you are confident that it is working correctly.
Comment 21 Luis Villa 2005-06-13 18:56:27 UTC
I've tested a bit more and am now fairly confident that this (at least) fixes
the mozilla case, and I'm fairly sure the firefox case is correct (though I
can't be 100% sure until bug 307418 is fixed.) So I've gone ahead and commited.
I'll brace for the pain if I fucked it up :)