Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 98839 - Build gecko-sharp against firefox to allow building mono{,develop} without mozilla
Summary: Build gecko-sharp against firefox to allow building mono{,develop} without mo...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: dotnet project
URL: http://go-mono.com
Whiteboard:
Keywords:
: 92868 129183 130693 (view as bug list)
Depends on:
Blocks: 137665 153308
  Show dependency tree
 
Reported: 2005-07-12 19:39 UTC by Saleem Abdulrasool (RETIRED)
Modified: 2007-01-01 15:47 UTC (History)
23 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch against configure.in to use {mozilla,firefox}-gtkmozembed.pc (gecko-sharp-pkgconfig.patch,1.07 KB, patch)
2005-08-14 02:37 UTC, Grzegorz Artur Daszuta
Details | Diff
modified ebuild for 0.7 version to use the patch (gecko-sharp-0.7-r2.ebuild,1.39 KB, text/plain)
2005-08-14 02:38 UTC, Grzegorz Artur Daszuta
Details
gecko-sharp-0.10.ebuild (gecko-sharp-0.10.ebuild,1.52 KB, text/plain)
2005-08-26 06:14 UTC, Gergan Penkov
Details
list of files in firefox-bin (firefox-bin-files.txt.gz,3.20 KB, application/octet-stream)
2005-08-31 04:20 UTC, Fabian Zeindl
Details
ebuild for stable gecko-sharp using firefox instead of mozilla (gecko-sharp-0.6.ebuild,1.66 KB, text/plain)
2006-07-11 05:02 UTC, skolima
Details
ebuild for unstable gecko-sharp using firefox instead of mozilla (gecko-sharp-0.11.ebuild,1.55 KB, text/plain)
2006-07-11 05:02 UTC, skolima
Details
Stacktrace for failure on opening monodevelop-0.12 (monodevelop-stacktrace.txt,2.69 KB, text/plain)
2006-10-29 16:16 UTC, Peter Ansell
Details
Stacktrace for failure opening monodevelop-0.12 (monodevelop-stacktrace2.txt,8.86 KB, text/plain)
2006-10-29 18:11 UTC, Peter Ansell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Saleem Abdulrasool (RETIRED) gentoo-dev 2005-07-12 19:39:19 UTC
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.
Comment 1 Grzegorz Artur Daszuta 2005-08-14 02:37:08 UTC
Created attachment 65900 [details, diff]
patch against configure.in to use {mozilla,firefox}-gtkmozembed.pc
Comment 2 Grzegorz Artur Daszuta 2005-08-14 02:38:16 UTC
Created attachment 65901 [details]
modified ebuild for 0.7 version to use the patch
Comment 3 Gergan Penkov 2005-08-26 06:14:21 UTC
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.
Comment 4 Fabian Zeindl 2005-08-30 02:39:17 UTC
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
Comment 5 Saleem Abdulrasool (RETIRED) gentoo-dev 2005-08-30 14:30:15 UTC
AFAIK, the binary does not include all the needed files.  Could you please
provide a gziped output of 'equery -C files mozilla-firefox-bin'?
Comment 6 Fabian Zeindl 2005-08-31 04:20:12 UTC
Created attachment 67337 [details]
list of files in firefox-bin
Comment 7 Saleem Abdulrasool (RETIRED) gentoo-dev 2005-08-31 14:56:11 UTC
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.
Comment 8 Peter Johanson (RETIRED) gentoo-dev 2005-08-31 19:25:53 UTC
*** Bug 92868 has been marked as a duplicate of this bug. ***
Comment 9 Peter Johanson (RETIRED) gentoo-dev 2005-08-31 19:51:52 UTC
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.
Comment 10 Fabian Zeindl 2005-09-01 01:02:33 UTC
@#7:  It's OK for me, I installed firefox from source now. But strangely
gecko-sharp build fine with firefox-bin I had installed...
Comment 11 Fabian Zeindl 2005-09-03 07:11:38 UTC
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.
Comment 12 Fabian Zeindl 2005-09-04 06:16:02 UTC
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
Comment 13 Gergan Penkov 2005-09-08 12:26:49 UTC
(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 ?
Comment 14 Gergan Penkov 2005-09-08 14:49:06 UTC
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.
Comment 15 Yaron Tausky 2005-11-13 12:47:22 UTC
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.
Comment 16 Fabian Zeindl 2005-11-14 04:12:22 UTC
I think so too. Letting everything depend on gecko-sdk makes much more sense.
Comment 17 gad.kadosh 2005-11-22 13:03:09 UTC
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 ?
Comment 18 Saleem Abdulrasool (RETIRED) gentoo-dev 2005-11-23 09:36:16 UTC
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).
Comment 19 gad.kadosh 2005-11-23 10:47:03 UTC
So is it possible to correct the ebuild with:

|| ( www-clients/mozilla
     www-clients/mozilla-firefox  )

?
Comment 20 Gergan Penkov 2005-11-27 12:31:07 UTC
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
Comment 21 Peter Johanson (RETIRED) gentoo-dev 2005-11-27 12:51:42 UTC
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.
Comment 22 Daniel Drake (RETIRED) gentoo-dev 2005-11-27 13:42:36 UTC
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.
Comment 23 Gergan Penkov 2005-11-29 21:29:06 UTC
(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.

Comment 24 Radek Podgorny 2006-02-19 12:38:34 UTC
Any progress here? I don't want to install entire mozilla suite just because of gecko-sharp... :-(
Comment 25 Ernst Rohlicek 2006-02-28 11:29:39 UTC
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?
Comment 26 Alex Tarkovsky 2006-03-07 06:17:10 UTC
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.
Comment 27 Victor Tseng 2006-03-09 08:52:28 UTC
actually, i think it should depend on net-libs/gecko-sdk.
Comment 28 Alex Tarkovsky 2006-03-09 15:24:51 UTC
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".
Comment 29 Alex Tarkovsky 2006-03-09 16:01:27 UTC
(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.
Comment 30 Alex Tarkovsky 2006-03-13 11:52:53 UTC
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?
Comment 31 Peter Johanson (RETIRED) gentoo-dev 2006-03-13 11:58:30 UTC
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).
Comment 32 Alex Tarkovsky 2006-03-13 12:26:20 UTC
(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.
Comment 33 Peter Johanson (RETIRED) gentoo-dev 2006-03-13 14:07:49 UTC
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.
Comment 34 Alex Tarkovsky 2006-03-13 14:47:47 UTC
(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
Comment 35 Alex Tarkovsky 2006-04-15 11:46:34 UTC
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
Comment 36 Jakub Moc (RETIRED) gentoo-dev 2006-04-21 00:00:00 UTC
*** Bug 130693 has been marked as a duplicate of this bug. ***
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2006-04-21 00:00:40 UTC
*** Bug 129183 has been marked as a duplicate of this bug. ***
Comment 38 Gergan Penkov 2006-06-22 12:29:53 UTC
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".
Comment 39 Steve Carr 2006-07-07 00:49:49 UTC
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
Comment 40 skolima 2006-07-10 07:33:22 UTC
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...
Comment 41 Alex Tarkovsky 2006-07-10 23:28:07 UTC
(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.
Comment 42 skolima 2006-07-11 05:02:27 UTC
Created attachment 91450 [details]
ebuild for stable gecko-sharp using firefox instead of mozilla
Comment 43 skolima 2006-07-11 05:02:53 UTC
Created attachment 91451 [details]
ebuild for unstable gecko-sharp using firefox instead of mozilla
Comment 44 Steev Klimaszewski (RETIRED) gentoo-dev 2006-07-11 06:01:16 UTC
(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.
Comment 45 Alex Tarkovsky 2006-07-11 09:43:51 UTC
(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/
Comment 46 Gergan Penkov 2006-07-12 13:28:06 UTC
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...
Comment 47 Peter Johanson (RETIRED) gentoo-dev 2006-07-12 14:05:49 UTC
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.
Comment 48 Alex Tarkovsky 2006-07-12 15:16:19 UTC
(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 :).
Comment 49 Gergan Penkov 2006-07-14 02:24:29 UTC
(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.
Comment 50 Alex Tarkovsky 2006-07-14 04:07:02 UTC
(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?
Comment 51 Gergan Penkov 2006-07-14 13:23:13 UTC
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.
Comment 52 Peter Johanson (RETIRED) gentoo-dev 2006-07-15 05:13:35 UTC
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.
Comment 53 Gergan Penkov 2006-07-15 05:39:41 UTC
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.
Comment 54 Gergan Penkov 2006-07-15 05:46:36 UTC
FYI http://bugs.gentoo.org/show_bug.cgi?id=118941 if still don't believe me.
Comment 55 Gergan Penkov 2006-07-15 08:03:20 UTC
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?
Comment 56 Donnie Berkholz (RETIRED) gentoo-dev 2006-07-16 00:34:16 UTC
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.
Comment 57 Gergan Penkov 2006-07-16 02:33:27 UTC
(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? 
Comment 58 Gergan Penkov 2006-07-16 05:49:27 UTC
(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.
Comment 59 William Keaney 2006-07-16 15:25:50 UTC
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.
Comment 60 Alex Tarkovsky 2006-07-27 09:01:53 UTC
(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.
Comment 61 William Keaney 2006-07-27 10:11:59 UTC
(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.
Comment 62 George Jenkins 2006-07-28 15:58:46 UTC
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.
Comment 63 James Laver 2006-07-31 06:27:02 UTC
(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.
Comment 64 James Laver 2006-07-31 06:31:32 UTC
Ergh, sorry for the spam, forget to mention that you'll have to move everything out of the sandbox after the ebuild install phase.
Comment 65 Ruben Fonseca 2006-07-31 11:39:24 UTC
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??
Comment 66 kenjiru 2006-10-13 02:04:42 UTC
Please do something about this, it's extremely annoying!!
Comment 67 Jurek Bartuszek (RETIRED) gentoo-dev 2006-10-22 08:48:00 UTC
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.
Comment 68 Bernard Cafarelli gentoo-dev 2006-10-29 07:52:53 UTC
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
Comment 69 Peter Johanson (RETIRED) gentoo-dev 2006-10-29 09:10:33 UTC
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!
Comment 70 Akos Ladanyi 2006-10-29 11:44:21 UTC
Peter, blam-1.8.2-r2 still depends on gecko-sharp-0.6 which depends on mozilla. Sorry if you already know...
Comment 71 Peter Ansell 2006-10-29 16:15:24 UTC
(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
Comment 72 Peter Ansell 2006-10-29 16:16:14 UTC
Created attachment 100750 [details]
Stacktrace for failure on opening monodevelop-0.12
Comment 73 Peter Ansell 2006-10-29 18:11:41 UTC
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.
Comment 74 Peter Ansell 2006-10-29 21:23:35 UTC
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
Comment 75 Peter Ansell 2006-11-03 19:27:46 UTC
(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.
Comment 76 Luca Marturana 2006-11-05 03:33:09 UTC
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.
Comment 77 Jakub Moc (RETIRED) gentoo-dev 2007-01-01 15:47:14 UTC
Fixed in 0.11-r1; everything else -> file a new bug please. This is already messy enough.