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.
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
