gEDA-user: Re. New-install ? dbus-launch

["eas lab" <lab.eas@xxxxxxxxx>]

>>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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user