We should allow the user to build mono without requiring mozilla specifically. Firefox is based on the same gecko ans is able to used as the Gecko SDK. The changes also require a change to the monodevelop launcher (replacement at http://dev.gentoo.org/~compnerd/files/monodevelop). There is a trivial change which needs to be applied to the ebuild. We need to add the 'firefox' useflag to the IUSE and change the depends to reflect this: - www-client/mozilla + firefox? ( >=www-client/mozilla-firefox-1.0.3 ) + !firefox? ( www-client/mozilla ) We must use the >=1.0.3 as that is the first version that packages the entire set of gecko libs.
Created attachment 65900 [details, diff] patch against configure.in to use {mozilla,firefox}-gtkmozembed.pc
Created attachment 65901 [details] modified ebuild for 0.7 version to use the patch
Created attachment 66912 [details] gecko-sharp-0.10.ebuild This ebuild will directly modify gtkmozembed/gecko-sharp.dll.config to ensure the correct run-time linking and allows to build gecko-sharp against firefox or mozilla. It needs the new masked ebuilds (mozilla or mozilla-firefox) to ensure the correct linking to the choosen libraries. It does not need any patches, only one simple sed to make the changes.
Can't the new ebuild be modified to allow 'mozilla-firefox-bin' as dependency too? I have it this in my local overlay and it compiles cleanly. Is there a way too detect whether a package or it's -bin variant is installed? greetings
AFAIK, the binary does not include all the needed files. Could you please provide a gziped output of 'equery -C files mozilla-firefox-bin'?
Created attachment 67337 [details] list of files in firefox-bin
Yah, just as I suspected. The binary version does not have all the necessary files. I am pretty sure that upstream does not include them, so its not something we can build against. However, the build requires a full Gecko SDK (which firefox from source provides, and the binary version does not and has no intention to ever do so). By supporting building against firefox, it is useful for those of us who use Firefox and do not wish to install the Mozilla suite. Remember, the prefered (and suggested) method is to actually use the Mozilla suite and not Firefox from source. Also, if you build against Firefox, we can not really support the build (and I believe that upstream will respond with the same argument), build it against the Mozilla suite and if the issue can be replicated, we will work with you to resolve the issue). PS. I do not mean to be rude, but we need to follow upstream and the dependencies which upstream uses to build this.
*** Bug 92868 has been marked as a duplicate of this bug. ***
Concerning the proposed patches, .config files with dllmappings should not have absolute paths like this. This is generally bad mojo, and should be avoided. We should keep the simple target='libgtkembedmoz.so' mapping, and let LDPATH and MOZILLA_FIVE_HOME settings handle the resolution of which lib to load. Currently mozilla installs the /etc/env.d/10mozilla file which should set everything properly for folks, and we can remove all of the checks for various things from the blam and monodevelop startup scripts. I've confirmed with compnerd that an equivalent file is installed by newer firefox installs. Changes to the configure.in for this will still be needed, so initial compilation will function. I want to verify a few more things concerning the whole mozilla/firefox/whatever stuff before going with this, as there have been quite a few changes on that front recently. Fret not, I've not forgotten this issue.
@#7: It's OK for me, I installed firefox from source now. But strangely gecko-sharp build fine with firefox-bin I had installed...
Another idea: Wouldn't it be helpful to add a "gecko-virtual"? Because firefox,mozilla,epiphany and AFAIK even more (thunderbird) bring the gecko-sdk.
When I build gecko-sharp with firefox (or firefox-bin) it builds fine. When I start monodevelop afterwards I get: which: no mozilla in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130:/opt/blackdown-jdk-1.4.2.02/bin:/opt/blackdown-jdk-1.4.2.02/jre/bin) Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory
(In reply to comment #9) > Concerning the proposed patches, .config files with dllmappings should not have > absolute paths like this. This is generally bad mojo, and should be avoided. > > We should keep the simple target='libgtkembedmoz.so' mapping, and let LDPATH and > MOZILLA_FIVE_HOME settings handle the resolution of which lib to load. Currently > mozilla installs the /etc/env.d/10mozilla file which should set everything > properly for folks, and we can remove all of the checks for various things from > the blam and monodevelop startup scripts. I've confirmed with compnerd that an > equivalent file is installed by newer firefox installs. > > Changes to the configure.in for this will still be needed, so initial > compilation will function. > > I want to verify a few more things concerning the whole mozilla/firefox/whatever > stuff before going with this, as there have been quite a few changes on that > front recently. > > Fret not, I've not forgotten this issue. The problem, if setting only the relative path, is as in bug #100597 and you will not have deterministic linking of this, which means only new bugs, that's why the full path is there with the intention to resolve to the libraries, which we have determined at compile time. And what if you don't have the 10mozilla-file, as i don't use it with the new changes? I experience the same problem with monodevelop, but it is simply a bug in monodevelop, because the monodoc starts happiliy without exporting anything, and even after exporting the mozilla-five-home the monodevelop would not start, because it could not find the gecko-sharp ?
So the problem with the monodevelop is resolved, (is there a tool like revdep-rebuild for mono?), I have had to rebuild some libraries (gtksourceview-sharp for example) to make it start and i think this not all the story because muine has some other problems ::(( So removing all the unneeded lines (checks and exports for mozilla and so on) in /usr/bin/monodevelop it starts without soiling the ld_path and exporting the mozilla-five-home just fine now.
It seems that more packages are using the gecko-sdk dependency, wouldn't it be wiser to depend on that? Asking the users to compile the Suite TWICE is plain stupid.
I think so too. Letting everything depend on gecko-sdk makes much more sense.
I don't know how that is so, but I don't have mozilla suit installed and still gecko-sharp is cleanly compiled and works (I just changed the dep on mozilla to mozilla-firefox). Is it supposed to work against firefox ?
Yes, it does build against mozilla-firefox as I do that as well. It wont build against mozilla-firefox-bin (atleast it shouldnt as the headers are not present in that version).
So is it possible to correct the ebuild with: || ( www-clients/mozilla www-clients/mozilla-firefox ) ?
you could not depend on gecko-sdk, it is simply so that gecko-sdk does not install gecko nor gtkmozembed. so it sth, which asks for bugs. the best solution is with hardcoding the path to the moz-libraries and remove from the monodevelop-script all the mozilla-related stuff, all the new mozilla/firefox version should be fine with this. it is the same technique, which is used in epiphany and galeon to link against firefox/mozilla-mess
As stated previously, hardcoding the library paths in the .config is *not* an acceptible solution to this. I've not bothered sinking more time into this personally, as several times the setting of MOZILLA_FIVE_HOME has changed (first there were env.d files to help programs out, then there weren't, etc), and it's made trying to sort through the mozilla mess a royal pain. I still firmly believe that mozilla is a *library/platform*, as well as a browser, and that firefox is a *browser* only. Until someone can definitively show me that the firefox folks have no plans on changing API/ABI with the mozilla/gtkembedmoz bits, I'm going to be incredibly hesitant to add this support. Even once someone does this, I'll need someone to get the following verified working (and no, i'm not joking, this is the *minimum* sanity check needed): 1) Install firefox -> install gecko-sharp -> install blam, monodevelop, beagle, and *all* other consumers of gecko-sharp -> verify things work for every app -> install mozilla -> verify again. 2) Install mozilla -> install gecko-sharp -> install blam, monodevelop, beagle, and *all* other consumers of gecko-sharp -> verify things work for every app -> install firefox -> verify again. 3) Use 'nm' to verify that *every* DllImport used in the gecko-sharp stuff is a valid symbol in the libgtkembedmoz.so provided by firefox. This is a hacky way to verify they've not messed with API/ABI. In reality things should be checked against the headers for it, that would be fine too. Before someone pulls the "Ubuntu does it" card (or if they already did and I forgot), they are a binary distro with much less complicated packaging requirements. I don't care if they do it or not, we need to make sure we aren't breaking things. Thanks all, hopefully this clears up what needs to happen if people want to see this added/resolved.
You should also test stuff against firefox 1.5 as this is just around the corner. The updated gtkmozembed in firefox 1.5 does include some behavioural differences (as well as bug fixes). I recently fixed beagle to work with FF 1.5 and ran into some strange problems along the way. Basically we were trying to render the initial content (a blank page) too early on, but this was causing all sorts of weirdness. Beagle definately works fine against 1.5 but other apps should be tested carefully.
(In reply to comment #21) > As stated previously, hardcoding the library paths in the .config is *not* an > acceptible solution to this. > well you could read bug #100597 and the mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=304655 > I've not bothered sinking more time into this personally, as several times the > setting of MOZILLA_FIVE_HOME has changed (first there were env.d files to help > programs out, then there weren't, etc), and it's made trying to sort through the > mozilla mess a royal pain. and this could answer why the env.d files are evil in this case > > I still firmly believe that mozilla is a *library/platform*, as well as a > browser, and that firefox is a *browser* only. Until someone can definitively > show me that the firefox folks have no plans on changing API/ABI with the > mozilla/gtkembedmoz bits, I'm going to be incredibly hesitant to add this support. > well mozilla is/will be shortly a deprecated platform and I don't see any difference between firefox and mozilla as a developer platform, it provides the same libs and headers > Even once someone does this, I'll need someone to get the following verified > working (and no, i'm not joking, this is the *minimum* sanity check needed): > > 1) Install firefox -> install gecko-sharp -> install blam, monodevelop, beagle, > and *all* other consumers of gecko-sharp -> verify things work for every app -> > install mozilla -> verify again. > > 2) Install mozilla -> install gecko-sharp -> install blam, monodevelop, beagle, > and *all* other consumers of gecko-sharp -> verify things work for every app -> > install firefox -> verify again. > > 3) Use 'nm' to verify that *every* DllImport used in the gecko-sharp stuff is a > valid symbol in the libgtkembedmoz.so provided by firefox. This is a hacky way > to verify they've not messed with API/ABI. In reality things should be checked > against the headers for it, that would be fine too. > well this is impossible, because there is no revdep-rebuild for mono and even epiphany/galeon will crash in this way, whithout rebuilding:) > Before someone pulls the "Ubuntu does it" card (or if they already did and I > forgot), they are a binary distro with much less complicated packaging > requirements. I don't care if they do it or not, we need to make sure we aren't > breaking things. > no it's not true ubuntu uses mozilla (at least 5.10 and this alas in very incorrect way, that's why there are mozilla/firefox-related-crashes every 5-10 min) > Thanks all, hopefully this clears up what needs to happen if people want to see > this added/resolved.
Any progress here? I don't want to install entire mozilla suite just because of gecko-sharp... :-(
I just came across monodevelop too - cool thing. But I'd like to avoid installing mozilla JUST for gecko-sharp and instead use the gtkmozembed.so from Firefox. Any news on this issue here?
The Mozilla suite has been discontinued, and I doubt upstream will mandate the Mozilla suite's unofficial successor SeaMonkey in its place when they finally get around to updating. The decision to allow gecko-sharp builds against gecko-sdk should now be a no-brainer if we've ruled out Firefox as a viable Gecko SDK.
actually, i think it should depend on net-libs/gecko-sdk.
The gecko-sharp-0.6 ebuild should also be revised to allow building against gecko-sdk. At least one current mono-related ebuild, mono-tools-0.1.11, has the dependency "<dev-dotnet/gecko-sharp-0.10".
(In reply to comment #28) > At least one current mono-related ebuild, mono-tools-0.1.11, Typo. That was meant to be mono-tools-1.1.11.
It would be nice to at least get a response from the dotnet herd on this recent development (the Mozilla suite being discontinued). Are you guys/gals still alive?
Absolutely nothing has changed since I last left a detailed description of what is required before this is even considered an option. Someone care to point me to links to the mozilla folks' rundown of their plan moving forward? (and not just anecdotal stuff, I'm curious about a real roadmap for what the 'sponsored source of gecko' will be in the future).
(In reply to comment #31) > Someone care to point me to links to the mozilla folks' rundown of their plan > moving forward? (and not just anecdotal stuff, I'm curious about a real roadmap > for what the 'sponsored source of gecko' will be in the future). The official method of developing against the Mozilla codebase has *always* been to pull source from Mozilla CVS: http://developer.mozilla.org/en/docs/Developing_Mozilla This is also the method prescribed in the definitive book on Mozilla development, Rapid Application Development with Mozilla. I assumed that this code is what the gecko-sdk ebuild provided. If not, then we probably need a mozilla-cvs ebuild.
That is for doing actual development on mozilla. That is *not* the same as what I wanted. I want information on the sponsored way to provide/package the gecko bits, what exact product's version of gecko is the supported/sanctioned one for distros, etc.
(In reply to comment #33) > That is for doing actual development on mozilla. That is *not* the same as what > I wanted. The nature of the Mozilla development is irrelevant. The officially prescribed method is currently the same for both developing on the Mozilla platform and for using Mozilla SDK components in your standalone application. Instructions on building the Gecko embedding components from the Mozilla source tree: http://developer.mozilla.org/en/docs/Roll_your_own_browser_-_An_embedding_HowTo > I want information on the sponsored way to provide/package the gecko > bits, what exact product's version of gecko is the supported/sanctioned one for > distros, etc. As early as Q3 2006 XULRunner could become the official embedding SDK provider on Linux. Though as you can see from their roadmap, a feature-complete XULRunner isn't due until 1Q 2007, so it could conceivably be that long before we see an API freeze on the embedding components. http://developer.mozilla.org/en/docs/Mozilla_Embedding_FAQ:Introduction_to_Gecko_and_Embedding#Is_there_an_SDK.3F http://developer.mozilla.org/en/docs/XULRunner:What_XULRunner_Provides http://wiki.mozilla.org/XULRunner:Roadmap
XULRunner is upstream's official recommendation for gtkmozembed. The maintainer: http://www.mozilla.org/owners.html#gtk-embedding-widget He says: http://benjamin.smedbergs.us/blog/2005-12-23/whats-coming-for-gtkmozembed/ The work is complete. gtkmozembed is now provided by XULRunner: https://bugzilla.mozilla.org/show_bug.cgi?id=299988 The Gecko issue is also being discussed here: http://bugs.gentoo.org/show_bug.cgi?id=120310
*** Bug 130693 has been marked as a duplicate of this bug. ***
*** Bug 129183 has been marked as a duplicate of this bug. ***
First to retrospect some, in fact I found out that no header-installation whatsoever is needed to compile the package - it does not regenerate the API-bindings in its current form, so any gecko-pkg in the tree should do, to build it, I'm not saying that it will work :) Second as I already said it is an error to not link to a specific gecko (aka absolute paths), it is similiar to the -Wl,-R switch passed to all the normal-packages, as this is the only solution to mozilla not versioning their libraries and it works quite well for all the pkgs in the tree. I will not comment any more on this, but this link http://www.mozilla.org/projects/security/known-vulnerabilities.html#Mozilla should bring more clarity to the thesis that "mozilla is the one and only developers platform".
This one is now a blocker guys, can you sort it out pretty quickly, it's holding up normal emerge update of packages as mozilla has now been ripped out of the tree in favour of seamonkey. I believe you have been made aware that this was going to happen for a few weeks now... http://bugs.gentoo.org/show_bug.cgi?id=137665
Hello? This bug blocks updates on every box that has monodevelop emerged, or just happens to have gecko-sharp. Can someone change it's severity to blocker? And to dotnet-herd - guys,please fix it ASAP...
(In reply to comment #40) > Hello? This bug blocks updates on every box that has monodevelop emerged, or > just happens to have gecko-sharp. Can someone change it's severity to blocker? > And to dotnet-herd - guys,please fix it ASAP... I'm not encouraged... seems the dotnet herd has lost interest. Further evidence: A user contributed an ebuild for MonoDevelop 0.11 on May 6 and even offered to help maintain it, yet the dotnet herd hasn't even bothered to respond, and the latest version in Portage remains 0.10: http://bugs.gentoo.org/show_bug.cgi?id=132457 Since April 7 users have contributed ebuilds for Mono 1.1.14, 1.1.15, and 1.1.16 (including libgdiplus 1.1.16), yet the dotnet herd hasn't even bothered to respond, and the latest version in Portage remains 1.1.13.8: http://bugs.gentoo.org/show_bug.cgi?id=129110 When ebuild contributions and offers to help are completely ignored for months, it's not a good sign.
Created attachment 91450 [details] ebuild for stable gecko-sharp using firefox instead of mozilla
Created attachment 91451 [details] ebuild for unstable gecko-sharp using firefox instead of mozilla
(In reply to comment #41) > (In reply to comment #40) > > Hello? This bug blocks updates on every box that has monodevelop emerged, or > > just happens to have gecko-sharp. Can someone change it's severity to blocker? > > And to dotnet-herd - guys,please fix it ASAP... > > I'm not encouraged... seems the dotnet herd has lost interest. Further > evidence: > > A user contributed an ebuild for MonoDevelop 0.11 on May 6 and even offered to > help maintain it, yet the dotnet herd hasn't even bothered to respond, and the > latest version in Portage remains 0.10: > http://bugs.gentoo.org/show_bug.cgi?id=132457 > > Since April 7 users have contributed ebuilds for Mono 1.1.14, 1.1.15, and > 1.1.16 (including libgdiplus 1.1.16), yet the dotnet herd hasn't even bothered > to respond, and the latest version in Portage remains 1.1.13.8: > http://bugs.gentoo.org/show_bug.cgi?id=129110 > > When ebuild contributions and offers to help are completely ignored for months, > it's not a good sign. > I am not sure if you noticed, but 1.1.14+ are not considered stable versions by upstream. In fact, monodevelop .10 isn't even considered stable. Developers do have other things that they have to deal with, it is an unfortunate occurance, but don't be discouraged. We DO notice, it is simply a matter of having the time available. - and please note that I am not in the dotnet herd.
(In reply to comment #44) > I am not sure if you noticed, but 1.1.14+ are not considered stable versions by > upstream. In fact, monodevelop .10 isn't even considered stable. Developers > do have other things that they have to deal with, it is an unfortunate > occurance, but don't be discouraged. We DO notice, it is simply a matter of > having the time available. - and please note that I am not in the dotnet herd. If MonoDevelop 0.11 isn't considered stable enough for inclusion in Portage (MonoDevelop 0.10 is just as crashy as 0.11 yet it's in Portage), all the dotnet herd has to do is drop a little comment on that bug so the users won't remain in the dark on its status, but this hasn't been done. For over *two months*. And putting aside the question of whether "unstable" Mono releases should be in Portage (it's debatable), when users are actively contributing version bump ebuilds the very *least* the affected herd could do is pop in every once in a while to offer guidance on the ebuild or inform users of the herd's stance on the versions in question. I understand devs are busy and have other things to do, but if a group of devs can't find the time to drop in to comment on contributed ebuilds for *months* then there's a user relations problem. If they're otherwise engaged for that long, they should add themselves to the devaway list [1] (which incidentally lists none of the dotnet herd members currently). If they need more help, they should be actively recruiting (I don't see any pleas for help on the lists or the Staffing Needs page [2]). [1] http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml [2] http://www.gentoo.org/proj/en/devrel/staffing-needs/
I'm gonna open a bug request to move the whole tree to xulrunner as it seems that every developer in gentoo has some sort of preferences, moving for example gecko-sharp to seamonkey is officially unsupported by the mozilla foundation for example, as seamonkey is not an official mozilla-browser, there are only two sanctioned platforms (and soon probably to be only one) - firefox and xulrunner (firefox will be built on top of xulrunner very soon) so it is your choice here to move to what you want. Not to forget the future mozilla-maintener, who in the next iteration (firefox on xulrunner) should explain again to every developer and user of some sort of mozilla embedding, why they could not use the fancy use-flags anymore and why they should be masked. So have fun...
Alex and others: About this bug in particular: Since the seamonkey push, I've been talking to dsd_ on IRC and started working on trying to address this *again*, but as others have stated, the whole mozilla thing is a *mess*, and TBH, I hate wasting time on this when everything just changes 3 months down the line. In general: One man is more than enough to handle most the mono related bugs, but the past couple months I've been distracted with things like $50M lawsuits at work, etc. Regardless, the mono-1.1.14, etc items had previously been discouraged in favor of the mono-1.1.13.x series. Just this week, I finally pinned down Miguel, and he said that 1.1.16 was good for folks to start shipping... so lo and behold, that went into portage today. You have a point about my lack of user relations, I will try to respond to bugs more timely. Typically, I try to put my current limited time to actual bug fixing work, and less spending lots of time responding to bugs. I'll try to be better about responding to things, superfluous or not.
(In reply to comment #47) > You have a point about my lack of user relations, I will try to respond to bugs > more timely. Typically, I try to put my current limited time to actual bug > fixing work, and less spending lots of time responding to bugs. I'll try to be > better about responding to things, superfluous or not. Thanks for letting us know what's up Peter. Keeping the dev <--> user communication going is the most important thing for Gentoo because when there's silence for a significant span of time (weeks, months) we users start getting funny (and sometimes wrong) ideas, and that just ends up agitating both parties. Having said that, I agree it'd be a waste of your time and energy to respond to every single bid for your attention from users. IMO what deserves the highest communication is user-contributed ebuilds and migration/blocker issues like the present gecko-sharp problem. Also, when someone asks how they can help please do your best to advise them where you think their efforts are best spent (and yeah, some users should just go "fly a kite"... I'm not sure how that should be handled though :).
(In reply to comment #47) > Alex and others: > > About this bug in particular: Since the seamonkey push, I've been talking to > dsd_ on IRC and started working on trying to address this *again*, but as > others have stated, the whole mozilla thing is a *mess*, and TBH, I hate > wasting time on this when everything just changes 3 months down the line. > > In general: > > One man is more than enough to handle most the mono related bugs, but the past > couple months I've been distracted with things like $50M lawsuits at work, etc. > Regardless, the mono-1.1.14, etc items had previously been discouraged in favor > of the mono-1.1.13.x series. Just this week, I finally pinned down Miguel, and > he said that 1.1.16 was good for folks to start shipping... so lo and behold, > that went into portage today. > > You have a point about my lack of user relations, I will try to respond to bugs > more timely. Typically, I try to put my current limited time to actual bug > fixing work, and less spending lots of time responding to bugs. I'll try to be > better about responding to things, superfluous or not. > You really make me laugh and cry at the same time. If you need an year to address this bug, you should probably reconsider your gentoo-position. Even using the compnerd-submitted patches should be enough for you to move along, not to speak that your pkgs are *mess* as you should change monodevelop, in order for it to work with the ported gecko-sharp, don't you think? As to the officially using mozilla, suse uses xulrunner since december 2005. Just much FUD, here move along people.
(In reply to comment #49) > As to the officially using mozilla, suse uses xulrunner since december 2005. Interesting if true. Peter, do you have any inside contacts at work that might be able to give you the lowdown on their decision to go with XULRunner?
cat gecko-sharp2.spec # # spec file for package gecko-sharp2 (Version 0.11) # # Copyright (c) 2006 SUSE LINUX Products GmbH, Nuernberg, Germany. # This file and all modifications and additions to the pristine # package are under the same license as the package itself. # # Please submit bugfixes or comments via http://bugs.opensuse.org/ # # norootforbuild # usedforbuild Mesa Mesa-devel aaa_base acl atk atk-devel attr audit-libs autoconf automake bash bind-libs bind-utils binutils bison bzip2 cairo cairo-devel coreutils cpio cpp cracklib cvs cyrus-sasl db diffutils e2fsprogs expat file filesystem fillup findutils flex fontconfig fontconfig-devel freetype2 freetype2-devel gawk gcc gdbm gdbm-devel gettext gettext-devel giflib glib-sharp2 glib2 glib2-devel glibc glibc-devel glibc-locale glitz glitz-devel gnome-filesystem gpm grep groff gtk-sharp2 gtk-sharp2-gapi gtk2 gtk2-devel gzip info insserv klogd less libacl libattr libcom_err libdrm libgcc libgdiplus libjpeg libltdl libnscd libpng libpng-devel libstdc++ libtiff libtool libvolume_id libxcrypt libxml2 libzio m4 make man mktemp module-init-tools mono-core mono-data mono-devel mono-nunit mono-tools mono-web mono-winforms monodoc-core ncurses ncurses-devel net-tools netcfg openldap2-client openmotif-libs openssl pam pam-modules pango pango-devel patch perl perl-XML-LibXML perl-XML-LibXML-Common perl-XML-NamespaceSupport perl-XML-SAX permissions pkgconfig popt procinfo procps psmisc pwdutils rcs readline rpm sed strace sysvinit tar tcpd texinfo timezone unzip util-linux vim xorg-x11-devel xorg-x11-libs zlib zlib-devel Name: gecko-sharp2 BuildRequires: glib-sharp2 gtk-sharp2 gtk-sharp2-gapi gtk2-devel mono-tools Version: 0.11 Release: 22 License: MPL, LGPL BuildArch: noarch URL: www.monodevelop.com Source0: gecko-sharp-2.0-%{version}.tar.gz Summary: Gecko bindings for Mono Group: Development/Libraries/Other %if %suse_version > 1010 Requires: mozilla-xulrunner180 %else Requires: mozilla-xulrunner %endif Provides: gecko-sharp-2_0 Obsoletes: gecko-sharp-2_0 BuildRoot: %{_tmppath}/%{name}-%{version}-build AutoReqprov: on %description This package provides Mono bindings for the Gecko engine, through an easy-to-use widget that will allow you to embed a Mozilla browser window into your Gtk# application. Authors: -------- John Luke <jluke@cfl.rr.com> Mark Crichton <crichton@gimp.org> Mike Kestner <mkestner@ximian.com> Todd Berman <tberman@sevenl.net> Geoff Norton <gnorton@customerdna.com> Raja R Harinath <rharinath@novell.com> Zac Bowling <zac@zacbowling.com> Christian Hergert <christian.hergert@gmail.com> Alp Toker <alp@atoker.com> Ben Maurer <bmaurer@ximian.com> %debug_package %prep %setup -q -n gecko-sharp-2.0-%{version} %build ./configure --prefix=/usr --libdir=/usr/lib --sysconfdir=/etc --mandir=/usr/share/man --infodir=/usr/share/info --localstatedir=/var %install make install DESTDIR=%{buildroot} mkdir -p $RPM_BUILD_ROOT/usr/share/pkgconfig mv $RPM_BUILD_ROOT/usr/lib/pkgconfig/* $RPM_BUILD_ROOT/usr/share/pkgconfig %clean rm -rf "%{buildroot}" %files %defattr(-, root, root) /usr/lib/mono/gecko-sharp-2.0 /usr/lib/mono/gac/gecko-sharp /usr/lib/monodoc/sources/* /usr/share/pkgconfig/*.pc %changelog -n gecko-sharp2 * Fri Jul 07 2006 - lrupp@suse.de - Requires mozilla-xulrunner180 for %%suse_version > 1010 * Wed Jan 25 2006 - mls@suse.de - converted neededforbuild to BuildRequires * Fri Jan 13 2006 - gekker@suse.de - Fixup nfb and Requires for new gtk-sharp2 packaging * Fri Dec 09 2005 - wberrier@suse.de - Replace mozilla dep with mozilla-xulrunner, clean up deps, and add documentation * Fri Oct 21 2005 - ro@suse.de - rename package, provide and obsolete old name * Sat Oct 08 2005 - wberrier@suse.de - Update to 0.11 * Mon Aug 15 2005 - ro@suse.de - added check-build.sh * Tue Aug 09 2005 - lnussel@suse.de - use buildroot and build as user * Mon Aug 08 2005 - ro@suse.de - fix location of pkgconfig file * Mon Aug 08 2005 - ro@suse.de - rename package to gecko-sharp-2_0 (no "." allowed in name) * Thu Aug 04 2005 - wberrier@suse.de - Initial package Do you think that I'm spreading the FUD here :) Just because someone has g.o in his e-mail does not automatically mean that he understands, what he is talking about, and of course the other way round.
Gergan: I can only hope that you were trying to joke here, and not just be insulting to me. Having previously glossed over the details (calling firefox and mozilla no different as a platform, *immediately* after Daniel points out several bugs related to using firefox vs. mozilla as the gtkmozembed provider), and now suggesting a partial solution as something we should just shove into portage, I don't know what to think. Also, I'd appreciate it if you would not make claims about me spreading FUD without backing them up, and call the packages I maintain a 'mess'. The part that you *do* have right, is that the @gentoo.org address doesn't mean a thing. Ultimately, we are all just individuals trying to use/improve Gentoo the best we can. Please don't get in the way of that through accusing me of spreading FUD, and asking me to 'reconsider your gentoo-position' because a complicated bug has remained open for a year. Alex: I will try to ask a few folks Monday when I'm back near the interweb again.
I still stay by what - I have said that, the gecko used is the same, try this with xulrunner, seamonkey and firefox and you will see that this bug exists everywhere, showing that you don't understand what you are talking about. Yes it does not exist in mozilla, as it *uses* a different generation of gecko, at the time when I said this the stable releases were probably mozilla, firefox-1.0.x and so on meaning that there was no difference. And I stay by my saying that your pkgs are a mess, as you need to change the monodevelop-script in order for monodevelop to work with gecko-sharp "compiled" against seamonkey, huh is this better than absolute paths - no, it is just a *mess*. And if you need a week to find a patch about this bug, then there is something amiss with your skill, and I have posted the links to the bugs and patches - no one cares to apply them. And on the side note they were for firefox (probably that's why you are eager to apply them :lol: ), showing that the gecko used is the same once more. So stop the FUD and fix the stable-tree, which is broken because of this behaviour of yours for some time now.
FYI http://bugs.gentoo.org/show_bug.cgi?id=118941 if still don't believe me.
still more evidences of your mess needed - now looking at your monodevelop-0.10 ebuild : inherit mono eutils fdo-mime DESCRIPTION="Free .NET development environment" SRC_URI="http://www.go-mono.com/sources/${PN}/${P}.tar.gz" HOMEPAGE="http://monodevelop.com/" LICENSE="GPL-2" IUSE="boo java" DEPEND=">=dev-dotnet/gtksourceview-sharp-0.10 >=dev-dotnet/gecko-sharp-0.10 >=dev-lang/mono-1.1.10 >=dev-util/monodoc-1.0 >=dev-dotnet/gtk-sharp-2.4.0 >=dev-dotnet/gnomevfs-sharp-2.4.0 >=dev-dotnet/gnome-sharp-2.4.0 >=dev-dotnet/gconf-sharp-2.4.0 >=dev-dotnet/gtkhtml-sharp-2.4.0 >=dev-dotnet/glade-sharp-2.4.0 >=dev-dotnet/vte-sharp-2.4.0 boo? ( >=dev-lang/boo-0.7.5 ) java? ( || ( >=dev-dotnet/ikvm-bin-0.14 >=dev-dotnet/ikvm-0.14.0.1-r1 ) )" KEYWORDS="~amd64 ~ppc ~x86" SLOT="0" no rdepends adding sth ? looking in mono.eclass: # >=mono-0.92 versions using mcs -pkg:foo-sharp require shared memory, so we set the # shared dir to ${T} so that ${T}/.wapi can be used during the install process. export MONO_SHARED_DIR=${T} hm I don't see any rdepend on mozilla (or anything gecko-related, if this matters) only the gecko-sharp one. now looking at /usr/bin/monodevelop --snip-- if test -n "$MOZILLA_FIVE_HOME"; then MOZILLA_HOME=$MOZILLA_FIVE_HOME elif [ -f /chrome/comm.jar ]; then MOZILLA_HOME= elif [ $(which mozilla) ] && grep MOZILLA_FIVE_HOME= "$(which mozilla)" > /dev/null ; then MOZILLA_HOME=$(grep MOZILLA_FIVE_HOME= $(which mozilla) | cut -d '"' -f 2) elif [ $(which firefox) ] && grep MOZILLA_FIVE_HOME= "$(which firefox)" > /dev/null ; then MOZILLA_HOME=$(grep MOZILLA_FIVE_HOME= $(which firefox) | cut -d '"' -f 2) else echo "Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to your mozilla directory" exit 1 fi MD_BIN_PATH=/usr/lib/monodevelop/bin if [ -n $LD_LIBRARY_PATH ]; then export LD_LIBRARY_PATH=$MOZILLA_HOME:$LD_LIBRARY_PATH else export LD_LIBRARY_PATH=$MOZILLA_HOME fi --snip-- hm strange very strange first it seems, that it could use firefox, also it seems from the original script, that it rdepends on mozilla (or firefox :lol: ) hm... now this is strange first the script is buggy, as it should be changed every time you use different gecko - just making the idea of using external libraries, which abstract some api nearly "*obsolete*", the second thing is that the ebuild is buggy as it does not know anything about this rdepend and still uses it in the start-script. do you still want to see more or are you now contented with my explanations?
Gergan, being a dick about this is a great way to get a developer to ignore your comments and this bug entirely. We're all volunteers here, and we do things that we _want_ to do because there's always more than enough to work on.
(In reply to comment #56) > Gergan, being a dick about this is a great way to get a developer to ignore > your comments and this bug entirely. We're all volunteers here, and we do > things that we _want_ to do because there's always more than enough to work on. > A developer being a *hard* "dick" all this year and showing that he in incapable of being one - made me dick?
(In reply to comment #56) > Gergan, being a dick about this is a great way to get a developer to ignore > your comments and this bug entirely. We're all volunteers here, and we do > things that we _want_ to do because there's always more than enough to work on. > And one more thing and I'll be also ignoring this bug, it is not what he _wants_, not anymore. He is breaking the stable tree, he is breaking security policies - http://bugs.gentoo.org/show_bug.cgi?id=137665 So it is not about _my_way_ or _his_way_ anymore, it is about the gentoo policies and about choice and wide support: seamonkey - KEYWORDS="alpha amd64 hppa ppc ~ppc64 x86 ~x86-fbsd" firefox - KEYWORDS="-* arm amd64 hppa ~ia64 ppc sparc x86 ~x86-fbsd" so 1 < 2 don't you think I don't see why the devs are supporting him, as it was clearly shown that either he can't tackle this problem or is stubborn enough to not to want to resolve it. I would also not be sendig this to user-rel, as I don't see any sense in this, as the devs do not show any flexibility and are only breaking their own policies, moving in circles.
Erm...I'm not sure exactly when this occurred but replacing the 'mozilla' USE flag in make.conf with 'firefox' removes the blockage. gecko-sharp just compiled without complaint for me with this change, and my emerge -uD world is only complaining about a heimdal/mit-krb5 conflict now.
(In reply to comment #59) > Erm...I'm not sure exactly when this occurred but replacing the 'mozilla' USE > flag in make.conf with 'firefox' removes the blockage. gecko-sharp just > compiled without complaint for me with this change, and my emerge -uD world is > only complaining about a heimdal/mit-krb5 conflict now. If you installed an unmodified gecko-sharp-0.11 from Portage on your system, I don't see how that's possible unless you had Mozilla installed at the time. gecko-sharp-0.11 doesn't have any USE flags, and it has a hard dependency (both build-time and runtime) on www-client/mozilla.
(In reply to comment #60) It does require that mozilla be installed, but removing the mozilla USE flag somehow removed the blockage - my system and world updates are working fine now, where before portage was complaining about a circular blockage between mozilla and seamonkey.
Please fix this bug. It has been preventing me from updating world for too long. (Without reading all 61 comments) I don't see any problem. In fact the only problem I see is that Seamonkey has replaced Mozilla so it should have been fixed and this discussion should be irrelavant.
(In reply to comment #62) > Please fix this bug. It has been preventing me from updating world for too > long. (Without reading all 61 comments) I don't see any problem. In fact the > only problem I see is that Seamonkey has replaced Mozilla so it should have > been fixed and this discussion should be irrelavant. > Agreed. The simple answer i've gone for instead of waiting for the maintainer who is pissing about not fixing things is to either -C seamonkey and mask it off, leaving packages to default to mozilla. Some won't, not a good idea. Or merge mozilla -O1 . This appears to work actually, although I'm sure portage will whine at update time. Or, using ebuild /path/to/ebuild.ebuild compile && ebuild /path/to/ebuild.ebuild install This won't merge it into portage's database, and you might be able to get away with it.
Ergh, sorry for the spam, forget to mention that you'll have to move everything out of the sandbox after the ebuild install phase.
please fix this... it's very very bad everytime I run a emerge --sync, had to edit gecko-sharp ebuild and s/firefox/seamonkey/ and ebuild digest... can't this be transformed in a flag??
Please do something about this, it's extremely annoying!!
I'll take care of that. There are some things left to do in those submitted ebuilds (thank you all who contributed to that bug). I'll let you know when I'm done.
And now latest mono-tools are fixed to build against seamonkey... Except with seamonkey USE flag, it depends on gecko-sharp, which still wants mozilla! I hope gecko-sharp will not be "fixed" to use firefox if one wants to have seamonkey support
Ok folks, long overdue I know, but monodevelop, mono-tools, blam, and gecko-sharp should all be jiving with either firefox or seamonkey now. Can everyone please emerge --sync in a couple hours, and test everything for me? If everything jives, I need to get blam stabalized (bug #153308) and then I can remove all the offending packages that dep on mozilla (the old blam versions, and the old gecko-sharp releases). Thanks for the patience everyone, please let me know if anyone hits any problems. Thanks!
Peter, blam-1.8.2-r2 still depends on gecko-sharp-0.6 which depends on mozilla. Sorry if you already know...
(In reply to comment #69) > Ok folks, long overdue I know, but monodevelop, mono-tools, blam, and > gecko-sharp should all be jiving with either firefox or seamonkey now. > > Can everyone please emerge --sync in a couple hours, and test everything for > me? If everything jives, I need to get blam stabalized (bug #153308) and then I > can remove all the offending packages that dep on mozilla (the old blam > versions, and the old gecko-sharp releases). > > Thanks for the patience everyone, please let me know if anyone hits any > problems. Thanks! > I have tested things out with what I presume are the ebuilds you are referring to and I get an error importing System.Xml.XmlElement Not sure how relevant it is but it may be an actual bug. I still get "no mozilla in path" complaints though too, so I may not have the fixed version yet. Will attach bug trace below
Created attachment 100750 [details] Stacktrace for failure on opening monodevelop-0.12
Created attachment 100753 [details] Stacktrace for failure opening monodevelop-0.12 Turns out I had not been syncd properly. My "emerge -pv mono gecko-sharp mono-tools monodevelop" details are shown below the stack trace. It looks like it fails on the dialog when it tries to load the MonoDevelop.XmlEditor On another note, I have a feeling my system has not been entirely recompiled since I updated to glibc-2.4, as there are references in the stack trace to 2.3 so my problems may not be universal. Will do an "emerge -e world" in the next few days to see if it helps.
The following two posts say something about XMLEditor not working with a certain version of Mono. Is it possible that the bug I posted is the same one? http://lists.ximian.com/pipermail/monodevelop-list/2006-August/004402.html http://lists.ximian.com/pipermail/monodevelop-list/2006-August/004403.html
(In reply to comment #74) > The following two posts say something about XMLEditor not working with a > certain version of Mono. Is it possible that the bug I posted is the same one? > > http://lists.ximian.com/pipermail/monodevelop-list/2006-August/004402.html > > http://lists.ximian.com/pipermail/monodevelop-list/2006-August/004403.html > I fixed my problem by opening monodevelop as root, and then installing the extension upgrade for XML Editor from Tools->Add-in Manager->Install Add-ins . Now I just get the warning about "which: no mozilla in ... " but it actually starts up now.
I noticed that the new ebuild dev-dotnet/gecko-sharp-0.11-r1 now can build over firefox instead of mozilla. But every program that use this lib need to find gtkmozembed.so that isn't in the LD_PATH, so I think that we need a solution like the ebuild in attachment http://bugs.gentoo.org/attachment.cgi?id=91451 /use an absolute path) or to add on /etc/env.d a file called ??mozembed that will look like this: --------- LD_PATH=/usr/lib/mozilla-firefox --------- and if necessary this file can be managed by eselect to allow user to change the mozilla product to use.
Fixed in 0.11-r1; everything else -> file a new bug please. This is already messy enough.