C# bindings to dbus. Probably not ready yet.
Created attachment 105255 [details] dbus-sharp-0.3.ebuild
Created attachment 105256 [details] files/dbus-sharp.pc
Is .3 meant to be installed in gac? If not, then no, its not a dropin replacement yet (as far as I know, old software that used dbus-sharp needs to be updated regardless)
(In reply to comment #3) > Is .3 meant to be installed in gac? If not, then no, its not a dropin > replacement yet (as far as I know, old software that used dbus-sharp needs to > be updated regardless) No, not yet. I had the idea that it should be possible to get working anyway (through pkgconfig hackery, mostly), but that didn't work out all that well.
I also wrote an ebuild. It's not meant for GAC. It's meant for applications to integrate on their own. i.e. Banshee has done this. Also this package is no where near a drop-in replacement. Totally different API that behaves totally diff. The old bindings wrapped the C library. These are totally written from scratch in C# with a diff API. 0.5 is the targeted release for GAC
As I previously stated. Once there's a release meant for GAC, feel free to re-open.
Please reopen. Both 0.4.* and 0.5.* series are ready for GAC. Upstream ask distros to package only stable releases (that is, 0.4.* series) and packages should be named ndesk-dbus and ndesk-dbus-glib.
Created attachment 121074 [details] ndesk-dbus-0.5.2.ebuild Ebuild for 0.4 and 0.5 (I wrote it for 0.5.2 but I realized it works on the other releases without problems) based on Ed Catmur's one.
Created attachment 121078 [details] ndesk-dbus-0.5.2.ebuild Forgot to inherit multilib.
It uses gac now, reopening.
coldwind: you want to maintain it? compnerd was suppose to take care of it but has been MIA.
(In reply to comment #11) > coldwind: you want to maintain it? compnerd was suppose to take care of it but > has been MIA. Actually, I don't want to maintain it unless I get some success with landell ebuilds, which is the only reason to being iterested in this package. Do you know more packages which can take advantage of ndesk-dbus? I may reconsider maintaining it if I find some use.
yes actually muine, banshee and tomboy will take advantage of this package they could be build with the built in ndesk-dbus and with this (external).
Do they actually take advantage of it if its externally built, or do they still use/build their own source/build versions?
I know banshee still bundles it's own and builds it's own. As far as muine, it would probably be good to ask latexer since well, he's the author of that package.
banshee and muine can use external dbus and the internal dbus the only thing that changes is that usually external dbus gets updated more often. Of course new packages can depend of this external dbus.
I'm not an expert, I'm just trying to use f-spot that (probably since version 0.4) need ndesk-dbus-glib. I get this trace at startup: dario@giquattro ~ $ f-spot Stacktrace: at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0xffffffff> at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0x000a4> at NDesk.GLib.IO.AddWatch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc) <0x00064> at NDesk.DBus.BusG.Init (NDesk.DBus.Connection,NDesk.GLib.IOFunc) <0x00080> at NDesk.DBus.BusG.Init (NDesk.DBus.Connection) <0x000cc> at NDesk.DBus.BusG.Init () <0x00044> at FSpot.Driver.Main (string[]) <0x0039c> at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0x00080> Native stacktrace: f-spot [0x1012b11c] f-spot [0x100f56c0] [0x100380] [(nil)] /usr/lib/libglib-2.0.so.0(g_io_add_watch_full+0x54) [0xff14538] [0x311b29dc] [0x311b2858] [0x311b253c] [0x311b23c8] [0x3110bf50] [0x30b7c8b0] [0x30b7a0dc] f-spot [0x10115720] f-spot(mono_runtime_invoke+0x1c) [0x100929a8] f-spot(mono_runtime_exec_main+0x74) [0x1009a0c0] f-spot(mono_runtime_run_main+0x188) [0x1009a3a0] f-spot(mono_jit_exec+0xa0) [0x1000ef50] f-spot(mono_main+0xff4) [0x1000ff80] f-spot [0x1000e980] /lib/libc.so.6 [0xfc7cd3c] /lib/libc.so.6 [0xfc7cf60] Debug info from gdb: (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0x0fd30198 in select () from /lib/libc.so.6 ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= Abortito On irc people suggested me to look at the patch in http://bugzilla.gnome.org/show_bug.cgi?id=458078 but I don't know where to apply it. I guess it should apply to the ebuild in this bug report. Please, give me some hints. Bye, Dario
I solved my problem. I was not able to link esternal ndesk library (those of this bug report) to f-spot ; f-spot instead used the same ndesk code integrated in its package. I applied the patch I linked before in dbus-sharp-glib/GLib.IO.cs of f-spot source and it worked. So, even if I didn't test it directly, I guess this patch should be necessary for ndesk-dbus ebuild on ppc.
Created attachment 133900 [details] ndesk-dbus-0.6.0.ebuild
Created attachment 133902 [details] ndesk-dbus-glib-0.4.1.ebuild
Both ebuilds install fine here. I'd be happy to help maintain this.
Just For The Record, media-sound/muine could be using this but it's using a internal copy now instead. It should be "fixed" when this is in tree.
I had completely forgotten about pushing this into the tree (its been in my overlay forever).
(In reply to comment #23) > I had completely forgotten about pushing this into the tree (its been in my > overlay forever). > ndesk-dbus and ndesk-dbus-glib are still not in the tree. I've been using them (in my own overlay) with beagle 0.3.3 with no problems.
Yes they are. Look for dbus-sharp and dbus-glib-sharp
