It looks like Seamonkey is going to be going 1.0 final pretty soon. Is someone going to create a new ebuild/package or is it just going to be grouped as mozilla 1.8?
*** Bug 116380 has been marked as a duplicate of this bug. ***
Created attachment 75859 [details] proposed ebuild for seamonkey-1.0_beta This is ebuild I've made based on mozilla-1.7.12-r2 ebuild. It lets me emerge seamonkey but mozilla-launcher does not recognize seamonkey browser so I run it using /usr/lib/seamonkey/seamonkey. All files from my ebuild are stored in this file http://rafal_glazar.w.interia.pl/seamonkey-1.0_beta.tar.bz2. Happy testing. PS. I think that mozilla-launcher should be updated to recognize seamonkay name and treat it as mozilla. Mozilla name is used only by Mozilla Fondation products which SeaMonkey is not so making mozilla 1.8 ebuild IMHO would not wrong.
Edit of Comment #2: Last sentence should be: "Mozilla name is used only by Mozilla Fondation products which SeaMonkey is not so making mozilla 1.8 ebuild IMHO would be wrong."
Created attachment 76829 [details] ebuild for seamonkey-1.0_beta version 2 This is second version of my ebuild. I've added cairo USE flag for those, who wants to test cairo as svg renderer engine, seamonkey now stores configuration files in .seamonkey directory. I've also added blockers for www-client/mozilla because having both mozilla and seamonkey made my seamonkey unusable. As earlier whole ebuild is stored here: http://rafal_glazar.w.interia.pl/seamonkey-1.0_beta_v2.tar.bz2
i got some problems emerging the 1.0 beta v2 ebuild. i simply put the extracted tarball in www-clients/seamonkey in my portage overlay. adding: locale/US/messenger-region/contents.rdf (stored 0%) gmake[2]: Leaving directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla/mailnews' gmake[1]: Leaving directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla' /usr/bin/gmake tier_98 gmake[1]: Entering directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla' tier_98: calendar creating calendar/Makefile ./build/autoconf/make-makefile: Cannot read ./calendar/Makefile.in: No such file or directory gmake[2]: Entering directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla/calendar' gmake[2]: *** No rule to make target `export'. Stop. gmake[2]: Leaving directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla/calendar' gmake[1]: *** [tier_98] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/seamonkey-1.0_beta/work/mozilla' make: *** [default] Error 2 !!! ERROR: www-client/seamonkey-1.0_beta failed. !!! Function src_compile, Line 207, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. and emerge --info: Portage 2.1_pre3-r1 (default-linux/x86/2005.0, gcc-3.4.5, glibc-2.3.5-r3, 2.6.13-gentoo-r4 i686) ================================================================= System uname: 2.6.13-gentoo-r4 i686 AMD Athlon(TM) XP 2400+ Gentoo Base System version 1.12.0_pre12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac aalib acl acpi alsa ao apm audiofile avi bash-completion berkdb bitmap-fonts bzip2 bzlib canna cdb cdda cdparanoia cdr cjk corba crypt cscope cups curl dlloader dmx dvd dvdread ecc eds emacs emboss encode esd ethereal exif expat fam fame ffmpeg firefox flac font-server foomaticdb fortran freetype freewnn gcj gd gdbm ggi gif glut gmp gnome gnustep gpm gstreamer gtk gtk2 guile howl icecast idea idn imagemagick imlib jpeg lcms ldap libcaca libg++ libwww live lua lzo mad matroska mhash mikmod mmx mmx2 mmxext mng motif mozcalendar mozdevelop mozilla mozsvg mp3 mpeg musepack mysql nas ncurses nls nvidia objc offensive ogg oggvorbis openal opengl oss pam pcre pdflib perl png portaudio python quicktime readline real recode ruby screen sdl skey sndfile snmp speex spell sqlite sse ssl stats tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb video_cards_matrox vorbis win32codecs wxwindows x86 xinerama xml xml2 xmms xosd xprint xv xvid zlib elibc_glibc kernel_linux userland_GNU" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS, MAKEOPTS would be nice if there is a way to fix it :P
Created attachment 76954 [details] updated seamonkey-1.0_beta version 2 ebuild It looks like calendar isn't a part of seamonkey suite (it is not listed on seamonkey webpage and there is no calendar directory in seamonkey tarball) so I just trow it out of the ebuild. Tarball with updated ebuild is here: http://rafal_glazar.w.interia.pl/seamonkey-1.0_beta_v3.tar.bz2
i think i found another bug - i'm not sure whether its the ebuild or seamonkey itself - however i cannot find text on the current page using /keyword_to_find. another nice thing would be if there were a way to disable all the debugging stuff. i know seamonkey is beta, bug the debugging stuff makes it a whole lot slower, and for the enduser wanting to use seamonkey but not debugging/developing it that would be a nice option. if there is a configure option for it a use flag would be really nice :P (i also could do that when i find time :/ damned school.)
Could you give more details about this finding text bug. What does "cannot find" mean and what is "/keyword_to_find" method.
if you are on a website and simply press / and enter some keyword mozilla (also firefox and the old mozilla suite) normally executes a simple "find" on that word - it highlights it and jumps where it is. and by dont work i litterarily mean don't work :( unfortunatly it does nothing - really nothing. i also have no hint where to look for debugging prints or similar - sorry.
Regarding comment #6, I've requested the restoration of calendar, which will occur after the 1.0 release. So. Hang on to the keyword. Maybe just comment it out for now.
Tried the most recent ebuild posted above, and while it compiled, canvas is only partially functioning, password manager does not work and popups don't seem to get blocked - various exceptions popup in the javascript console as these things fail. Also, for some reason it felt it had to have a ~/.seamonkey dir instead of ~/.mozilla so I had to symlink it. Kind of annoying. Seamonkey is basically Mozilla 1.8
By the way, the official 1.0 binary build works fine. *looks suspiciously at the long list of moz_config in the ebuild*
1.0 final has been released a few hours ago.
*** Bug 121139 has been marked as a duplicate of this bug. ***
Created attachment 78648 [details, diff] mozilla-launcher-1.45-seamonkey.patch Hi, I was able to compile and install seamonky-1.0 with the latest attached ebuild. I also managed to patch mozilla-launcher so it recognizes seamonkey now and can also register the chrome components of seamonkey. The only problem I have is, that seamonkey doesn't start. No matter if I run it via mozilla-launcher or directly by using /usr/lib/seamonkey/seamonkey I only get the message "No running windows found" and then the shell hangs until I press CTRL+C. After this ps aux shows one instance of seamonkey-bin running but I have no seamonkey-window and so can't test seamonkey at all :-( Cheers Poly
Did you just rename the seamonkey-1.0_beta ebuild or did you use my new ebuild from bug http://bugs.gentoo.org/show_bug.cgi?id=121139? I will attach new ebuild and new eclass here. Rest of the files are the same as in seamonkey-1.0_beta ebuild. Your patch for mozilla-launcher works for me. I will attach seamonkey.desktop for updated mozilla-launcher.
Created attachment 78658 [details] seamonkey-1.0.ebuild
Created attachment 78659 [details] mozconfig-3.eclass This is updated mozconfig.eclass. Put it in /usr/local/portage/eclass.
Created attachment 78660 [details] seamonkey.desktop seamonkey.desktop for updated mozilla-launcher.
Hi, @ rafal: I just renamed the seamonkey-1.0_beta_version_2 ebuild you submitted here some days ago. I'll give your new ebuild and the eclass a try this evening... Cheers Poly
I'm thinking of adding makemake_mailnews function to mozconfig.eclass which will leave old makemake intact and makes posible compiling extensions in mailnews/extensions directory.
Hi, alright Rafal, your latest ebuild works here, good work. I can now run and use seamonkey, but I'm not very impressed. The cookie-manager doesn't work, the interface where the language for seamonkey (not for the websites) can be set is gone... Does anybody know a URL where I can report these problems? I must admit the www.mozilla.org website is kinda confusing to me I even had problems to find the seamonkey projectpage... Cheers Poly
Created attachment 78677 [details] mozconfig-3.eclass Ok. Function makemake_mailnews works so here is new eclass and ebuild. Poly: Try this one http://www.mozilla.org/projects/seamonkey/releases/
Created attachment 78678 [details] seamonkey-1.0.ebuild
Created attachment 78679 [details] mozilla-launcher-1.45-r1.ebuild And the ebuild for mozilla-launcher that uses Poly's patch.
In order to use this ebuild you have to name Poly's patch seamonkey-1.0.patch and put it into files directory in mozilla-launcher directory in your portage overlay.
Hi, alright I talked with some devs in #seamonkey on irc.mozilla.org and all my problems were caused by some --enable-extensions options. I recompiled seamonkey without any of these options and now my cookie-manager works, I can switch the languages again and also the "/keyword_to_find" problem is gone. I'm now trying to find out, which of all these --enable-extensions options is/are the culprit here... I hope it isn't the irc-extension because I don't like the chatzilla thingy at all and don't wanna have it compiled into my seamonkey :) Cheers Poly
Created attachment 78687 [details] seamonkey-1.0.ebuild This ebuild should resolve all problems Poly has. I've also added moznoroaming USE flag as Poly has sugested to me but I did implement it a little different.
Created attachment 78695 [details] seamonkey-1.0.ebuild I've made this ebuild depend on mozilla-launcher-1.45-r1.ebuild so that everything works as it should. For all the "lazy" ;-) people I've made a tarball with all files needed for emerging seamonkey. It is here: http://rafal_glazar.w.interia.pl/seamonkey-1.0.tar.bz2. Just download it, untar to your portage overlay and emerge. PS. I had to delete my ~/.mozilla directory in order to all things work. Good thing that I can restore my Bookmarks and History just by copying bookmarks.html and history.dat
Hi, my problems are all fixed now. Thanx again for your unweary work in this Rafal. I'm going to replace all my mozilla-installations with seamonkey. Now we only need a maintainer for this package preferrably a dev who will bring this package into portage as soon as possible. Cheers Poly
Hey Lars. Chatzilla isn't compiled :) Well. It mostly isn't. Just javascript and XML.
Left my .mozilla (did make a backup) without problems. I did however get a seamonkey.desktop without a reference to the seamonkey.png pixmap. I did see a pixmap beeing copyed, albeit a bit large.
If noone else in the herd does anything with this before my day off, which is over a week away, I will work on a proper ebuild for the tree. I am not gonna add another eclass to the tree, mozilla-launcher will be updated at same time as I have other changes that need to be commited to the tree. So you all should think about how to use what is in tree right now before wanting to add yet another eclass to the tree which can never be removed.
Created attachment 78761 [details, diff] desktop file patch Fixes reference to icon location
Hi Jory. My goal was to use just standard eclass. I've added one function to standard eclass because enigmail 0.94.0 should go into /mailnews/extensions not /extensions and old function makemake didn't work. I did not change anything else and old makemake is there. So my mozconfig-3.eclass can be named mozconfig.eclass and replace mozconfig.eclass in the tree. Old mozilla ebuilds should work with it. This will require one change to my ebuild (changing "inherit mozconfig-3" to "inherit mozconfig")
I've updated seamonkey.desktop. I've also updated seamonkey icon. Now it is 48x48 pixels. It's all in new seamonkey-1.0.tar.bz2.
Hi, @kyberneticist: You're right. I just compiled seamonkey without the "moznoirc" useflag and also have no way found to run chatzilla. Seems like we still have issues to solve. @Jory A. Pratt: What about a replacement mozconfig.eclass which still works with the other apps that use this eclass? Would that be an acceptable solution? Cheers Poly
This is odd. I have Chatzilla. I just did connect to irc.mozilla.org and joined #seamonkey.
Hi, could be related to useflags. I built seamonkey with these useflags: www-client/seamonkey-1.0_pre +crypt -debug -gnome -ipv6 +java -ldap -mozcalendar -mozdevelop +moznocompose -moznoirc +moznomail +moznoroaming -moznoxft +mozsvg -postgres +ssl +truetype -xinerama +xprint What are yours Rafal? Cheers Poly
P.S.: don't bother about the _pre in the packagename. I use this for all my ebuilds in my overlay so that these packages get updated as soon as portage catches up to these packages. Poly
And those are mine (portage 2.1_pre4): www-client/seamonkey-1.0 USE="crypt gnome ipv6 java mozcalendar mozdevelop mozsvg ssl truetype -debug -ldap -moznocompose -moznoirc -moznomail -moznoroaming -moznoxft -postgres -xinerama -xprint" Have you tried delete your ~/.mozilla (beckup first)?
Hi, I just rechecked this. I renamed my .mozilla directory and fired up seamonkey. No chatzilla available. The strange thing is, I can see a preferences-dialog for chatzilla in the preferences of seamonkey. I can also run chatzilla's preferences. But I can't run chatzilla itself... strange thing... Poly
No problems with chatzilla here. All the other things work also very well.
Hi, @kyberneticist: Could you please post the USE-flags with which you built your seamonkey? @all others: please also post your USE-flags for seamonkey and wether chatzilla works for you or not. Cheers Poly
Hi, here are my USE-Flags: www-client/seamonkey-1.0 +crypt -debug -gnome -ipv6 +java -ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznoroaming -moznoxft +mozsvg -postgres +ssl +truetype -xinerama -xprint Works without problems, including Chatzilla
The ebuild from Comment #29 works great. In X-Chat is no menuoption to open urls in Seamonkey after a right-klick on a URL. Ist this an seamonkey- or X-Chat-problem?
I'm cleaning my ebuild and have a question if anyone know: What are those lines in mozconfig eclass for? declare MOZ=$([[ ${PN} == mozilla || ${PN} == gecko-sdk ]] && echo true || echo false) declare FF=$([[ ${PN} == *firefox ]] && echo true || echo false) declare TB=$([[ ${PN} == *thunderbird ]] && echo true || echo false) declare SB=$([[ ${PN} == *sunbird ]] && echo true || echo false) I want to know why they are there? And Poly maybe it's something outside seamonkey like wrong java or something?
(In reply to comment #47) > I'm cleaning my ebuild and have a question if anyone know: What are those lines > in mozconfig eclass for? It sets certain variables, if the Package Name "matches". > declare MOZ=$([[ ${PN} == mozilla || ${PN} == gecko-sdk ]] && echo true > || echo false) MOZ is set to true, if PN is either "mozilla" or "gecko-sdk". Else, MOZ is set to false > declare FF=$([[ ${PN} == *firefox ]] && echo true || echo false) FF is set to true, when PN ends with "firefox" - or is it, when it starts with "firefox"?
I know that. I asked why they are there because i did not find usage of this variables neither in mozconfig.eclass nor in the mozilla ebuild.
any idea when this seamonkey beta build will make it into the official portage tree?
(In reply to comment #49) > I know that. I asked why they are there because i did not find usage of this > variables neither in mozconfig.eclass nor in the mozilla ebuild. > declare MOZ=$([[ ${PN} == mozilla || ${PN} == gecko-sdk ]] && echo true || echo false) declare FF=$([[ ${PN} == *firefox ]] && echo true || echo false) declare TB=$([[ ${PN} == *thunderbird ]] && echo true || echo false) declare SB=$([[ ${PN} == *sunbird ]] && echo true || echo false) #################################### # # Setup the initial .mozconfig # See http://www.mozilla.org/build/configure-build.html # #################################### case ${PN} in mozilla|gecko-sdk) # The other builds have an initial --enable-extensions in their # .mozconfig. The "default" set in configure applies to mozilla # specifically. : >.mozconfig || die "initial mozconfig creation failed" mozconfig_annotate "" --enable-extensions=default ;; *firefox) cp browser/config/mozconfig .mozconfig \ || die "cp browser/config/mozconfig failed" ;; *thunderbird) cp mail/config/mozconfig .mozconfig \ || die "cp mail/config/mozconfig failed" ;; *sunbird) cp calendar/sunbird/config/mozconfig .mozconfig \ || die "cp calendar/sunbird/config/mozconfig failed" ;; esac that is the reference to your question. I plan on using mozcoreconf and mozconfig-2 when I get around to adding this to the tree.
(In reply to comment #47) > And Poly maybe it's something outside seamonkey like wrong java or something? Hi, yes maybe. I will give a chatzilla-enabled seamonkey a try on my ~x86 box tomorrow. By the way which java are you using? I have dev-java/blackdown-jdk-1.4.2.03 installed on that x86 machine where chatzilla isn't working. Cheers Poly
Same as mine so it might not be the java.
This is summary of my work since my last post. I tried to make ebuild using mozcoreconf and mozconfig-2 and this is the outcome: 1. It looks like some flags from mozcoreconf breaks seamonkey. It does compile but does not start giving error: seamonkey-bin exit with non-zero status (or soething like that) those flags are --enable-single-profile --disable-profilesharing --disable-profilelocking. 2. I still don't understand the need for those declare lines because updated case works without changing those. 3. I've made new ebuild using mozconfig and here are the changes (tarball is updated): - I've renamed mozgonfig-3 back to mozgonfig and change ebuild accordingly, - I've added --enable-canvas because someone here told that it works partialy and ./configure --help gives me this flag so I think that canvas is disabled by default, - I did comment out line adding -enable-extensions=gnomevfs because it is compiled just by setting --enable-gnomevfs - I did the same with "mozconfig_use_extension postgres sql" because it sets -enable-extensions=-sql when the postgres USE flag is not set and that is no needed and I've added mozconfig_annotate '' --enable-extensions=sql when postgres is set (by the way if enyone know what is this needed for e-mail me about it instead of adding comment to this bug to avoid cluttering of this bug raport) 4. I still don't know why in some cases chatzilla does not start. 5. There has been a word that seamonkey does not compile with my ebuild on amd64 so I've added ~amd64 keyword and I'm asking for anyone on that arch to try it and email me if it works, USE flag used and emerge info. Thanks Rafal
Created attachment 79041 [details] mozconfig.eclass
Created attachment 79042 [details] seamonkey-1.0.ebuild
Created attachment 79085 [details] mozconfig.eclass Updated eclass for error on AMD64 while building with GCC >=4.0.0
(In reply to comment #57) > Created an attachment (id=79085) [edit] > mozconfig.eclass > > Updated eclass for error on AMD64 while building with GCC >=4.0.0 > After changing your "if [[ $ARCH == x86 ]];" to "if [[ $ARCH == amd64 ]];" Seamonkey successfully emerged with your ebuild.
Created attachment 79104 [details] seamonkey-1.0.ebuild EzInKy: I did send you ebuild I tested on my x86 machine. Here is corect one in which I moved AMD64 GCC 4.0 hack from ecless to ebuild.
Created attachment 79105 [details] mozconfig.eclass I hope this is last change. ;-)
Please supply the other patches this ebuild requires.
Hi, I can tell more about the chatzilla problem. I was playing around a bit with the following useflags: moznocompose moznomail And these are my results: seamonkey built with +moznocompose +moznomail = no working chatzilla seamonkey built with -moznocompose -moznomail = chatzilla works seamonkey built with +moznocompose -moznomail = chatzilla works but also does composer seamonkey built with -moznocompose +moznomail = chatzilla works All other useflags were the same in all four builds: +crypt -debug -gnome -ipv6 +java -ldap -mozcalendar -mozdevelop -moznoirc +moznoroaming -moznoxft -postgres +ssl +truetype -xinerama +xprint It seems like the combination of +moznocompose +moznomail also prevents seamonkey from having a working chatzilla even with -moznoirc. Another problem seems to be that composer is also built when the useflags are +moznocompose -moznomail which shouldn't be the case. I didn't investigate further in this as I have not much time the next few days but maybe Rafal or somebody else can find the real problem behind these two contradictions. Cheers Poly
Created attachment 79179 [details] seamonkey-1.0.ebuild Well, as they say "Hope is a fool's mother". But back to ebuild. It looks like Chatzilla does not work without Composer so i've changed ebuild that Chatzilla is build when Composer is build and Composer is not build when Chatzilla isn't build (I hope you understand what i did just said). When someone sets +moznocompose and does not set +moznoirc ebuild gives warning that Chatzilla will not be build. PS. I'm not english native so if there is an error in the warning let me know.
Created attachment 79180 [details, diff] firefox-cairo-canvas.patch Kiyoshi Aman: As you request I add all the patches. I've made also tarball with all the files. I is here: http://rafal_glazar.w.interia.pl/seamonkey-1.0.tar.bz2
Created attachment 79181 [details, diff] firefox-nopangoxft.patch
Created attachment 79182 [details, diff] mozilla-rpath-1.patch
Created attachment 79199 [details] seamonkey-1.0.ebuild There are two components that does not work without Composer: Mail and Chatzilla. Also judging by the ebuild Calendar does not work without Mail. So Composer might be excluded from the build only if all of those three components are not build which this new ebuild does. Also Chatzilla is a part of default extensions setup so with old ebuild it will be build with moznoirc set. This is also resolved. PS. Tarball updated. If there is no need for those warning I've added I will remove them.
Created attachment 79208 [details] seamonkey-1.0.ebuild Looks like AMD64 GCC4 bug affect GCC 3.4.5 also. This is fixed now.
useflag moznocompose ist set, but the ebuild compiles composer. complete flags: gnome java moznocompose moznoirc ssl truetype xprint -crypt -debug -ipv6 -ldap -mozcalendar -mozdevelop -moznomail -moznoroaming -moznoxft -postgres -xinerama
That is correct. As I said in Comment #66 Mail needs Composer to work and you did not set moznomail flag so composer is compiled. Ebuild gives warning about that.
So, any bugs left that prevent seamonkey from being put into portage?
A lot of plug-ins will get broken, I can name a few that no longer work properly.
My Seamonkey keeps reverting the theme every time I restart the browser: when I select a new theme and restart the browser, it selects the theme, but on the next restart it reverts again. Also, applications that depend on Mozilla can't link to Seamonkey (yet?): Evolution complains about libplc4.so, and Epiphany wants libgtkembedmoz.so. Also, the calendar toolbar is completely wrecked (not matching the theme at all, but I think the toolbar works otherwise). Seamonkey also seems to hang a lot when loading pages with Javascript: it'll just stop there for like 3 seconds, being unresponsive, then keep going again.
(In reply to comment #73) > My Seamonkey keeps reverting the theme every time I restart the browser: when I > select a new theme and restart the browser, it selects the theme, but on the > next restart it reverts again. Also, applications that depend on Mozilla can't > link to Seamonkey (yet?) Yes, you're right. Openoffice with +mozilla also still depends on the old Mozilla-suite. So there is still some work to be done.
actually, maybe things like openoffice should still depend on the old mozilla, until we are sure that seamonkey is a full and debugged replacement. given where things are going, maybe we also should have a seamonkey flag in addition to the mozilla flag.
(In reply to comment #74) > (In reply to comment #73) > > My Seamonkey keeps reverting the theme every time I restart the browser: when I > > select a new theme and restart the browser, it selects the theme, but on the > > next restart it reverts again. Also, applications that depend on Mozilla can't > > link to Seamonkey (yet?) > > Yes, you're right. Openoffice with +mozilla also still depends on the old > Mozilla-suite. So there is still some work to be done. > Well, but why should this be a bug or something? Let OOo depend on Mozilla Suite - were's the problem? I mean, Firefox users are also forced to install Mozilla Suite for quite some programs - it's not considered to be a big problem (it seems), so why should this be a problem with SeaMonkey?
Well, considering how, at the moment, Seamonkey and Mozilla cannot both be installed at the same time on one machine, it does pose a problem because users cannot install Seamonkey anymore: apps depend on Mozilla, and Seamonkey cannot be installed without first uninstalling Mozilla. Maybe later, some sort of slotting or whatever could be done to allow both on the same system, but for now I think it is a problem.
(In reply to comment #77) > Well, considering how, at the moment, Seamonkey and Mozilla cannot both be > installed at the same time on one machine, it does pose a problem because users > cannot install Seamonkey anymore: apps depend on Mozilla, and Seamonkey cannot > be installed without first uninstalling Mozilla. Maybe later, some sort of > slotting or whatever could be done to allow both on the same system, but for > now I think it is a problem. > arrgghhh...may I ask why? there are few unix non-system apps that run into this problem. if I recall, mozilla likes the .mozilla directory; seamonkey should like a .seamonkey directory. what else?
(In reply to comment #77) > Well, considering how, at the moment, Seamonkey and Mozilla cannot both be > installed at the same time on one machine, it does pose a problem Ah, okay, I didn't realise that. So, yes, I agree, it will be a problem. However, I much rather think that the real problem is, that not both programs can be installed at the same time. IMO *that* should be fixed.
(In reply to comment #79) > (In reply to comment #77) > > Well, considering how, at the moment, Seamonkey and Mozilla cannot both be > > installed at the same time on one machine, it does pose a problem > > Ah, okay, I didn't realise that. So, yes, I agree, it will be a problem. > However, I much rather think that the real problem is, that not both programs > can be installed at the same time. IMO *that* should be fixed. > Keep in mind that, while it is a new ebuild, Seamonkey really is just Mozilla 1.8. You can disagree with me and consider them two separate programs (which might actually be quite useful, as some corporations, organizations are more comfortable with a Mozilla foundation-supported program), but Seamonkey contains most of the same code as Mozilla, compiles mostly the same libraries (thus, most if not all applications that link to Mozilla should be able to link to Seamonkey), they share the same .mozilla directory, etc. and thus, IMHO currently the only solution is to make "slot" ebuilds so that both can be installed... By the way, I have not yet used the Portage slot system so I really don't know what I'm talking about here :). I'm sure someone can think of a more adequate solution, but right now I'm thinking that we'll only need Mozilla and Seamonkey on the same system in special cases (kind of like installing Apache and Apache 2 on the same system, I guess), so I'm in favor of encouraging users to upgrade Mozilla 1.7 to Seamonkey, and providing some sort of "slot" system to install both only if enterprises/organizations express the need. Thanks for reading the above rant :). Feel free to disagree.
Frank, I fully agree with you. It's nonsense to have users install Mozilla just because they want OO.org to use the bindings. IMHO Mozilla and Seamonkey should be treated as one and the same program, with Seamonkey being the newer version, compared to Mozilla. However, I don't know if this is possible at all with the ebuild system ;-) But having the two programs installed at the same time is certainly not an option for most of the users.
(In reply to comment #81) > Frank, I fully agree with you. It's nonsense to have users install Mozilla just > because they want OO.org to use the bindings. IMHO Mozilla and Seamonkey should > be treated as one and the same program, with Seamonkey being the newer version, > compared to Mozilla. However, I don't know if this is possible at all with the > ebuild system ;-) > But having the two programs installed at the same time is certainly not an > option for most of the users. > since we are all opining... I think the folks at seamonkey have made a mistake if they stuck to .mozilla as their dir. (this should be very easy to correct in the source, though I have not seen it.) yes, I am aware that seamonkey is trying to be mozilla 1.8. alas, also look at the first few comments (eg #3 here). we are *not* calling this ebuild mozilla-1.8, *because* it is now seamonkey. it also was quite painful that, for many years, mozilla was .mozilla, but still used the .netscape dir. this is the time to cleanly separate the names. as to .mozilla, this could be cleanly copied to .seamonkey, if the first exists and the latter does not. (i.e., first time use.) then we should be able to use... /iaw
(In reply to comment #82) > I think the folks at seamonkey have made a mistake if they stuck to .mozilla as > their dir. (this should be very easy to correct in the source, though I have > not seen it.) > > yes, I am aware that seamonkey is trying to be mozilla 1.8. alas, also look at > the first few comments (eg #3 here). we are *not* calling this ebuild > mozilla-1.8, *because* it is now seamonkey. it also was quite painful that, > for many years, mozilla was .mozilla, but still used the .netscape dir. this > is the time to cleanly separate the names. > > as to .mozilla, this could be cleanly copied to .seamonkey, if the first exists > and the latter does not. (i.e., first time use.) This can be acieved by using --with-user-appdir=.seamonkey but as I've been told by a seamonkey-dev it was intended to keep .mozilla as dir for an easy transition from mozilla to seamonkey.
> This can be acieved by using --with-user-appdir=.seamonkey but as I've been > told by a seamonkey-dev it was intended to keep .mozilla as dir for an easy > transition from mozilla to seamonkey. > ok, now it really depends. we can make a full transition very easy by copying the .mozilla dir to .seamonkey, if .seamonkey does not exist. Done! Of course, it would indeed be nice if one could run both seamonkey and mozilla sharing the same definitions after installation, but if they both cannot run off the same .mozilla directory, then there is no point to keeping the .mozilla dir name for seamonkey. as soon as it hits the portage tree, I will try to install it on my end, too, and hopefully have some intelligent things to say.
I've added blocker for mozilla because seamonkey stoped working after i've emerged mozilla as dependency on some package. It has nothing to do with seamonkey using .mozilla or .seamonkey. As I recall it was using .seamonkey when i've added the blocker. I'm trying to find out now if they can coexist while seamonkey is build with my current ebuild. BTW Epiphany 1.8 has configure option --with-mozilla=seamonkey. I'm checking that also.
Well, both packages install files into /usr/bin and those files have the same names. This does not prevent both from working, but package emergeed later overwrites files from package emerged earlier. So having both is not good idea. I don't know how to do sloting in this conditions or if it is possible. Emergeing Epiphany using --with-mozilla=seamonkey (--with-gecko=seamonkey in Epiphany 1.9) gives errors about mozilla header. They does not see NSPR header. Compiling Seamonkey using --with-system-nspr gives error while compiling /security/nss/lib/utils I'm still working on those issues.
The problem with epiphany is that it seeks nspr headers in /usr/include/seamonkey-1.0/nspr not in /usr/lib/seamonkey/include/nspr
I just noticed that mplayerplug-in no longer builds either. That means the newer version or the one that I am currently using.
Created attachment 79768 [details, diff] seamonkey-pkgconfig.patch This patch solves problem with nspr headers. Epiphany 1.8 does not compile but Epiphany 1.9.6 does compile. Mplayerplug-in-3.21 does compile. The credits sould go to Gentoo developers because it is patch from Firefox ebuild patches. I just cut it to needed part and make it work for seamonkey.
Created attachment 79769 [details] seamonkey-1.0.ebuild Ebuild that uses new patch. Tarball http://rafal_glazar.w.interia.pl/seamonkey-1.0.tar.bz2 updated.
Obviously to compile epiphany and mplayerplug-in I used my hacked ebuilds not the portage ones.
My mozillaplug-in still works: I didn't even have to re-emerge it after installing Seamonkey (maybe that's it: the API didn't change drastically enough for me to need to re-emerge the plugin after emerging Seamonkey?), and it still works fine.
I never said that it doesn't work, it just doesn't build anymore. I'll try the latets hacked ebuild from Rafal, maybe it changes things and post my findings.
Created attachment 79823 [details] The emerge-log from emerge mplayerplug-in
The latest zip seems to fix it, thanks :).
Created attachment 79905 [details] seamonkey-1.0-r1.ebuild This is the biggest update of my ebuild hence the name is changed to seamonkey-1.0-r1.ebuild. Now it uses mozcoreconf and mozconfig-2 eclasses. I did apply three patches from firefox and those are: 008_firefox-gentoo-pkgconfig-1.patch, 021_firefox-1.5-system-nss.patch, 022_nss-with-system-nspr.patch. I had to change first patch a bit so I changed the name of the patch to seamonkey-gentoo-pkgconfig.patch. Applying those patches allow me to compile seamonkey using --with-system-nspr and --with-system-nss. I did apply another two patches: 002_firefox-1.5-visibility-check.patch and 003_firefox-1.5-visibility-fix.patch which I think might resolve compilation errors on AMD64 using GCC >= 3.4.5. I did remove old hack for this bug so I need reports if it work. If not than I will return to old way. I did remove enigmail from the ebuild so there is one question. I have to either hack portage enigmail ebuild to build for both thunderbird and seamonkey, or to make separate ebuild <seamonkey-enigmail-0.94.0.ebuild> just for seamonkey and leave portage enigmail as it is. I'm for the second option because it will be much easier to do. As for mozcoreconf.eclass it is almost like the portage one except I add .mozconfig initialization if ${PN} is seamonkey and make the flags --enable-single-profile --disable-profilesharing --disable-profilelocking apply only if ${PN} is not seamonkey because they break seamonkey build at current stage. If there is a patch that make those flags work please let me know. I also did update tarball. It contains now both ebuilds.
Created attachment 79906 [details] mozcoreconf.eclass
Created attachment 79907 [details, diff] 002_firefox-1.5-visibility-check.patch
Created attachment 79908 [details, diff] 003_firefox-1.5-visibility-fix.patch
Created attachment 79909 [details, diff] 021_firefox-1.5-system-nss.patch
Created attachment 79910 [details, diff] 022_nss-with-system-nspr.patch
Created attachment 79911 [details, diff] seamonkey-gentoo-pkgconfig.patch
I have everything done up and ready to be commit'd to the tree. I have made minor adjustments and have included alot more of the patches from firefox. Soon as I get agriffis to handle the mozilla-launcher bump I will get it added to the tree :)
I have commited it to the tree p.mask for 30 days for testing.
Hi Jory. I've seen that you include 008_firefox-gentoo-pkgconfig-1.patch into seamonkey-1.0-patches-0.1.tar.bz2. This is not good because although it will apply it won't work the correct way. It sets mozappdir variable to /usr/lib/mozilla-seamonkey but seamonkey is in /usr/lib/seamonkey so pkgconfig will not work as it should. You need to apply seamonkey-gentoo-pkgconfig.patch which set correct mozappdir. Another thing is that making separate seamonkey-enigmail ebuild is not as simple as I thought because seamonkey does not use extensions the way firefox and thunderbird does and to be honest I was thinking of giving up and returning enigmail back to seamonkey ebuild.
I have addressed the pkgconfig patch, also cleaned up some more issues as far as QA was concerned. I will add enigmail support when I do a -r1
Could someone apply the mozilla tab patch as well since seamonkey does not blank its tab if it is the last one opened. Moreover, even if hidelasttab is disabled in about:config, the tab bar will disappears if all tabs are closed. https://bugzilla.mozilla.org/show_bug.cgi?id=156082
After installing the latest version of mozilla-laucher(1.49) seamonkey still depends on 1.47. The ebuild should be altered to RDEPEND on >=1.47 instead of ~1.47. At least, that is what I think should be done since 1.49 is compatible with seamonkey.
launcher dep has been fixed.
The browser component segfaults on AMD64 after a few minutes of use. gcc 3.4.4 here. pbarros@neutrino4 ~ $ seamonkey No running windows found Starting calendar alarm service error creating table cal_calendars -- probably already exists error creating table cal_calendars_prefs -- probably already exists observer added /usr/libexec/mozilla-launcher: line 117: 25877 Falha de segmenta
The browser component segfaults on AMD64 after a few minutes of use. gcc 3.4.4 here. pbarros@neutrino4 ~ $ seamonkey No running windows found Starting calendar alarm service error creating table cal_calendars -- probably already exists error creating table cal_calendars_prefs -- probably already exists observer added /usr/libexec/mozilla-launcher: line 117: 25877 Falha de segmentação MOZ_NO_REMOTE=1 "$mozbin" "$@" seamonkey-bin exited with non-zero status (139) pbarros@neutrino4 ~ $ emerge --info Portage 2.1_pre6-r2 (default-linux/amd64/2006.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r7 x86_64) ================================================================= System uname: 2.6.15-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 ccache version 2.3 [enabled] dev-lang/python: 2.3.5-r2, 2.4.2-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -pipe -O2 -fweb -frename-registers" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib64/mozilla/defaults/pref /usr/share/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="-march=k8 -pipe -O2 -fweb -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://www.las.ic.unicamp.br/pub/gentoo/ ftp://ftp.las.ic.unicamp.br/pub/gentoo/" LANG="pt_BR.ISO8859-1" LC_ALL="pt_BR" LINGUAS="pt_BR" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X Xaw3d aac aalib accessibility acl acpi alsa apache2 arts artswrappersuid audiofile avi bash-completion berkdb bitmap-fonts blas bluetooth bonobo bzip2 cdparanoia cdr cli crypt cscope css ctype cups curl dba directfb doc dri dvd dvdr dvdread eds emacs emboss encode esd examples exif expat fastbuild fbcon ffmpeg flac font-server foomaticdb force-cgi-redirect fortran ftp gd gdbm gif gimpprint glut gmp gnome gnutls gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 java jikes jpeg jpeg2k junit kde kdeenablefinal lcms ldap leim lesstif libcaca lm_sensors lzo lzw lzw-tiff mad matroska memlimit mng motif mozcalendar mozilla mp3 mpeg mplayer musepack musicbrainz mysql nas ncurses network nls nptl nvidia ogg oggvorbis opengl pam pcre pda pdf pdflib perl plotutils png posix python qt quicktime readline real samba sdl session simplexml sms sndfile soap sockets speex spell spl ssl svg tcltk tcpd tetex theora threads tiff tokenizer truetype truetype-fonts type1-fonts usb vcd vorbis xchatdccserver xcomposite xemacs xine xml xml2 xmms xpm xsl xv xvid zeroconf zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_pt_BR userland_GNU video_cards_nvidia video_cards_fbdev video_cards_vesa video_cards_vga" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LDFLAGS
Having a seamonkey-bin ebuild will be nice also...
Is there any reason why seamonkey is blocked by www-client/mozilla but not by www-client/mozilla-bin ? I found this in seamonkey-1.0.2.ebuild but posted here in absence of a seamonkey 1.0.2 bug.
