This is the initial version to build Firefox with complete headers In future Firefox is going to replace mozilla as backend and there we go. As always. highly experimental.
Created attachment 53991 [details] firefix 1.0.1-r1
Created attachment 53992 [details] 10MozillaFirefox Along the right environment set to make firefox the default header-provider.
Comment on attachment 53991 [details] firefix 1.0.1-r1 wrong prefix due to econf
Created attachment 54000 [details] Firefox 1.0.1 fixed ebuild Fixed
Created attachment 54006 [details] Firefox 1.0.1-r2 Symlink fix
Created attachment 54331 [details] mozilla-firefox-1.0.2-r1.ebuild with headers Updated ebuild for Firefox 1.0.2.
Excellent.
I just compiled against firefox 1.0.2-r1 the mozilla plugin included in totem 1.0.1 (not yet in portage) and it worked, but I had to change '/usr' in '/usr/lib/MozillaFirefox' and '/usr/include' in '/usr/lib/MozillaFirefox/include' in every .pc file installed in /usr/lib/pkgconfig and to create a symlink mozilla-plugin.pc pointing to firefox-plugin.pc
Yes, the portage-people have kipped once more and due to modifying my ebuild the pkgconfig is broken! econf implies "prefix=/usr", while configure implies only the given moz-parameters (i.e. /usr/lib/MozillaFirefox), which will lead to an unusable pkgconfig. The "old" and original firefox never used a prefix and was dumped into /usr by copying the files. This is rather a hack than a correct solution. econf should therefor not be used and configure instead of it. Also the environment set is still not up to date (File under Environment-set). Hence the currently merged firefox-ebuild is completely useless and will give the user 17MB of garbage. Those who desire a "working" ebuild should use the attached ebuild instead of the portage-provided.
I've successfully built Galeon 1.3.20 against the current version of mozilla-firefix-1.0.2-r1.ebuild in the tree (CVS revision 1.4). However, a few patches are needed to make typeahead find work and to fix a few crasher bugs: http://live.gnome.org/Epiphany/MozillaPatches I can attach these patches and an updated ebuild if desired.
It seems ok to apply these, (only the needed one of course) and to check if that wiki page is up to date (maybe patches have been applied to 1.0.2)
This patch is not quite small and the firefox should still be deployable _without_ any conflicts regarding its purpose which is serving as a browser and being a base for epiphany. Galeon is quite old now and nothing should be done in making modern applications brake, in order to get an old application running. Make sure you test both epiphany and galeon when applying patches. I would even wait for further feedback as I cannot image there are more people using Galeon than Epiphany as Epiphany popularity is also a vanishing number.
I've attached the necessary patches to hanno's bug 86872.
Looks like we're good to go wrt to the headers Brad. Nice work!
Brad, aren't you going to fix the econf-bug? The current state leaves Firefox' pkgconfig-registration in an unusable state. configure should be used uness econf provides are more useful way to handle the prefix. The mozilla-suite has always been built with configure instead of econf, and this has surely be done on purpose. Some "modern" ways are nice... if they work...
Created attachment 56359 [details] mozilla-firefox-1.0.2-r3 with nss/nspr I decided to include nss/nspr installation with the current firefox-ebuild, so applications like evolution and evolution-data-server can be linked against its included headers without installing the additional nss and nspr headers. The evolution and evolution-data-server ebuilds will be included in a separate bug report
WARNING: DON'T build this firefox with revision r3 as it does not include mozilla's lambda-flaw (see also https://bugzilla.mozilla.org/show_bug.cgi?id=288688). You should get this ebuild and the diff from http://bugs.gentoo.org/show_bug.cgi?id=88039 and bump the version to r4. This way you make sure, you have both a complete firefox-suite and the security issue fixed.
Created attachment 56451 [details] mozilla-firefox-1.0.3.ebuild Implies fix for lambda-fix, so it's not needed anymore. Firefox 1.0.3 replaces everything.
Your 1.0.3 ebuild failed... ======= making ./libldap50.so i686-pc-linux-gnu-ld -shared -Wl,-soname -Wl,libldap50.so -o libldap50.so ./a bandon.o ./add.o ./bind.o ./cache.o ./charray.o ./charset.o ./compare.o ./compat .o ./control.o ./countvalues.o ./delete.o ./disptmpl.o ./dsparse.o ./error.o ./e xtendop.o ./free.o ./freevalues.o ./friendly.o ./getattr.o ./getdn.o ./getdxbyna me.o ./getentry.o ./getfilter.o ./getoption.o ./getvalues.o ./memcache.o ./messa ge.o ./modify.o ./open.o ./os-ip.o ./proxyauthctrl.o ./psearch.o ./referral.o ./ regex.o ./rename.o ./request.o ./reslist.o ./result.o ./saslbind.o ./sbind.o ./s earch.o ./setoption.o ./sort.o ./sortctrl.o ./srchpref.o ./tmplout.o ./ufn.o ./u nbind.o ./unescape.o ./url.o ./utf8.o ./vlistctrl.o -L/var/tmp/portage/mozilla- firefox-1.0.3/work/mozilla/dist/lib -llber50 i686-pc-linux-gnu-ld: unrecognized option '-Wl,-soname' i686-pc-linux-gnu-ld: use the --help option for usage information gmake[5]: *** [libldap50.so] Error 1 gmake[5]: *** Waiting for unfinished jobs.... gmake[5]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.3/work/mozilla /directory/c-sdk/ldap/libraries/libldap' gmake[4]: *** [export] Error 2 gmake[4]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.3/work/mozilla /directory/c-sdk/ldap/libraries' gmake[3]: *** [export] Error 2 gmake[3]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.3/work/mozilla /directory/c-sdk/ldap' gmake[2]: *** [export] Error 2 gmake[2]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.3/work/mozilla /directory/c-sdk' gmake[1]: *** [ldap] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/mozilla-firefox-1.0.3/work/mozilla ' make: *** [default] Error 2 Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11-gentoo-r5 i686) ================================================================= System uname: 2.6.11-gentoo-r5 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 18 2005, 18:33:16)] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.9.5, 1.5, 1.4_p6, 1.8.5-r3, 1.6.3, 1.7.9-r1 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -msse -mmmx -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -msse -mmmx -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl dvd dvdread emboss encode esd fam flac foomaticdb fortran freetds gd gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml imagemagick imlib jpeg kde ldap libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nptlonly odbc ogg oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline samba sdl slang speex spell sqlite sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Created attachment 56460 [details] mozilla-ldap.diff Seems like ldap-support is still broken, so apply the diff to not compile ldap support. It is an issue with the linker, which is called with wrong parameters. I had no time and motivation to fix it, as it's a mozilla-bug anyway... So, apply the ldap-diff above or compile with USE="-ldap"
Okay - using "-ldap" works... - firefox 1.0.3 emerges fine - plz submit it to the portage tree (think ~x86 would best for a wider testing audience) - and don't forget to add the ldap patch... - thx for your great work!
I will do so as I'm interested in LDAP-support myself. So all I can say is: "Stay tuned". :-)
Thanks, guys. Epiphany and epiphany-extensioncan be built against this version of firefox now. To get eipihany to compile successfully, I had to symlink these headers from their respective subdirs into /usr/include/MozillaFirefox: nsIPrefBranch.h nsIPrefService.h nsIURI.h nsIWebBrowserFind.h nsIWebBrowser.h I also had to link these to get epiphany-extensions to build: domstubs.h nsIDOMDocument.h nsIDOMDocumentStyle.h nsIDOMElement.h nsIDOMHTMLElement.h nsIDOMHTMLLinkElement.h nsIDOMMediaList.h nsIDOMNode.h nsIDOMStyleSheet.h nsIDOMStyleSheetList.h nsIDOMWindow.h Symlinking files all over the place is not a great solution, it would be cleaner to add /usr/include/MozillaFirefox/(dom/ pref/ webbrwsr/) to the appropriate .pc file, but I wasn't sure which one to change. Hopefully someone with more knowledge of firefox and pkg-config can sort this out, so we can build epiphany againse firefox automagically.
Next time, check your the bugreports and you'll find : http://bugs.gentoo.org/show_bug.cgi?id=88649
concerning the ldap build problem I found the same bugs for mozilla-1.7.5 and 1.7.6 http://bugs.gentoo.org/show_bug.cgi?id=86786. The workaround/solution was introduced in the respective -r1 ebuilds (see also the links for the diffs in the bug). When I introduce the changes in your famous firefox ebuild ldap compiles fine and libldap50.so libprldap50.so are installed in /usr/lib/MozillaFirefox. BTW in the official gecko-sdk-1.7.5.ebuild the same solution was used.
Created attachment 57327 [details, diff] patch to compile firefox with USE='ldap' the patch for your great ebuild, give it a try
Created attachment 58861 [details] mozilla-firefox-1.0.4-r1 1.0.4-r1 release notes: LDAP-Fix: The ebuild now contains the ability to compile firefox with USE="ldap" PKG-Fix: After the pkgconfig-modification has finally been fixed we can use econf And as always, this ebuild copies nss/nspr headers, so we can use firefox' ssl instead of emerging the nss-package.
Created attachment 63380 [details] Mozilla Firefox 1.0.5-r1 ebuild Updated to 1.0.5-r1 featuring the complete ssl-package (tools and libs) as well as ldap support. #### The current env.d's mozilla-config should be updated to reflect the new MOZILLA5HOME in order to get several application's features working, like RSSOWL, which used the mozilla-engine for internal browsing. ####
please use diffs when modifing ebuilds makes my job and most other devs job alot easier.
(In reply to comment #29) > please use diffs when modifing ebuilds makes my job and most other devs job alot > easier. As if doing "diff -ruN ..." was so difficult for the devs...
Created attachment 64607 [details] mozilla-firefox-1.0.6-r4 update Version bumped to reflect latest patches against firefox including nss headers.
- Why don't you install a firefox-env (in r6) containing a MOZILLA_5_HOME environment so applications like rssowl can use the browser and the xpcom extensions??? - Why the hell do you symlink MozillaFirefox to mozilla-firefox? Do you fix redundancy problems in just to have a "-"-partitioned path in /usr/lib??? - Why are using the MOZILLA_5_HOME in the ebuild to copy/compile 1337-style files and never use it again after merging the browser - Why is Firefox still a co-product for mozilla as the mozilla suite has already be degraded to development only (implying block-state for mozilla and firefox) Jesus, I really don't understand what kind of noobs are allowed to merge these creepy ebuilds into portage without thinking first. ~x86 means unstable, that's right, but it does not imply "I submit my untested software and let others test". Tz....
A big slap for the submitter of the 1.0.6-r7-ebuild!! Congratulations, you've broken firefox although there are ebuilds in portage that rely on the ssl-headers like Evolution-2.4. Good job, Mr. Submitter.... We need a new maintainer. Soon, before he brakes everything, that is useable right now....
Created attachment 69604 [details] Attempt at updating ebuild I took a crack a diffing the latest firefox in portage with the latest one in this bug and came up with this ebuild. Disclaimer: I have no significant prior ebuild knowledge and this ebuild is untested. Use at your own risk.
(In reply to comment #33) > A big slap for the submitter of the 1.0.6-r7-ebuild!! > Congratulations, you've broken firefox although there are ebuilds in portage > that rely on the ssl-headers like Evolution-2.4. Good job, Mr. Submitter.... > > We need a new maintainer. Soon, before he brakes everything, that is useable > right now.... Mind expanding on this, as -r7 is -r6 with an security fix ... ----- --- mozilla-firefox-1.0.6-r5.ebuild 2005-09-15 11:22:51.000000000 +0200 +++ mozilla-firefox-1.0.6-r7.ebuild 2005-09-18 10:47:04.000000000 +0200 @@ -1,6 +1,6 @@ # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/www-client/mozilla-firefox/mozilla-firefox-1.0.6-r5.ebuild,v 1.9 2005/09/15 04:01:01 josejx Exp $ +# $Header: /var/cvsroot/gentoo-x86/www-client/mozilla-firefox/mozilla-firefox-1.0.6-r7.ebuild,v 1.8 2005/09/17 23:02:43 weeve Exp $ unset ALLOWED_FLAGS # stupid extra-functions.sh ... bug 49179 inherit flag-o-matic toolchain-funcs eutils mozconfig mozilla-launcher makeedit multilib @@ -127,6 +127,13 @@ # patch to add border to tooltips # https://bugzilla.mozilla.org/show_bug.cgi?id=238052 epatch ${FILESDIR}/gtk-tooltips.patch + + ################################### + # + # security fixes + # + ################################### + epatch ${FILESDIR}/${P}-GLSA105396.patch } src_compile() { -----
Also, just FYI, evolution-2.4 uses either mozilla or nss/nspr packages for nss/nspr, and _not_ firefox. Lastly, as I am the person who added the NSS building and installing in mozilla back then, I think I have to say I chose the wrong alternative then to make mozilla provide it, instead of splitting nss/nspr out. Evolution should depriciate mozilla as provider for nss/nspr, and use the seperate packages. Gnome herd, can we fix this?
@Martin Go and get yourself a beer from bavaria and shut up talking about providers of redundancy and useless code. I don't think Gnome should change this nor should they support the separate nss/nspr package only. Gentoo makes extensive use of the USE-flags, so please let the users decide whether they want nss/nspr or mozilla's and firefox' headers. Just to clarify things: It has been me who provided the firefox ebuild which installs headers, so I can also suggest improvements regarding the firefox ebuild. Don't break flexibility just to save 3 or 4 lines of code. If firefox' maintenance is too much for you, then leave it for me. It's no effort for me and we won't have creepy static firefox ebuilds anymore....
This is getting out of control bug will be ignored by mozilla herd until respect can be learned from users and developers a like. As soon as I see someone using respect on this bug I will go ahead and think about were it will go and how it could be beneficial or not to the gentoo project. I also agree with Martin that nss/nspr deps should depend on those provided outside mozilla/firefox. So everyone step back calm down and think before posting please.
(In reply to comment #37) > @Martin > > Go and get yourself a beer from bavaria Sorry, we do not have a 'babaria' here :/ > and shut up talking Nasty .. I asked why you think I should get a big slap, and asked why you accused me of breaking stuff ... and you get more insulting ? > about providers of redundancy and useless code. The code which you added (copied and wrongly labeled as NSS/NSPR I might add), is what I added to rebuild NSS and then install it .. meaning for people with mozilla, firefox and say nss installed, the same thing gets built 5 times ... I would call that redundant, event though I never said that here. I did though said please lets not waist more time and space than needed, but alas also attacked for that. > I don't think Gnome should change this nor should they support the separate > nss/nspr package only. Gentoo makes extensive use of the USE-flags, so please > let the users decide whether they want nss/nspr or mozilla's and firefox' > headers. > So splitting NSS out, and only installing it once, and not building it 2 times with each mozilla/firefox/whatever build, and then installing it for each of those, is a bad thing? Hmm... > Just to clarify things: It has been me who provided the firefox ebuild which > installs headers, so I can also suggest improvements regarding the firefox > ebuild. Which looks pretty much like the code from mozilla ebuild ... > Don't break flexibility just to save 3 or 4 lines of code. Sure, 3 or 4 lines of code in the ebuild (actually more like 40, but ok), but also an extra rebuild with each install of mozilla/firefox, and extra disk space if you have both of those. > If firefox' maintenance is too much for you, then leave it for me. > It's no effort for me and we won't have creepy static firefox ebuilds > anymore.... Where do you get this from? I never said this? Guess this is what you get for spending the last week on mozilla/firefox security updates, whatever bugs inbetween, etc ... But yeah, consider this bug marked as closed from my side.
(In reply to comment #36) > I think I have to say I chose the wrong alternative then to make > mozilla provide it, instead of splitting nss/nspr out. Evolution should > depriciate mozilla as provider for nss/nspr, and use the seperate packages. > Gnome herd, can we fix this? This sounds good, although I want to know what the rest of the gnome herd think. Could you open a new bug about this and assign it to us so we can keep track? Thanks.
@Martin I never insulted anyone, I'm just sueing "someone" for being really slow in maintaining the firefox-ebuild. And it does not matter if it's copied or not. No one cared to do it and "someone" did it. I'm glad I did it, because I'm sure that no one would have done it at all. So let's keep it as it is and be fine. ok? Darn!
Created attachment 70000 [details] 10MozillaFirefox for new env Change advice: To overcome several firefox-integration problems, the firefox-env should be set to replace mozilla's. The symlink in the ebuild should be removed as it is IMHO really naive to make firefox eclipse-aware.. Eclipse (-sdk) is currently (from what I've seen in portage) the only package that has a hardcoded MozillaFirefox in path. The eclipse-maintainers should fix this. I will file this as an eclipse bugreport, too.
I agree with azarah here, lets just wipe the mozilla dep completely and fall back to nss libs. Keeping them separate is a good thing, and it cuts down on the amount of bogus deps for testing.
It's obvious that you gentoo-devs agree, isn't it? But you are reducing problems that virtually don't exist at all. What bogus deps are you talking about? If you are not able to maintain the ssl-section, why don't you let other's care who are able to do this. Three gentoo-devs and all have ideas of a pocket-rocket.
As we now build against system nspr/nss this has become invalid.
