There are www-client/seamonkey-2.0_alpha3 revision bump. Ebuild attached next. Used patches: http://mahatma.bspu.unibel.by/download/transit/enigmail-0.95.7-cvs-20090317.tar.bz2 - 200k patch (unpacked - near 1.4g) to update enigmail-0.95.7 to current cvs (requred for USE="crypt"); mozilla-firefox-3.0.7-patches-0.1.tar.bz2 - current firefox patches from gentoo. May be removed by commenting out "PATCH="mozilla-firefox-3.0.7-patches-0.1" string in ebuild, work same for me, but I dummy add patches without meditation on it. ;) Notes: With Cairo with USE="directfb" ("directfb surface feature") used built-in mozilla's Cairo (this is required now), without USE="directfb" - system. On x86_64 target I have near 1 of 10 make failed. Just retry emerge command before panic. My x86_32 too slow to test loop builds, just all works even with "-O3" (yes, I use patched eclasses with additional CFLAGS and configure optimizations, but think Gentoo gays do not like it idea, but I may post it in bugzilla if you ask). Reproducible: Always
Created attachment 185522 [details] www-client/seamonkey-2.0_alpha3.ebuild
> http://mahatma.bspu.unibel.by/download/transit/enigmail-0.95.7-cvs-20090317.tar.bz2 > - 200k patch (unpacked - near 1.4g) to update enigmail-0.95.7 to current cvs > (requred for USE="crypt"); unpacked - near 1.4m ;). Don't worry.
Created attachment 185527 [details] not crytical fix (eclass dependece, overloaded)
Created attachment 185538 [details] Disabled usupported "xforms" flags
Created attachment 185544 [details] Removed dirt char in KEYWORDS
Created attachment 185561 [details, diff] Patches against mozilla eclasses mindf**king anti-optimizations There are patches against mozilla eclasses mindf**king anti-optimizations. While bug reporter historically denyed in ebuilds, I see no sense in this. Only "--disable-strip*" may have other reasons, but while I don't know it - I switched it off. I only don't touch "-fPIC" for amd64 target - I don't find this legend source ("-fPIC and x86_64") even in Google. But it may slow down code too. In most cases, I sure, system-wide C*FLAGS good for mozilla too. Also this patch contains "moznopango" fix for seamonkey-1 and related. PS I pessimistic about including this into portage, just subject-related FYI.
Created attachment 185657 [details] fixed directfb + system-cairo, fixed system-hunspell
Created attachment 185660 [details] fixed xulrunner (x86_32 firefox segfaults), still too experemental, works on x86_64
Created attachment 185667 [details, diff] problems on x86_32
I'd love to see this in portage. mozilla herd is there any chance for the _alpha versions?
Next(In reply to comment #10) > I'd love to see this in portage. mozilla herd is there any chance for the > _alpha versions? I don't know. Eclass patch must be not in portage - sure, just experemental, mozillas give segfaults on improved optimization. But just ebuild - may be. www-app/seamonkey-bin-2.0a3 alredy exists in portage, only this fact give me idea to post ebuild - I disdain precompiled binaries ;). IMHO source package must trap to official portage before binary, exclude compilation problems. Next I will post IMHO last fixed ebuild here. Now I send request to add my overlay to layman list - svn http://raw.googlecode.com/svn/trunk/ - for my development branch of PSPacer and some of ebuilds, absent in known to me places, inluding seamonkey-2.0a3 (but with "experemental" eclasses, sorry;) ). But may be I skip some formal procedures/etc., this is normal fo me. ;)
Created attachment 185995 [details] fixes Last stability question - "on" or "off" firefox patches. "X" relations (breaking without "X" flag on gtk & Cairo) removed to help experiments with "directfb" flag. Let it breaks in other stages. Also added useflag "moznosystem" to force using possible internal libraries (to any goal - testing, stability or dependences).
There is a problem doing sed for localization. if [[ -n ${LANG} && ${LANG} != "en" ]]; then elog "Setting default locale to ${LANG}" dosed -e "s:general.useragent.locale\", \"en-US\":general.useragent.loca le\", \"${LANG}\":" \ "${MOZILLA_FIVE_HOME}"/defaults/pref*/*.js || die "sed failed to change locale" fi It fails, I've not the erro now, and exits after seamonkey have been compiled, so I'd to comment it for get it install and also merge. You can reproduce it yourself using LANG != en . I think that it can be solved changing ${MOZILLA_FIVE_HOME}"/defaults/pref*/*.js for ${MOZILLA_FIVE_HOME}"/defaults/pref/defaults/pref/suite-l10n.js since this is the only file in /usr/lib/seamonkey that has this line. This file (sutie-l10n.js), also include this line: pref("spellchecker.dictionary", "en-US"); That should be replaced by pref("spellchecker.dictionary", "$LANG"); so everything can be done at same replacing ebuild lines I wrote before with this: if [[ -n ${LANG} && ${LANG} != "en" ]]; then elog "Setting default locale to ${LANG}" dosed -e "s:general.useragent.locale\", \"en-US\":general.useragent.loca le\", \"${LANG}\":" \ "${MOZILLA_FIVE_HOME}"/defaults/pref/suite-l18n.js || die "sed failed to change locale" dosed -e "s:spellchecker.dictionary\", \"en-US\":general.useragent.loca le\", \"${LANG}\":" \ "${MOZILLA_FIVE_HOME}"/defaults/pref/suite-l18n.js || die "sed failed to change locale" fi But I think it could be a good idea erase the || die, cause this is not a reason for stop installing. P.S. Sorry about my english.
Also, it would be a good idea include this in /usr/lib/seamonkey/seamonkey MOZ_USER_DIR="${HOME}/.mozilla/seamonkey" since seamonkey request for it.
I've test lines I wrotte 2 post ago, and they work fine, setting locales and hunspell to your language. ...and it also compile and works on PPC (I've test it too), so this keyword should be added to the ebuild too (I don't know why most of people ommit this keyword!!!).
Excuse me, I had a mistake on my first comment (#13). File who has to be modified is 'suite-l10n.js', so... if [[ -n ${LANG} && ${LANG} != "en" ]]; then elog "Setting default locale to ${LANG}" dosed -e "s:general.useragent.locale\", \"en-US\":general.useragent.loca le\", \"${LANG}\":" \ "${MOZILLA_FIVE_HOME}"/defaults/pref/suite-l10n.js || die "sed failed to change locale" dosed -e "s:spellchecker.dictionary\", \"en-US\":general.useragent.loca le\", \"${LANG}\":" \ "${MOZILLA_FIVE_HOME}"/defaults/pref/suite-l10n.js || die "sed failed to change locale" fi P.S. Now mozilla-firefox-patches-3.0.7-0.1 doesn't exist, so ebuild should be modified to use mozilla-firefox-patches-3.0.8-0.1 or nothing, because this patches aren't needed for compile and use seamonkey-2.
(In reply to comment #16) > Excuse me, I had a mistake on my first comment (#13). > File who has to be modified is 'suite-l10n.js', so... x-patches-3.0.7-0.1 doesn't exist, so ebuild should be > modified to use mozilla-firefox-patches-3.0.8-0.1 or nothing, because this > patches aren't needed for compile and use seamonkey-2. ... Interesting. First: why wildcards do no work? I widely using wildcards and all OK, but if in some case it. It wors: http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_alpha3.ebuild. Another sense to use double wildcard are: I was think about "xulrunner" option, like Firefox and directory name will be changed. Now I just satisfyed by Seamonkey and do not think to add this option (external xulrunner not support "-O3" optimization, but Seamonkey flying sure). Second. I know about dictionary, but: 2.1. I think, "app-text/hunspell" used by default instead of Mozilla's locale dictionary. Other package locale name MAY do not be equals to Mozilla's locale name (for example: "ru", "ru_RU", etc.). In Firefox ebuild this way more advanced (synthesed various locales aliases), but I prefer simple code (just add present locales). In many cases locales substitution are not trivial (for example, in CIS area). 2.2. I prefer foreign dictionary :)) to my native language dictionary. 2.3. I have my dictionary changed after install anymore to Russian by default and do not check this message. I do not deep dig this.
(In reply to comment #16) I was not right. Now is good? if [[ -n ${LANG} && ${LANG} != "en" ]]; then elog "Setting default locale to ${LANG}" dosed -e "s:\"en-US\":\"${LANG}\":g" \ "${MOZILLA_FIVE_HOME}"/defaults/pref/suite-l10n.js || die "sed failed to change locale" fi PS http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_alpha3.ebuild or "layman -s raw"
PPS ... but old locale was working (exclude dictionary) and if you know case when wildcards ("*") do not work - please, describe! (or "g" sed flag was required in your case?)
I've added seamonkey-2.0_alpha3 to the mozilla overlay. It doesn't have enigmail, though. And i need to have a look at the ldap stuff. Have fun
(In reply to comment #20) > I've added seamonkey-2.0_alpha3 to the mozilla overlay. > It doesn't have enigmail, though. And i need to have a look at the ldap stuff. > > Have fun OK. My ebuild in raw overlay was broken. But now you may get fixes also for latest state of pango/gcc/sqlite/etc (in overlay). "PATCH=.." line may be commented out. -O3 + system-sqlite don't work more ;(
(In reply to comment #10) > I'd love to see this in portage. mozilla herd is there any chance for the > _alpha versions? > It is avaliable via mozilla overlay. It will not appear in tree until we get to the rc's.
No beta/alpha will be added to the tree for mozilla products. Please refer to overlay for ebuilds.
Initial (tests in progress) release of www-client/seamonkey-2.0_beta1 added to "raw" overlay. Not posted here while 1 patch (now) required. Usual "001-seamonkey_gentoo_install_dirs.patch" replaced by sed command. Direct links: http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_beta1.ebuild http://raw.googlecode.com/svn/trunk/www-client/seamonkey/files/2.0_beta1/001-ogg_debug.patch
(In reply to comment #24) > Initial (tests in progress) release of www-client/seamonkey-2.0_beta1 added to > "raw" overlay. Not posted here while 1 patch (now) required. Usual > "001-seamonkey_gentoo_install_dirs.patch" replaced by sed command. > Direct links: > > http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_beta1.ebuild > http://raw.googlecode.com/svn/trunk/www-client/seamonkey/files/2.0_beta1/001-ogg_debug.patch > If you want to see this supported, you need to provide patches based off of work already done, we do not have time to resort threw an entire ebuild just to see what you have changed and why, you also need to provide info as to where the patch comes from. All credit needs to be given to the author of patch. Bug will be reopened for a few days while I give ya time to update info as requested, if you do not I will be forced to leave out the patch and make another bump in the overlay without your feedback.
Denis, I should have also mentioned I would like to see your overlay closer to that of what mozilla has in the overlay, your using a bit out of date eclass (mozilla-launcher) which has been drop'd in the ovleray
(In reply to comment #26) > Denis, I should have also mentioned I would like to see your overlay closer to > that of what mozilla has in the overlay, your using a bit out of date eclass > (mozilla-launcher) which has been drop'd in the ovleray OK. There are preview: cleaned (may be not all - before understanding) and some around default mozcoreconf: http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_beta1-r1.ebuild (some changed cross-looked-up from mozilla overlay, but I keep EAPI-1 while) (patch - same, patch comes from me & same sources) Are I must to use mozcoreconf[-2]? Now I use [fixed] mozcoreconf.eclass. I may rewrite ebuild to: 1) No mozcoreconf[-2] (I just move fixed mozcoreconf into ebuild and forget to CFLAGS filtering or move fixed filtering); 2) mozcoreconf (now used, simple to do); 3) mozcoreconf-2. Suggestions? PS Zero-release tested, working. This r1 - in progress. After tests may be provided as patch against seamonkey-1 - if required.
(In reply to comment #27) > (In reply to comment #26) > > Denis, I should have also mentioned I would like to see your overlay closer to > > that of what mozilla has in the overlay, your using a bit out of date eclass > > (mozilla-launcher) which has been drop'd in the ovleray > > OK. There are preview: cleaned (may be not all - before understanding) and some > around default mozcoreconf: > http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_beta1-r1.ebuild > (some changed cross-looked-up from mozilla overlay, but I keep EAPI-1 while) > (patch - same, patch comes from me & same sources) > > Are I must to use mozcoreconf[-2]? Now I use [fixed] mozcoreconf.eclass. I may > rewrite ebuild to: > 1) No mozcoreconf[-2] (I just move fixed mozcoreconf into ebuild and forget to > CFLAGS filtering or move fixed filtering); > 2) mozcoreconf (now used, simple to do); > 3) mozcoreconf-2. > > Suggestions? > > PS Zero-release tested, working. This r1 - in progress. After tests may be > provided as patch against seamonkey-1 - if required. > The problem is mozilla herd is moving everything to eapi 2, mozilla-launcher will be masked soon as last few packages using it are removed/masked. I would suggest you update your overlay to match the mozilla overlay, and provide patches based around the mozilla overlay. If you have any question feel free to email me I will answer any question that you might have.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > Denis, I should have also mentioned I would like to see your overlay closer to > > > that of what mozilla has in the overlay, your using a bit out of date eclass > > > (mozilla-launcher) which has been drop'd in the ovleray > > > > OK. There are preview: cleaned (may be not all - before understanding) and some > > around default mozcoreconf: > > http://raw.googlecode.com/svn/trunk/www-client/seamonkey/seamonkey-2.0_beta1-r1.ebuild > > (some changed cross-looked-up from mozilla overlay, but I keep EAPI-1 while) > > (patch - same, patch comes from me & same sources) > > > > Are I must to use mozcoreconf[-2]? Now I use [fixed] mozcoreconf.eclass. I may > > rewrite ebuild to: > > 1) No mozcoreconf[-2] (I just move fixed mozcoreconf into ebuild and forget to > > CFLAGS filtering or move fixed filtering); > > 2) mozcoreconf (now used, simple to do); > > 3) mozcoreconf-2. > > > > Suggestions? > > > > PS Zero-release tested, working. This r1 - in progress. After tests may be > > provided as patch against seamonkey-1 - if required. > > > > The problem is mozilla herd is moving everything to eapi 2, mozilla-launcher > will be masked soon as last few packages using it are removed/masked. I would > suggest you update your overlay to match the mozilla overlay, and provide > patches based around the mozilla overlay. If you have any question feel free to > email me I will answer any question that you might have. > Initial beta 1 is in the mozilla overlay, any bugs please open a new bug report.
seamonkey-2.0_beta1-r1 in "raw" overlay / URLs now works and full-featured (IMHO). But bug is closed and I will not post diffs here.
(In reply to comment #30) > seamonkey-2.0_beta1-r1 in "raw" overlay / URLs now works and full-featured > (IMHO). But bug is closed and I will not post diffs here. > Dennis please email me the diffs directly at gentoobugsie@gmail.com.
