GNOME Bugzilla – Bug 154213
mozilla does not install nss headers correctly causing evo build failures
Last modified: 2005-06-13 18:56:27 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.
Created attachment 32135 [details] [review] patch against mozillamodule.py
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.
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.]
Isnt't there a mozilla bug for this?
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?
*** Bug 168315 has been marked as a duplicate of this bug. ***
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.
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.]
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.
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?
> 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" else: mozilla_app_name = "mozilla" and then mozilla_path = '%s/lib/%s-%s' \ % (buildscript.config.prefix, mozilla_app_name, self.get_mozilla_ver(buildscript)) If you have problems to get this going let me know and I'll try to get a mozilla tree going...
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 (bugzilla.mozilla.org) bug for this?
Grrr you will have to do the self.projects check in get_mozilla_ver too then.
Bah, I'll fix these issues... give me one day or so.
Luis issue should be fixed in cvs
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?
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 ;)
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.
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?
Luis: you may as well commit if you are confident that it is working correctly.
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 :)