Ping.
Any news? the whole application is broken, no comment on this bug for more than 3 weeks, no changes in the package git [1] since the (failed) rebuild for Fedora 15 [2], and no another rebuild since then.
So, question asked, is the monodevelop package in Fedora is dead?

I don't want to sound annoying, or demanding. I know each and every one of the Fedora packagers and developers are doing awesome work. All I want is a little bit of attention for this bug. Is it to much to ask?

[1] http://pkgs.fedoraproject.org/gitweb/?p=monodevelop.git;a=summary
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=221923

Saw this via the blog post. Paul who maintains this is offline for a while

http://lists.fedoraproject.org/pipermail/devel/2011-March/149914.html

I am not familiar enough with Mono to help fix but if you have a patch that fixes the problem,  I can commit and do a build.

(In reply to comment #2)
> Saw this via the blog post. Paul who maintains this is offline for a while
> 
> http://lists.fedoraproject.org/pipermail/devel/2011-March/149914.html
> 
> I am not familiar enough with Mono to help fix but if you have a patch that
> fixes the problem,  I can commit and do a build.

Monodevelop is co-maintained by chkr (I don't know his real name), so he could fix it...
He told me on IRC that the whole mono stack is broken on F15 and that his plan is to get it fixed before GA.

Alright then.  I will let him handle it.

I have debugged the issue and unfortunately it is quite complicated:

1. there is an ugly workaround to get monodevelop somehow working: just close all error message (around 40 ;-) )

2. the first debug approach was to check, what's really going wrong:
- unfortunately I could not get a better backtrace than the one which was included in this bug report
- the first error message appears when in 
src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs: Show():

RootWindow.Visible = true

is executed...

- gdb referred only to some callback function (from gtk/glib), but nothing specific and not hint which object is not instantiated


3. the 2nd approach was to check, why the issue suddenly appeared in F15:

- the issue started to happen in F15 with monodevelop-2.4-1.fc14.i686
- the same package (literally the same build) works fine in F14
- the same issue happens with monodevelop 2.4.2 from rawhide
- the same issue happens with the monodevelop package from opensuse
- the same issue happens even if I upgrade the whole mono-stack to mono 2.10.1 from rawhide

- this means that something else in F15 must have triggered the issue
- I have downgraded the whole mono stack (2.8.x) in F15 to mono 2.6.7 from F14 and the issue remained.
- Then I have downgraded all packages which were directly or indirectly used by monodevelop and it turns out, that the issue is somehow caused (or at least triggered) by glib2:

glib2-2.28.5-2.fc15.i686: issue happens
glib2-2.26.0-2.fc14.i686: monodevelop starts correctly

- however, when I try to rebuild F14's glib2 within F15, the problem is still there
- on the other hand, when I rebuild glib2-2.28.5-2.fc15 in F14 and install it in F15, the monodevelop issue remains

-> because of this I assume that in F15 either the compile flags or the compiler itself causes a different behavior (or a bug) in glib2

That's the current status.

Any idea or help how to proceed from here is highly appreciated.

I sugest try packaging monodevelop 2.6 beta 1
The source it is found at http://ftp.novell.com/pub/mono/sources/monodevelop/monodevelop-2.5.90.tar.bz2
This may be an option, in the past Fedora had has a beta version of monodevelop 2.0 in a GA release.
I will help to package it, I was repackage 2.4 for Fedora 14 at some time back, for try it, and package monodevelop-database for use it in my work.
I need spec files of 2.4.2 version to adapt it to 2.6 beta 1
And some  who help me to push the rpm, because I'm not oficial packager yet, and I try to learn how to be one.
I want provide the spec to monodevelop work fine, and I want help in other package on top of mono to.
Sorry if my english is not perfect. I speak spanish better than english.

I have already tested monodevelop 2.6 beta and it doesn't solve this issue. It shows exactly the same behavior as originally reported. :-( So an update won't solve the underlying issue...

So whether monodevelop should be updated to 2.6 beta is a different topic - here are my thoughts:

I don't recommend packaging unstable beta version:
- it is against the general Update rules of Fedora
- the package may be unstable ;-)

I've talked with the monodevelop developers and they couldn't tell me a specific release date. So there is no guarantee that the final 2.6.0 will be released in time for Fedora's F15 release.

So there is currently no reason why monodevelop should be updated to 2.6 beta.

Good to hear that you want to become a packager and help with the mono packages! Just some quick hints:
- in general just follow the process as described in http://fedoraproject.org/wiki/PackageMaintainers/Join
- I've seen that you have already created a review request for a new package - that's good and the first step!
- next step is to get a sponsor who can guide you through the whole process
- in general the sponsors would like to see some informal reviews of other review requests to know your packaging skill...
There is lots more to say about this, but this should be discussed separately. Please drop me an email if you need some guidance here.

This sounds like something I experienced when I partially upgraded my f14 system to 2.8.2 (I want the sgen stuff). I fixed the problem and submitted a patch but it isn't in mono 2.8.x yet. 

See https://bugzilla.novell.com/show_bug.cgi?id=643366#c6 - it is likely a problem with System.Windows.Forms (2.8.x/2.10.x are quite different from 2.6.x, which branched off early) ; you might also try my procesdure , i.e. the new 
"--trace=E:all" when running monodevelop to see where it breaks.

FWIW, monodevelop actually runs on my box (f14 but with f15's mono rpm --rebuilded + patches), so your issues are somehow fixed on my box, and my slightly mod'ed rpms are on:

http://sourceforge.net/projects/outmodedbonsai/files/Ximian Mono/Fedora updates/mono 2.8.2 for fc14/

I wrote to Paul and CC'ed mono@fedora about my rebuilds (I want sgen, and am willing to remove break a few packages to get that; so a few packages needed to be removed; but monodevelop wasn't one of them); but never got any response; but my posts are in the mailing list archive:

http://lists.fedoraproject.org/pipermail/mono/2010-December/000304.html
http://lists.fedoraproject.org/pipermail/mono/2010-December/000307.html

(In reply to comment #7)
<snipped>
> Good to hear that you want to become a packager and help with the mono
> packages! Just some quick hints:
> - in general just follow the process as described in
> http://fedoraproject.org/wiki/PackageMaintainers/Join
> - I've seen that you have already created a review request for a new package -
> that's good and the first step!
> - next step is to get a sponsor who can guide you through the whole process
> - in general the sponsors would like to see some informal reviews of other
> review requests to know your packaging skill...
> There is lots more to say about this, but this should be discussed separately.
> Please drop me an email if you need some guidance here.

Since Paul isn't active much, and I have my own patch, any chance of somebody taking up my patch?
https://bugzilla.novell.com/show_bug.cgi?id=643366

It is the same as the listView patch below, and I also need a largeheap change to get something running smoothly as well:
http://sourceforge.net/projects/outmodedbonsai/files/Ximian Mono/

I am willing to take the pain of co-maintaining mono if that's what it takes...

(In reply to comment #8)
> This sounds like something I experienced when I partially upgraded my f14
> system to 2.8.2 (I want the sgen stuff). I fixed the problem and submitted a
> patch but it isn't in mono 2.8.x yet. 
> 
> See https://bugzilla.novell.com/show_bug.cgi?id=643366#c6 - it is likely a
> problem with System.Windows.Forms (2.8.x/2.10.x are quite different from 2.6.x,

No, IMHO that's unrelated. AFAIK monodevelop uses Gtk and not Windows.Forms as its GUI toolkit.

> which branched off early) ; you might also try my procesdure , i.e. the new 
> "--trace=E:all" when running monodevelop to see where it breaks.

Ok, that's helpful! Here is now a much better backtrace of this issue:

"<unnamed thread>" tid=0x0x3a68f0 this=0x0x53f20 thread handle 0x403 state : not waiting owns ()
  at GLib.Object.NotifyCallback (intptr,intptr,intptr) <0x0018d>
  at (wrapper native-to-managed) GLib.Object.NotifyCallback (intptr,intptr,intptr) <0xffffffff>
  at (wrapper managed-to-native) GLib.Object.g_object_set_property (intptr,intptr,GLib.Value&) <0xffffffff>
  at GLib.Object.SetProperty (string,GLib.Value) <0x0003d>
  at Gtk.Widget.set_WidthRequest (int) <0x0006b>
  at MonoDevelop.Components.DockToolbars.DockToolbar.CalcSizes () <0x0009d>
  at MonoDevelop.Components.DockToolbars.DockToolbar.get_DefaultSize () <0x0001b>
  at MonoDevelop.Components.DockToolbars.DockToolbarPanel.UpdateRowSizes (int) <0x00099>
  at MonoDevelop.Components.DockToolbars.DockToolbarPanel.OnBarSizeChanged (object,System.EventArgs) <0x00055>
  at MonoDevelop.Components.DockToolbars.DockToolbar.OnItemChange (object,System.EventArgs) <0x00027>
  at MonoDevelop.Components.DockToolbars.DockToolbar.OnRealized () <0x0002f>
  at Gtk.Widget.realized_cb (intptr) <0x0004c>
  at (wrapper native-to-managed) Gtk.Widget.realized_cb (intptr) <0xffffffff>
  at (wrapper managed-to-native) Gtk.Container.gtksharp_container_invoke_gtk_callback (intptr,intptr,intptr) <0xffffffff>
  at Gtk.Container/CallbackInvoker.Invoke (Gtk.Widget) <0x00021>
  at (wrapper unbox) Gtk.Container/CallbackInvoker.Invoke (Gtk.Widget) <0xffffffff>
  at MonoDevelop.Components.DockToolbars.FixedPanel.ForAll (bool,Gtk.Callback) <0x0008e>
  at Gtk.Container.Forall_cb (intptr,bool,intptr,intptr) <0x000d1>
  at (wrapper native-to-managed) Gtk.Container.Forall_cb (intptr,int,intptr,intptr) <0xffffffff>
  at (wrapper managed-to-native) GLib.Object.g_object_set_property (intptr,intptr,GLib.Value&) <0xffffffff>
  at GLib.Object.SetProperty (string,GLib.Value) <0x0003d>
  at Gtk.Widget.set_Visible (bool) <0x0006b>
  at MonoDevelop.Ide.Gui.Workbench.Show (string) <0x000db>
  at MonoDevelop.Ide.IdeApp.Initialize (MonoDevelop.Core.IProgressMonitor) <0x003c3>
  at MonoDevelop.Ide.IdeStartup.Run (string[]) <0x012fd>
  at MonoDevelop.Startup.MonoDevelopMain.Main (string[]) <0x00073>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <0xffffffff>
ERROR [2011-04-06 00:59:20Z]: Unhandled Exception
System.NullReferenceException: Object reference not set to an instance of an object
  at GLib.Object.NotifyCallback (IntPtr handle, IntPtr pspec, IntPtr gch) [0x00000] in <filename unknown>:0 

> FWIW, monodevelop actually runs on my box (f14 but with f15's mono rpm
> --rebuilded + patches), so your issues are somehow fixed on my box, and my
> slightly mod'ed rpms are on:

It runs on your box because you use F14's glib2. The issue was introduce by any glib2 package which was compiled in F15.

> I wrote to Paul and CC'ed mono@fedora about my rebuilds (I want sgen, and am
> willing to remove break a few packages to get that; so a few packages needed to
> be removed; but monodevelop wasn't one of them); but never got any response;
> but my posts are in the mailing list archive:
> 
> http://lists.fedoraproject.org/pipermail/mono/2010-December/000304.html
> http://lists.fedoraproject.org/pipermail/mono/2010-December/000307.html

That's unrelated to this bug report (mono 2.10.1 will include sgen, but there are no plans to update mono in F14). Please let's discuss this outside of this bug report.

Christian Krause,

If you want to accept someone as a co-maintainer,  there is a shortcut at 

http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_comaintainer

You can file a ticket with FESCo if you want

(In reply to comment #9)
> Since Paul isn't active much, and I have my own patch, any chance of somebody
> taking up my patch?

That's unrelated to this bug report.

Please create new bug bug entries for other mono issues.

(In reply to comment #10)
> Ok, that's helpful! Here is now a much better backtrace of this issue:
> 

>   at Gtk.Widget.set_WidthRequest (int) <0x0006b>
>   at MonoDevelop.Components.DockToolbars.DockToolbar.CalcSizes () <0x0009d>

> 
> It runs on your box because you use F14's glib2. The issue was introduce by any
> glib2 package which was compiled in F15.

The monodevelop developers should be able to work out something from the above trace. I am not familiar enough with gtk2-sharp(?), but the first thing one might do is to trap the exception at gtk2-sharp at this point: 

    Gtk.Widget.set_WidthRequest (int) <0x0006b>

It looks like the widget is not what gtk2-sharp thinks it is.

The 2nd way is to trap the exception at:
MonoDevelop.Components.DockToolbars.DockToolbar.CalcSizes () <0x0009d>

Either way, since comment 5 mentions that closing all the error message popup allow monodevelop to proceed, I think trapping the exception at  MonoDevelop.Components.DockToolbars.DockToolbar.CalcSizes() - something like this - should work:

try {...
} catch (exception e) { 
/* assignment to Gtk.Widget.WidthRequest failed, just make up a sensitive value */
  size = <some sensible value>
}

BTW, if you put the *-debuginfo* package on, you may get line-numbers, which could save you a bit of time...

There is also the rather crazy thing to do - put a "try {} catch (exception e) {/* do nothing */}" around 

src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs: Show():
RootWindow.Visible = true

I'm new to fedora (3 days) but I have 5 years debian 
I've always manually compiled mono packages 
monodevelop install fedora 15 to meet and test was 
The annoying thing in monodevelop problem so I decided to compile it manually and it does not show this error. 

1. - Lower the monodevelop git repositories (git clone 
https: / / github.com / mono / gtk-sharp.git) 

2 - ln-s / usr/lib64/mono / usr / lib 

3 - Compile monodevelop (. / Configure prefix = / usr) 

4 - make 

5 - make install 


monodevelop ready fixed. 
I forgive my English but I speak Spanish

monodevelop-2.4.2-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/monodevelop-2.4.2-4.fc15

Package monodevelop-2.4.2-4.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing monodevelop-2.4.2-4.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/monodevelop-2.4.2-4.fc15
then log in and leave karma (feedback).

monodevelop-2.4.2-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.