I'm confirming this bug, I was able to reproduce the behavior in the question.
David: Its not clear if you've not used mono or C# before, but mono uses the PE format for its executables, but instead of using i386 or other assembly code, its CIL byte code. Wikipedia has a fairly good writeup of how .NET (and thus mono) applications work http://en.wikipedia.org/wiki/.NET_Framework. I realize its confusing to see .exec and .dlls on a Linux system, but rest assured that this is proper and expected behavior.
As an added test, I installed f-spot on my ia64, and it works, so there are no architecture-specific bits. I had apport file https://bugs.edge.launchpad.net/ubuntu/+source/f-spot/+bug/390701 which should give us some idea of where the segfault exists, but it seems this is a general mono issue, as I saw segfaults installing and removing mono assemblies but dpkg completed the configuration regardless.
I'm confirming this bug, I was able to reproduce the behavior in the question.
David: Its not clear if you've not used mono or C# before, but mono uses the PE format for its executables, but instead of using i386 or other assembly code, its CIL byte code. Wikipedia has a fairly good writeup of how .NET (and thus mono) applications work http:// en.wikipedia. org/wiki/ .NET_Framework. I realize its confusing to see .exec and .dlls on a Linux system, but rest assured that this is proper and expected behavior.
As an added test, I installed f-spot on my ia64, and it works, so there are no architecture- specific bits. I had apport file https:/ /bugs.edge. launchpad. net/ubuntu/ +source/ f-spot/ +bug/390701 which should give us some idea of where the segfault exists, but it seems this is a general mono issue, as I saw segfaults installing and removing mono assemblies but dpkg completed the configuration regardless.