do you have a dbus running ?
did you try 'dbus-launch f-spot' ?

Stephane,

DBUS is running, both system and session.  

-Joseph

can you give the result of this:

export | grep DBUS

Per your resquest:

$ export | grep DBUS

declare -x DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-8PymfbEZM1,guid=45337c10e6f08fa13dba593a425b7e00"


Some facts/observations:

* GARNOME-2.16.x currently uses dbus-0.93
* GARNOME is installed into its own install-tree [for example
/opt/garnome]. Environment variables are set to ensure that files within the GARNOME install-tree are accessed first.
* Other GARNOME applications that use DBUS & HAL are working correctly.

* f-spot-0.2.1 did not have this DBUS problem.
f-spot-0.2.1 was built using dbus-sharp-0.63, extracted from the git repository at freedesktop.org. 

f-spot-0.2.2 provides its own internal version of dbus-sharp, which is a good idea, since the dbus folks have not provided a tarball for dbus-sharp. 

Hmmm... I wonder if the root cause of this problem is a path issue??? A quick look at the ndesk.org dbus-sharp code shows that there are some default paths hard-wired into the code. The code looks "OK", but...


When I get some free cycles I will run the code from gdb and see if the NDesk.DBus Address class is working as expected.


-Joseph

Stephane,

My "guess" was correct. Look at the code in dbus-sharp/Address.cs for the SYSTEM_BUS_ADDRESS:


const string SYSTEM_BUS_ADDRESS = "unix:path=/var/run/dbus/system_bus_socket";
public static string System
{
   get {
        string addr=Environment.GetEnvironmentVariable("DBUS_SYSTEM_BUS_ADDRESS");

        if (String.IsNullOrEmpty (addr))
              addr = SYSTEM_BUS_ADDRESS;

        return addr;
   }
}

If an env variable is not set, SYSTEM_BUS_ADDRESS defaults to a location in /var, which is incorrect for GARNOME or any other framework that installs dbus outside of the system-install tree.

There are a number of ways to fix this problem, for example using a configure argument to set the SYSTEM_BUS_ADDRESS. If a default value for SYSTEM_BUS_ADDRESS is to be hard-wired into the code, it should use
$localstatedir, not /var.

-Joseph

Hi Joseph,

I guessed the same things (that's why I asked about the DBUS* env variable). We had the same kind of issue a few days ago.

I'll ping Alp Toker (managed dbus writer) and see what we should do make it right. In the meantime, you probably can go through this by exporting a SYSTEM_BUS_ADDRESS

Stephane,

I patched the GARNOME makefile to correct the code and rolled on.

pre-configure:
        @cd $(WORKSRC)/dbus-sharp; \
        if [ ! -f Address.cs- ]; then mv Address.cs{,-}; fi; \
        $(SED) -e 's?/var/?$(localstatedir)/?' Address.cs- > Address.cs
        $(MAKECOOKIE)

-Joseph

The D-Bus specification suggests that unix:path=/var/run/dbus/system_bus_socket should be hard-coded as the default fallback if no variable is set. Managed D-Bus works on all sorts of platforms without needing to be recompiled, so it would be a shame to lose touch with the build-once run-anywhere ideal for for such a minor reason. This is particularly the case since the sources are being bundled by different projects with different build systems.

The environment variable is really the only way I can support non-standard install prefixes, and I use several prefixes myself to keep parallel installations of all sorts of software without trouble.

If libdbus is doing a conditional compile here, it's violating the spec itself and should be fixed. Defining the path at compile time is not an acceptable workaround.

That said, the exception message could be improved, and the variable should be documented to avoid wasting more time. There may be scope for providing a configuration entry in the .config file but i'd rather avoid that for the reasons given.

Actually, $localstatedir is the default.  On systems where DBUS is installed under /, $localstatedir resolves to /var. 

To see this, look at configure.in for dbus-0.93

                                 ...

##### Set up location for system bus socket
if ! test -z "$with_system_socket"; then
   DBUS_SYSTEM_SOCKET=$with_system_socket
else
   DBUS_SYSTEM_SOCKET=${EXPANDED_LOCALSTATEDIR}/run/dbus/system_bus_socket
fi

                                 ...

This is an easy thing to fix:

* create Address.cs.in 
where '/var' is defined by some token, say %localstatedir%

* add a target to Makefile that creates Address.cs from Address.cs.in using 'sed'


-Joseph

To summarize:
- we probably won't fix that directly in f-spot or we'll be off sync with managed dbus (and we don't want to)
- managed dbus follows the specification on this (http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types).
- libdbus admit not following the spec to the line (http://dbus.freedesktop.org/doc/dbus-specification.html#ftn.id2713144).
- for me, it's a packaging issue. it should be reported to the GARNOME packager. It should'nt be fixed at compile time (portability) but at runtime by exporting the right environment variable.

Joseph, Alp, your comments on this ? can I close this bug entry ?

Stephane,

This is a good summary of my views. I would discourage any compile-time configuration options in favour of using the environment variable at run-time if necessary, although it should really not be needed on a production system.

If there are others who still doubt this decision, see #362601 to see the needless hassle introduced by variables defined during the build.

Thanks.

Stepane,

I am the GARNOME packager.  

I have asked the DBUS folks to take a look at this thread.


Be well,

-Joseph

I've been asked to comment on this thread.  I think Alp, you are reading into the spec a bit much.  What the spec says is:

The address of the system message bus is given in the DBUS_SYSTEM_BUS_ADDRESS environment variable. If that variable is not set, applications should try to connect to the well-known address unix:path=/var/run/dbus/system_bus_socket.

In other words the most likely place for the system bus socket is unix:path=/var/run/dbus/system_bus_socket not that it will actually be there or that libraries have to look there but applications should if they can't find the socket.

Of course the semeantics in libdbus are a bit different since they are based off of localstatedir which is standard on Unix like platforms.  We do this specificly for self contained builds like GARNOME or jhbuild where apps may need to run on a bus version which is not installed on the system.  This makes testing a bit easier and predates the use of the env variable.

For all intents and purposes something like jhbuild and GARNOME should set the env variable but sometimes this is not possible.  Apps do not have to follow the prefix convention that libdbus uses but it would be nice if they do.

Joseph: is it still an issue for you ?

no news in month... closing. please reopen if this is still an issue for you.