cal | 2 Feb 2010 04:28
Favicon

Re: ladish + yoshimi

Nedko Arnaudov wrote:
> cal <cal@...> writes:
> 
>>>> The other big mystery is that studio files get created ok, but there's no way
>>>> gladish or ladish_control can list or load them. That one I suspect maybe
>>>> goes to service permissions.
>>> This sounds strange. Do you get errors in the ladishd log file when
>>> "ladish_control slist" is being executed?
>> Nope, nothing at all.
> 
> So you get:
>  * studio files created on save
>  * nothing is reported "ladish_control slist"
>  * you get no errors in terminal and no errors in the ladishd log file.
> 
> Do I get it right?
> 
> If so, I'd like to ask you to launch ladishd through gdb:
>  1. make sure that ladishd is not currently running
>  2. gdb ladishd
>  3. set breakpoint in studios_iterate()
>  4. inspect what is happening there. the function iterates a directory.
> 
> Tell me if you want to go through this process and if you need more
> hints from me.

gdb got a bit tedious, so I put in a sprinkle of printf style debugs, whereby
'ladish_control slist' produces -

{{{
Tue Feb  2 14:13:33 2010: LADI session handler activated. Version 0.3
(b6fe91e830aa5715dd03af2bf263b70d28f4df79-dirty) built on Tue Feb  2 14:12:48 2010
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0minit_paths: main.c:init_paths(), environment HOME dir:
'/home/cal', BASE_DIR: '/.ladish'
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0minit_paths: main.c:init_paths():228 sets g_base_dir: '/home/cal/.ladish'
Tue Feb  2 14:13:33 2010: Connected to local session bus, unique name is ":1.15"
Tue Feb  2 14:13:33 2010: studio object construct
Tue Feb  2 14:13:33 2010: JACK controller appeared.
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: Into studio.c:studios_iterate()
        g_base_dir: /home/cal/.ladish
        g_studios_dir: /home/cal/.ladish/studios/
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: studios_iterate() checks .
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: dentry->d_type != DT_REG
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: studios_iterate() checks ..
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: dentry->d_type != DT_REG
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: studios_iterate() checks XYZ.xml
Tue Feb  2 14:13:33 2010: ESC[31mERROR: ESC[0mstudios_iterate: dentry->d_type != DT_REG
}}}

where XYZ.xml was a studio file from an earlier run -
{{{
$ cd  /home/cal/.ladish/studios/
Tue Feb 02:cal <at> stkildaeast:~/.ladish/studios
$ ls -altF .
total 16
drwx------ 2 cal cal    24 2010-02-02 14:02 ./
-rwx------ 1 cal cal 14837 2010-02-02 03:58 XYZ.xml*
drwx------ 3 cal cal     8 2010-02-01 23:37 ../
}}}

> [ ... ]
> I don't get why you need to tweak dbus access permissions at all. What
> bus you are tweaking permissions of? Is "deny all" the default session
> bus policy in your distro? Policy settings of my
> /etc/dbus-1/session.conf look like this:

You're quite correct. What I presented was the accumulated garbage of my uneducated guesses
during the first 72 hours of exposure to dbus. None of it is actually necessary, most of it
came from my misguided attempts to compensate for various system quirks including an untidy
jackd -> jackdbus transition.

I'll keep pecking away, see what I can figure out.

cheers.


Gmane