>>Please someone tell me how 'dbus-launch' fits into geda? >xgsch2pcb and pcb use D-Bus for IPC. dbus-launch is responsible for >ensuring that a D-Bus session daemon is up and running for gEDA to > work with.
So, without D-Bus daemon running geda, gschem, or pcb can't run ? So there's no point in changing ownership & permissions, until D-Bus daemon is running ? ------snip ---- > and there is a README. > http://geda.seul.org/dist/suite/v0.0.2/README Yes and 'the computer' shows it to be identical to my copy which I've read/followed a zillion times. BTW, I like being able to fetch individual files instead of a big tar, but I failed to get: http://geda.seul.org/dist/suite/v0.0.2/dist/bin/ http://geda.seul.org/dist/suite/v0.0.2/dist/bin/execwrapper ------snip ---- > _If_ I remember correctly, the binary suite relies on shell-script > wrappers created around the programs to set the required > LD_LIBRARY_PATH and PATH. Yes. Let's just follow one 'route': the link: geda points to: -> ./pythonwrapper == which ends with: exec $installdir/bin/python $installdir/bin/$scriptsdir/$base.py $* BUT!! Using mc to 'find all lines in all files in this-dir which have "PATH", shows many; as examples I see:-- File: gschem == EXTRA_DBUS_PATH= EXTRA_DBUS_LD_LIBRARY_PATH= File: execwrapper == EXTRA_DBUS_PATH= EXTRA_DBUS_LD_LIBRARY_PATH= -------- Of course that doesn't prove that LD_LIBRARY_PATH is *not* Of course that doesn't prove that LD_LIBRARY_PATH is *not* updated later in the script, so I put a trace in my ./pythonwrapper just before: exec $installdir/bin/python $installdir/bin/$scriptsdir/$base.py $* == echo "trace LD_LIBRARY_PATH =" echo $LD_LIBRARY_PATH which shows 'empty'. So!! the business of LD_LIBRARY_PATH is a bit confusing. I note: LD_LIBRARY_PATH <> EXTRA_DBUS_LD_LIBRARY_PATH Is ngspice also locked into the quirks of geda ? -------------- snip -- >> !! what a canOworms ?? >I think this reflects that you're using it in a way it really wasn't >designed for. >It was designed to be installed by a local non-privileged user, >in a non-privileged location - such as their home directory. Well I've shown the 'failed-logs' of my attempt at install & run as [non-root] eas, in /home/eas. >As a nasty workaround, you could temporarily give your user account >write-permissions to wherever you want it installed, but I don't think >changing your install location will fix the problem with dbus-launch. > >The dbus-launch issues is probably just a bug in the binary suite. (It >is only version 0.0.2). Isn't dbus-launch essential to the basic working ? I noticed that the <showTheDocumention> call [vs. geda, gschem, or pcb] actually worked with mozilla, altho' mozilla doesn't any longer 'run' on this installation. Later invocations seemed to fail to run mozilla. A complex interaction of various apps. ? Is ngspice also dependant on this dbus-thing ? I think the dependance on dbus is my problem. Even my later installation FC1 [a sluggish hog] has no knowledge of dbus*. Perhaps dbus is only known by newer installations ? Thanks, == Chris Glur. PS. my first scan at goog:D-Bus indicates that it's a 'new' [for me < 10yo] technology. This box was diverted from the trash, before the dot.com-crash, when all the smatys were updating. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
