[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Update on state of Mono for Wheezy

So, I was feeling all pleased with the state of Mono for Wheezy, then some considerate souls go and file a couple of nontrivial RC bugs, post-freeze. Hooray, etc.

Since these are nontrivial, and the possible fixes may (will) result in fairly messy uploads of one kind or another, I felt it was prudent to keep -release updated on where things lie.

Bug#682284: mono-runtime: SIGSEGV while executing native code on armhf[0]

So, the first bug. When we enabled armhf as an architecture for Mono, on the advice of the ARM porter team, it seemed to work okay - well enough for the compiler to work seemingly normally. However, whilst the general case was fine, there was a problem with (gasp) floating point numbers. The Mono package in the archive is trying to use the soft-float armel ABI, and whenever it tries to call into C libraries on the system, it explodes into a shower of shrapnel. It also fails to correctly do floating point math in pure C# code, but that doesn't cause a SIGSEGV, it just results in bad numbers

There are essentially three ways to deal with this for Wheezy:

1) pretend the inability to use floating point numbers isn't a big deal, and ignore for Wheezy.

2) remove armhf as an architecture for Mono, requiring a sourceful upload of src:mono plus an arch-specific removal on a bunch of arch:any packages plus some sourceful uploads on packages maintained by other teams which generate Mono-related packages, typically very large messy packages from the -med or -science teams.

3) port Mono to armhf properly.

Since 1 is bullshit, and 2 is something I'd really really really rather avoid, I've been trying to get work done on 3, although recruiting knowledgeable hackers to help has been tough. I've had a little help from Jani Monoses, but have had to step up & work on this myself.

Rather fortuitously, a (L)GPL source request to Sony Computer Entertainment[1] has yielded results, and I'm now the proud owner of Sony's Playstation Vita port of a ~year old git master snapshot of the Mono Runtime, which just to happens to use the same ArmHF parameter passing semantics on the Vita operating system. After a couple of days, I managed to port Sony's code back to Linux on Harris (the ArmHF porterbox) well enough to work successfully with the test case in this bug. Since then I've been working on the rather more difficult task of rebasing both Sony's code and my changes to it back against the version of Mono in Debian, where there are significant changes to the runtime code between the relevant versions.

I don't have an ETA on this work, as I'm finding it difficult to juggle "concentrating on crazy C and ARM assembly which is way over my head" and "fatherly duties for 10 week old baby" - I hope to at least have it compiling within a week, with actually working somewhere down the line, depending on how many relevant knowledgeable people I can corner.

Obviously 3 still depends on the release team blessing my somewhat experimental ArmHF port patches, once completed, even if they are completed in a timely manner, which I can't guarantee.

Bug#683289: libmono-webbrowser4.0-cil Recommends package non-existent libgluezilla package[2]

I could just remove the Recommends: here, but it would be a horrible lie to do so, and not adequately deal with the underlying issue. Thinking about it, I should really retitle the bug.

So here's the real issue: Mono provides support for the "WinForms" toolkit used by Microsoft.NET GUI applications, and this package contains the glue to provide the "Mono.WebBrowser.dll" assembly, which is the back-end for the System.Windows.Forms.WebBrowser control, which allows WinForms applications to embed a browser window. Historically Mono provided this by using the Firefox embedding API to put a Gecko control instead of an expected Internet Explorer control, and the gluezilla library provided a simple C bridge to do this. Some time around Firefox 4.0, the embedding API in Firefox was completely broken upstream, with no intention to fix it. Hence removal of gluezilla which became worthless.

Here's where things get complicated. Currently any application which uses System.Windows.Forms.WebBrowser will crash upon object creation, due to the lack of gluezilla. This would be a bigger deal if any apps in Debian actually used System.Windows.Forms.WebBrowser, but they don't - this is an issue only for users' own code, or random apps downloaded from the net.

There are essentially three ways to deal with this for Wheezy:

1) Ditch the Recommends: and leave the (garbage) package, so apps which link against and optionally use the browser control will run (at least until they try to *use* the browser).

2) Remove the libmono-webbrowser{2,4}.0-cil packages entirely, thereby breaking all apps which link against them (affecting only non-Debian apps, but still, it may inconvenience users, especially users migrating their apps from Windows).

3) Fix up the almost-finished-but-not-quite-any-day-now-upstream-assures-me support for using Webkit instead - this requires at least one NEW package (an additional glue library to replace gluezilla), plus bug fixes to both src:mono and src:webkit-sharp. Possibly an entirely new Webkit binding (based on GObject Introspection) would be needed as well, instead of src:webkit-sharp. I'm not too sure, I've been gently leaning on upstream to fix up the issues and they've been somewhat busy so progress is slower than I'd like.

I've gotten things to the stage where with the addition of a new glue library, and removal of some conditional code in src:mono (to force use of Webkit rather than defaulting to Gecko), I can get... a crash in the marshalling code between WinForms and Gtk#. I've asked upstream to help me with some urgency, and that's where they're being cagey over whether the existing src:webkit-sharp will work as expected, or whether the new GI-based binding will be required.

In all cases, a slightly messy src:mono upload is needed, and in the best-case for users, at least one NEW package is also needed.

So, er, that's where things stand today. I rather wish I'd received these bugs a few months ago, but now they're here, it remains to find the best solution for our users which is acceptable to the release team. I'm on IRC as always (including -release) if anyone wants to ask further questions off-list.

NB: please CC me in replies

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682284
[1] http://www.scei.co.jp/psvita-license/mono.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683289

Reply to: