The build ID is always set to zeros in recent mozilla ebuilds. This causes (many) plugins which parse the build id as a date to fail to ask the user to install in their profile directory. The end result is that many plugins can not be installed by a user (with no permissions to the system installation dir). from http://www.mozilla.org/build/distribution.html BUILD_OFFICIAL and MOZILLA_OFFICIAL need to be set in order for the date to be used as the build id. The current ebuild has an 'export BUILD_OFFICAL=1' line commented out with this accompanying comment: # NB: We can't export these vars until enigmail is installed separately instead # of integrated into this ebuild. If enigmail wont build with the variables set, it should depend on the use flags ('moznomail' I believe), so that users who do not use the mail client can actually install plugins. As far as I know, this behaviour is a regression since 1.7.3 or so as I discovered it when upgrading to 1.7.8 from 1.7.3 As a workaround, I believe the user can export MOZILLA_OFFICIAL and BUILD_OFFICIAL using the shell before running emerge mozilla. ie BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 emerge www-client/mozilla I haven't tested a plugin installation with this yet as the build is still going, however I have checked the build_number and it has been correctly generated this time. I think in the meantime (i guess until this enigmail problem is fixed) a warning should be printed by the ebuild to inform them of the problem and give them the opportunity to retry the ebuild with the above workaround. I am amazed I lasted two weeks without mouse gestures, decent download manager integration, and all the other plugins. Reproducible: Always Steps to Reproduce: 1. emerge a mozilla version > 1.7.3 2. try an install a plugin such as the mozgest plugin mozgest_1_0_1.xpi definitely fails for me (and many others). Actual Results: The plugins report a failure to install due to a lack of permissions to install in the /usr/lib/mozilla directory, and often suggest that the user should do a profile installation, however the plugins do not actually give the user a choice because the build id is zero and thus the mozilla version is not deemed new enough to support installation into the .profile directory. Expected Results: Plugins should pop up a dialog asking the user if they wish to install into their profile directory. From looking at the plugins code, they generally check the build id, and if it represents a new enough version of mozilla, they show a dialog asking the user if they wish to install into their own profile directory. here is the 'emerge info' as asked for, though I don't think it is relevant in this case. emerge info Portage 2.0.51.22-r2 (default-linux/amd64/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r1-blah x86_64) ================================================================= System uname: 2.6.9-gentoo-r1-blah x86_64 AMD Athlon(tm) 64 Processor 3400+ Gentoo Base System version 1.4.16 dev-lang/python: 2.3.3-r1, 2.4.1-r1 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.6-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr//lib/mozilla/defaults/pref /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/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 " DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache confcache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.au.gentoo.org/gentoo-portage" USE="amd64 X X509 aalib adns alsa arts audiofile avi berkdb bitmap-fonts bsh cdr crypt cups curl dga directfb dnd doc dv dvb dvd dvdr emacs emacs-w3 encode esd evo fam fbcon flac foomaticdb fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile imagemagick imlib ipv6 java jpeg kde kerberos ldap libwww lirc live lzw lzw-tiff mad mikmod monkey motif mozcalendar mozilla moznocompose moznoirc moznomail mozsvg mp3 mpeg multilib-strict mysql ncurses nls nvidia oav offensive ogg opengl optional-tasks pam parse-clocks pcap pcre pdflib perl plotutils png ppds python qt quicktime quotes readline regexp rogue ruby samba scanner sdl slang snmp speex spell sqlite ssl stroke tcltk tcpd tetex theora tiff toolbar transcode truetype truetype-fonts type1-fonts unicode usb userlocales v4l2 vorbis wmf xatrix xemacs xerces xinerama xml xml2 xmms xosd xpm xv yahoo zlib zvbi userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
In case it isn't obvious from the context, when I wrote 'plugin' I meant 'extension'.
Mozilla is dead upstream and will be removed from portage.
