Arch Linux User Repository

This metapackage has a significant AUR dependency chain. In order to build it in a clean chroot (without using an AUR helper), you will have to preinstall its dependencies and their dependencies (after clean chroot building each of them):

makechrootpkg -c -r $CHROOT \
-I ../libgnomeui/libgnomeui-2.24.5-3-x86_64.pkg.tar.xz \
-I ../libbonoboui/libbonoboui-2.24.5-3-x86_64.pkg.tar.xz \
-I ../libgnome/libgnome-2.32.1-7-x86_64.pkg.tar.xz \
-I ../libgnomecanvas/libgnomecanvas-2.30.3-4-x86_64.pkg.tar.xz \
-I ../libgnome/libgnome-data-2.32.1-7-x86_64.pkg.tar.xz \
-I ../gnome-vfs/gnome-vfs-2.24.4-11-x86_64.pkg.tar.xz \
-I ../gnome-mime-data/gnome-mime-data-2.18.0-8-any.pkg.tar.xz \
-I ../gamin/gamin-0.1.10-9-x86_64.pkg.tar.xz \
-I ../libbonobo/libbonobo-2.32.1-4-x86_64.pkg.tar.xz \
-I ../orbit2/orbit2-2.14.19-7-x86_64.pkg.tar.xz

This metapackage has a significant AUR dependency chain. In order to build it in a clean chroot (without using an AUR helper), you will have to preinstall its dependencies and their dependencies (after clean chroot building each of them):

makechrootpkg -c -r $CHROOT \
-I ../libgnomeui/libgnomeui-2.24.5-3-x86_64.pkg.tar.xz \
-I ../libbonoboui/libbonoboui-2.24.5-3-x86_64.pkg.tar.xz \
-I ../libgnome/libgnome-2.32.1-7-x86_64.pkg.tar.xz \
-I ../libgnomecanvas/libgnomecanvas-2.30.3-4-x86_64.pkg.tar.xz \
-I ../libgnome/libgnome-data-2.32.1-7-x86_64.pkg.tar.xz \
-I ../gnome-vfs/gnome-vfs-2.24.4-11-x86_64.pkg.tar.xz \
-I ../gnome-mime-data/gnome-mime-data-2.18.0-8-any.pkg.tar.xz \
-I ../gamin/gamin-0.1.10-9-x86_64.pkg.tar.xz \
-I ../libbonobo/libbonobo-2.32.1-4-x86_64.pkg.tar.xz \
-I ../orbit2/orbit2-2.14.19-7-x86_64.pkg.tar.xz

gconf-sharp is available in AUR now

@FabioLolix

If the source is still out there I'll try to ressurect it as a new AUR package (don't remember which it was actually in), to be honest though gnome-sharp is long dead :( currently I only need it for glippy, which is also long dead :(

One of these days we'll have to move on.

gconf-sharp dependency is no more present in the repo or AUR

On my system, I had to install the package gnome-sharp to it works. Otherwise, it gives the error:
'MonoDevelop-Unity, add-in could not be started 'MonoDevelop.GnomePlatform.5.?'

>FuzzyCheese
Wow, you are like a bug detective. Good work!

>bititanb
Repackaged as per your git, except for gconf-sharp, which is provided in [extra] (at version 2.24.2-5). The section is commented out, so the PKGBUILD can be easily modified to build the newer version.

I just used the fixes provided by @bititanb.
Flawless. Thanks for that.

For the fix of this error :

Settings.cs(1,1): error CS1012: Too many characters in character literal
Settings.cs(1,93): error CS1525: Unexpected symbol `/'
Settings.cs(1,114): error CS1012: Too many characters in character literal

They or something probably added the first line wrongly. To fix it, comment out the first line at

../gnome-sharp/src/gnome-sharp-2.24.3/sample/gconf/Setting.cs

and go to ../gnome-sharp

run makepkg -si yourself.

this is located at your AUR cache parent-folder. It could differ for everyone.

>>FuzzyCheese

Thanks for the fixes.

>>quequotion

For now maybe we can ship the version with the patch? I got the patch from FuzzyCheese, made some fixes, so no changes needed from you.
Here are the patch and PKGBUILD:
https://github.com/bititanb/arch-pkgbuilds/tree/master/gnome-sharp

Btw, I removed some old patches that already in upstream.

Upstream problem in mono/gnome-sharp
A file is being specified "gconf-sharp.dll" instead of just the directory name in gnome-sharp/sample/gconf/Makefile.am line 25.

PATCH: fix_mono_path.patch https://pastebin.com/des0edbd
Apply patch file to extracted gnome-sharp package snapshot: patch -i fix_mono_path.patch
===========================================================
The error is raised on line 438 in mono/mono/metadata/assembly.c because with a file specified it fails the directory test "g_file_test (*splitted, G_FILE_TEST_IS_DIR)"

I could only find other uses of MONO_PATH as directory and never as a file.

A file has been specified in gnome-sharp/sample/gconf/Makefile.am for at least 11 years.
Two years ago mono_set_assemblies_path (mono_path) was implimented.
Prior to that change it looks like the DirectoryInfo function was used and it does not care if a file is specified as stated here:
https://msdn.microsoft.com/en-us/library/system.io.directoryinfo(v=vs.110).aspx
"In members that accept a path, the path can refer to a file or just a directory."

I think the mono change on Mar 15, 2016 triggered this problem but is not the cause.
https://github.com/mono/mono/commit/ef407901f8fdd9ed8c377dbec8123b5afb932ebb

The error can be traced like this:
gnome-sharp/sample/gconf/Makefile.am line 25 - Set MONO_PATH env and exicute mono.
https://github.com/mono/gnome-sharp/blob/master/sample/gconf/Makefile.am#L25

mono/mono/tests/assembly-load-remap.cs line 30 - Use value from MONO_PATH as parameter to function mono_set_assemblies_path.
https://github.com/mono/mono/blob/master/mono/tests/assembly-load-remap.cs#L30

mono/mono/metadata/assembly.c line 438 - Raise warning if path value is not a directory.
https://github.com/mono/mono/blob/fc6e8a27fc55319141ceb29fbb7b5c63a9030b5e/mono/metadata/assembly.c#L438

glib function g_file_test() - Tests filename.
https://developer.gnome.org/glib/stable/glib-File-Utilities.html#GFileTest