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: