mono/mock issue
Paul Howarth
paul at city-fan.org
Thu Apr 20 14:35:37 UTC 2006
Michael Schwendt wrote:
> On Wed, 29 Mar 2006 13:23:29 +0100, Paul Howarth wrote:
>
>> Whilst in the process of reviewing "lat" (#177580), I've created a
>> modified spec file that brings the package up to the latest release
>> version and addresses a number of review issues. It builds OK for me on
>> my FC5 desktop but I can't get it to build in mock. The following rather
>> cryptic error message appears:
>>
>> Making install in gnome-keyring-glue
>> make[1]: Entering directory
>> `/builddir/build/BUILD/lat-1.0.3/gnome-keyring-glue'
>> /usr/bin/mcs -unsafe -target:library -out:gnome-keyring-glue.dll
>> ./Attribute.cs ./AttributeType.cs ./Found.cs ./Global.cs
>> ./GnomeKeyringSharp.OperationGetIntCallbackNative.cs
>> ./GnomeKeyringSharp.OperationGetListCallbackNative.cs ./ItemType.cs
>> ./NetworkPasswordData.cs ./OperationGetIntCallback.cs
>> ./OperationGetListCallback.cs ./Result.cs
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/art-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-vfs-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp-peditors.dll
>> -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glade-sharp.dll
>> mono: mono-codeman.c:257: new_codechunk: Assertion `!err' failed.
>> make[1]: *** [gnome-keyring-glue.dll] Aborted
>> make[1]: Leaving directory
>> `/builddir/build/BUILD/lat-1.0.3/gnome-keyring-glue'
>
> Are there any noticable differences between the native FC5 build log and
> the mock build log?
It turns out that this was an SELinux issue. Mono normally runs in its
own domain, mono_t, which can do execmem and execheap. Under mock, the
domain transition to mono_t doesn't happen and so it runs in
unconfined_t and breaks with an execheap violation. I've fixed this by
writing a policy module for mock and running mock in its own domain,
mock_t, rather than turning on the allow_execheap and allow_execmem
booleans.
> %defattr(..) is missing, btw
Good spot, thanks.
Paul.
More information about the fedora-extras-list
mailing list