17 May
2009
17 May
'09
8:20 a.m.
On Sun, 17 May 2009 11:23:03 +0200, Fons Adriaensen <fons(a)kokkinizita.net>
wrote:
Ok. a few things here:
- dbus is not the default compile time config option. Your distro should
probably disable it (until it's stable and shiny)
- When dbus is active, it is indeed not backwards compatible with the
legacy autostart feature... I agree it might need fixing
- The behavior you describe with ports is indeed a bug and needs fixing
And for the record, "fixing a mess" doesn't always need to be "deleting
all
the features that might create it".
Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
On Sun, May 17, 2009 at 09:50:55AM +0200,
MarcO'Chapeau wrote:
> On Sun, 17 May 2009 00:31:41 +0200, Fons Adriaensen
> <fons(a)kokkinizita.net>
> wrote:
> > A request to the jackdmp and qjackctl devs:
> >
> > PLEASE REMOVE THAT DBUS MADNESS
>
> Hi Fons,
>
> As long as there's a compile time switch, I don't see how dbus could
ever
be a problem
for those who don't want to use it...
Compile time ? I'm a simple user installing things from
a reputable distro.
and for those who do, I can tell you it works
pretty well.
Are you serious ?
When jackd is autostarted by an app (with the wrong
settings, a separate problem), it creates a dbus daemon
that seems to prevent qjackctl to start jackd with
the right settings. The result is a jackd that does
not any way correspond the the setup in qjackctl, and
there is no way to escape from this, except by manually
killing the daemon. Do you call that 'working pretty
well' ?
When qjackctl starts displaying ports that don't
exist anymore and does not display those that
do exist (no problem with jack-0.116.1) do you
call that 'working pretty well' ?
I'd call it completely broken.