gmane.comp.audio.jack.ladish

TEST - please ignore

Marc-Olivier Barre — 2012-05-09T15:29:57

Thank you :)

--
Marc-Olivier Barre
XMPP ID : marco-qY6+oKxccOnaOVYouRjCbQ< at >public.gmane.org
www.MarcOChapeau.org

Re: updated ebuild

Wayne — 2012-04-23T23:22:16

Il giorno mar, 17/04/2012 alle 00.58 +0200, Alessio Treglia ha scritto: 



ahoy Alessio,

    thanks for the reply and sorry for me delayed response.  the
requested info is below:




    attached.




    i am using GNOME 2.32.1 on Gentoo, Metacity window manager. with the
Clearlooks theme.

Re: updated ebuild

Nedko Arnaudov — 2012-04-16T11:25:59


I don't get this on my machine


I get this as well


I don't know if this what is the correct behaviour. I'm CCing Alessio
Treglia, he should know.


libappindicator seems to be Unity/Ubuntu specific component. Maybe its
not strictly required. Alessio, please confirm.

Re: updated ebuild

Wayne — 2012-04-11T21:17:04

Il giorno sab, 07/04/2012 alle 18.22 +0300, Nedko Arnaudov ha scritto: 



thanks as always Nedko.  your directions worked great, i re-emerged the
python packages as needed and laditools is installing.  however, when
running ladi-system-tray, i am now getting the following error:

$ ladi-system-tray 
Gtk-Message: Failed to load module "gnomesegvhandler"
ERROR:root:Could not find any typelib for AppIndicator3

the menu still appears in the system tray area, but the
theme/decorations are all different that the other icons, and the actual
laditray icon is missing.

i am currently trying to install dev-libs/libappindicator to remove the
ERROR, but so far that is not installing either.

thanks+peace, w

Re: updated ebuild

Nedko Arnaudov — 2012-04-07T15:22:55


The problem is that laditools (1.0 and 9999) actually requires
python2.7, the INSTALL file in the 1.0 tarball incorectly states
2.6. Alessio fixed the INSTALL file in git. I've updated the 1.0 and
9999 ebuilds in the ladi overlay. You will have to make sure that you
have required python modules built for 2.7. I've updated the
dev-python/enum and dev-python/wmdocklib ebuilds in the ladi overlay to
build against multiple python versions, so if you rebuild them you
should get them built for all 2.x pythons (they are not 3.0 ready) that
you configured in /etc/make.conf via USE_PYTHON variable [1]. In case
you dont have this variable already set, please note the warning at the
end of [1]. I didn't run python-updater on my system. Instead I plan to
re-emerge packages that are broken (if they actually are) on
case-by-case basis, ... if I actually find broken ones. Your default
python seems to be 2.6, I had 2.7 as default on my system, so YMMV. The
three updated ladi overlay ebuilds are expected to work regardless of
currently eselected python version.

[1] dev.gentoo.org/~quantumsummers/use_python_guide.xml

Re: updated ebuild

Wayne — 2012-04-02T10:06:31

Il giorno dom, 01/04/2012 alle 23.51 +0300, Nedko Arnaudov ha scritto: 



    getting closer, but no luck yet:


python2.6 setup.py build
Traceback (most recent call last):
  File "setup.py", line 56, in <module>
    commit = subprocess.check_output(["sh", get_commit_script]).strip()
AttributeError: 'module' object has no attribute 'check_output'


not sure what the missing dependency is here? 



    OK, though i will keep testing the live ebuild until we get the
dependencies right.  just let me know.

peace, w

Re: updated ebuild

Nedko Arnaudov — 2012-04-01T20:51:28


Yes, it was another missing dependency. I've pushed fix for it, please
test.


Right now there are no major differences between the live ebuild and the
1.0 release.

Re: updated ebuild

Wayne — 2012-03-30T17:12:03

Il giorno gio, 29/03/2012 alle 19.44 +0300, Nedko Arnaudov ha scritto: 



    it is also your fault that we have LADISH and friends as well ;)




    i tried to emerge the new ebuild and received the following error:


python2.6 setup.py build
Traceback (most recent call last):
  File "setup.py", line 28, in <module>
    from DistUtilsExtra.command import *
ImportError: No module named DistUtilsExtra.command


    i assume this is another missing dependency?  a quick emerge -s
looks like dev-python/python-distutils-extra should be added as a
dependency as well?  when you push the fix i can test it again.


    finally, is there any reason to use the live ebuild with the 1.0
release?

    thanks again.

peace, w

Re: updated ebuild

Nedko Arnaudov — 2012-03-29T16:44:51


Hi Wayne,

Its my fault that the build doesnt work :] I've changed the dependencies
to match the latest laditools code (as per 1.0 release by Alessio
Treglia) but I didnt actually test the 9999 ebuild. The correct fix
would be to to adjust get git repo url to be the one at repo.or.cz,
because this is where the current development actually happens. I've
pushed the fix and it works here (now I did an actual test!). Please
report if you have any issues with the new ebuild.

updated ebuild

Wayne — 2012-03-29T15:27:54

ahoy Nedko & co.

    after an update, i noticed that laditray had stopped running.  from
the error, it looked like it needed dev-python/pyyaml.  i added it to
the laditools-9999.ebuild (attached) and it seems to be working now.  if
this is indeed a dependency, perhaps you can update the master ebuilds
in the ladi overlay?

    thanks as always for the great software.

peace, w

PS.  maybe the non-live ebuilds will need the same dependency info?
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI="3"

inherit distutils git-2

DESCRIPTION="LADITools is a set of tools to improve desktop integration and user workflow of Linux audio systems"
HOMEPAGE="http://www.marcochapeau.org/software/laditools"

EGIT_REPO_URI="git://git.marcochapeau.org/laditools.git"

LICENSE="GPL-3"
SLOT="0"
KEYWORDS=""
IUSE=""

PYTHON_DEPEND="2:2.6"

RDEPEND="dev-lang/python
dev-python/pyyaml
>=dev-python/enum-0.4.4
>=media-sound/jack-audio-connection-kit-0.109.2-r2[dbus]
>=x11-libs/vte-0.30.1[introspection]"

DOCS="README"

Re: lash-compat

Nedko Arnaudov — 2012-01-30T09:00:08


Studios support L1 because it doesnt require dedicated dirs. Internal
state [file] is set manually by user and there is less chance of user
loosing data bya accident.


Yes, this is one of the ways. Alternatively you can create a dedicated
room for jack_mixer and connect other room(s) to it.

Re: lash-compat

Dan Muresan — 2012-01-30T08:53:21

Sorry, I meant L2 as well.


So studios preserve command line (L0) settings, but not L1 or L2 settings.
A bit counter-intuitive, but I guess we've discussed this at length before.

I wanted to put a jack_mixer right before the Hardware Playback stage (in
the studio so I don't have to repeat it in every Room). I guess that means
creating a separate config file, passing that on the command line etc.

Re: lash-compat

Nedko Arnaudov — 2012-01-30T08:33:34


No... lash apps will stay lash apps (L2)...


Eventually but unlikely. lash requires app dirs and studios dont have
dedicated dirs. the studio level lash app support used per app dirs in
studios directory. this made lash apps somewhat shared between studios.
In theory because app uuids are used one app should belong to only one
studio. In practice studio "save as" does not regenerate app uuids so
they will be shared and user will be clueless.

Re: lash-compat

Dan Muresan — 2012-01-28T20:17:31

That's good news -- it means "old" lash apps can become L1 apps
straight away (well, upon recompilation).

I saw a ladish commit disabling studio-level lash apps -- will this be
"fixed" eventually?

Re: lash-compat

Nedko Arnaudov — 2012-01-26T16:48:27


Alessio just confirmed on IRC:

"I'll have a look and re-introduce lash compatibility layer (with a proper Debian's custom SONAME) ASAP"

Re: lash-compat

Nedko Arnaudov — 2012-01-23T08:50:42


To use at least one of jack-session, L1 or liblash. They can implement
all three and thus be more flexible to user`s needs.


jack_mixer should me considered maintained I think. I want to add L1 to
it at some point. IIRC it can manually save internal state as well. In
any case if you or someone else contributes improvements in this area,
I'll commit them. Frederic is the current maintainer. His position
wrt session handling is:

"it's a sensible topic I wouldn't want to touch before understanding all
issues; but this doesn't prevent patches to be applied, just me diving
into the stuff. so go ahead and commit, I'd say. and I'll push a tarball
out when you feel like it's been tested enough."

AFAIK Alessio is going to re-add lash support in Debian but its better
to ask him directly for an official position. I think he is not
subscribed to this list.


Time will tell. IMO jack-session is quite far from being perfect, both
design and implementation-wise. I don't play active role in the
jack-session crusade. I want ladish to provide alternative paths for
users and app developers.

Re: lash-compat

Dan Muresan — 2012-01-18T10:09:05

Well, what is your current recommendations for app writers who want
their apps to "play nice" in ladish? Use jack-session, liblash, stick
to L1, or what?


Maybe... The changelog just says

+  * Drop lash compatibility library, it's not needed anymore since we
+    don't want applications use something deprecated.

To make things worse Debian has been dropping liblash support  from
apps for a while now, on the theory that Lash is abandoned. At the
same time some of those apps are unmaintained (jack_mixer?). So in the
end they may never run properly (>= L1) under Ladish (in Debian
distros that is). Which is a pity!


A winner between... Jack-session vs liblash? With the 800-pound Debian
dropping liblash support completely, I think it's clear which way
things are heading.

github

Nedko Arnaudov — 2012-01-14T17:42:51

github provides useful features for colaboration so I created set of
LADI related repos there:

https://github.com/LADI

repo.or.cz is not deprecated, and stays as alternative to github.

Re: lash-compat

Nedko Arnaudov — 2012-01-03T16:35:20


I don't know what exactly lash_compat package is for. In gentoo I'm
handling liblash through a virtual package that is satisfied either by
LASH or ladish implementation of liblash.


Well, Alessio reported problem with ABI changes and asked for bumping
soname. I refuse because IMO soname must match the one of the emulated
liblash version, i.e. the one from the latest lash release. This may
have something to do with drop of lash-compat.


IMO its good to keep lash until there is a ubiquitous winner. Or at
least ubiquitous replacement for lash. This is why I implemented liblash
between 0.3 and 1.

lash-compat

Dan Muresan — 2012-01-03T09:33:48

Hi, a question about lash-compat.

My understanding is that it enables old programs that need
/usr/include/lash to compile, and perhaps even work better (L2 instead
of L1/0) under ladish.

It now seems that Debian is dropping lash-compat from their packaging
of ladish [1], because it is "not needed any more". True, many old
LASH programs have compile-time flags to disable LASH.

Is this a good thing? Are old LASH programs better of as L0 (by
compiling them with --disable-lash or whatever) or as L2 (using
lash-compat)?


[1] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/ladish.git;a=summary

Re: Adding Jack transport support?

Nedko Arnaudov — 2012-01-02T08:26:00

Hi Dan,


You are reading it right. jackdbus transport interface is not
implemented yet.