Re: [PD-dev] pd-extended exectuable - packaging for Debian
On Tue, Aug 13, 2013, at 02:55 AM, zmoel...@iem.at wrote: Quoting Kaj Ailomaa zeque...@mousike.me: As is now, I can change the name of the executable with the configure option --program-suffix. The files always end up in /usr/lib/pd-extended no matter what. Should the config option also change that? where do you want the lib-stuff to go? /usr/lib/pd-extended seems like the right place to me. Yes. It's the correct place for those files. Just thinking that if using the configure option to add a sufix to the program name also the folder /usr/lib/pd should be renamed /usr/lib/pd-extended. But, since something in the pd-extended source already does this, in some other way - I don't know how, the folder name will never change AFAIK. However, there seems to be a bug. It changes three files, not only the executable. I solve it by using a postinst script to rename the two files that shouldn't. https://sourceforge.net/p/pure-data/bugs/1105/ else i'm not sure whether i understand your problem. Currently, my problem is renaming the executable. Building pd-extended will create an exectuable named /usr/bin/pd. Using the configure option --program-suffix=-extended it is renamed to /usr/bin/pd-extended. However, as my bug report shows, two other files get suffixes as well. /usr/lib/pd-extended/bin/pd-watchdog is renamed to /usr/lib/pd-extended/bin/pd-watchdog-extended, and /usr/lib/pd-extended/tcl/pd.gui-tcl is renamed to /usr/lib/pd-extended/tcl/pd-gui.tcl-extended. When starting pd, it won't find those files until they are renamed. The postinst script is a workaround. I could also use it to rename the executable too of course. My thought was that using the configure option --program-suffix would be the best way to rename everything pd into pd-extended. But, maybe not? in any case, i can only reiterate, that the puredata package already handles the renaming properly. the package build process has proven to work for years. i'm pretty sure that you could just take it and do a 's/pure-data/pd-extended/g' on the rules-file. What is changed in the naming? I haven yet investigated. The executable, or something else? i figure that the pd-extended package will only contain the patched version of Pd (that is: all the externals will be separate packages that are pulled in via dependencies). so the packaging should be virtually the same as for puredata. Yes, I believe so. Except, there seems to be some details different in the build process. At least when it comes to naming. I have no clue about what of course. gfmasdr IOhannes PS: i would highly suggest, recommend or even depend to use Recommends for declaring dependencies on externals whenever possible. according to the Debian policy [1], Recommends [...] declares a strong, but not absolute, dependency. in practice this means that any package-manager (in their default settings) will install the recommended packages, but if the user decides to uninstall one of them, they will not end up with having to decide either to remove Pd-extended completely or end up with a broken system. [1] http://www.debian.org/doc/debian-policy/ch-relationships.html Thanks. I will do that. The idea is that we add a mass of libs to be installed with the package. And using recommends does seem like the best choice. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended exectuable - packaging for Debian
On Mon, Aug 12, 2013, at 09:06 AM, IOhannes m zmölnig wrote: On 08/11/13 15:03, Kaj Ailomaa wrote: Never mind. I found an option during configuration to solve this problem. whatever you are doing, you might also want to check out how we do this in the puredata package (where pd is renamed to puredata) Thanks. I'm studying the puredata rules file. But, not sure yet if I need to use any of that. Well, maybe from where to find the changelog, and such. As is now, I can change the name of the executable with the configure option --program-suffix. The files always end up in /usr/lib/pd-extended no matter what. Should the config option also change that? However, there seems to be a bug. It changes three files, not only the executable. I solve it by using a postinst script to rename the two files that shouldn't. https://sourceforge.net/p/pure-data/bugs/1105/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-extended exectuable - packaging for Debian
Hi. I took on the task of packaging pd-extended for Debian a couple of months ago and got some help from Hans to get started. While at the Debian Conference 2013, I thought I'd try and see if I could get it ready for upload during this week. A problem I'm having is with the exectuable for pd-extended. At which end would it be best to change pd into pd-extended?. I'm thinking this is done in the makefile. Sorry to say, my knowledge of building software with the gnu tools is still elementary. How is pd-extended maintained, the source itself? The picture I got was that it's puredata plus patches by Hans. In this case, I suppose it would be good to also patch the makefile. Or, is there a reason to keep the executable pd by default? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended exectuable - packaging for Debian
Never mind. I found an option during configuration to solve this problem. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [pure-data:bugs] #1105 configure option --program-suffix adds suffixes to unwanted files
--- ** [bugs:#1105] configure option --program-suffix adds suffixes to unwanted files** **Status:** open **Labels:** pd-extended **Created:** Sun Aug 11, 2013 02:43 PM UTC by Kaj Ailomaa **Last Updated:** Sun Aug 11, 2013 02:43 PM UTC **Owner:** nobody When building pd-extended from git source, configure option --program-suffix on Linux adds suffixes to /usr/bin/pd /usr/lib/pd-extended/pd-watchdog /usr/lib/pd-extended/tcl/pd-gui.tcl Should only add a suffix to the first of those. --- Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, May 29, 2013, at 09:17 AM, IOhannes m zmoelnig wrote: i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then. one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all). I think the situation with jack is somewhat problematic, since there are now three variants of jack, where jack1 and jack2 both can be run as jackd - but jack1 and jack2 do not support the same stuff, and where jackdbus, while a form of jack2 is not operated the way jackd is. Perhaps it is a sign of an organizational problem within the jack community? I would really make things easier if there was only one jack. From pd point of view, I suppose one could argue there is only two forms of jack: jackd and jackdbus - would that be correct? Where jackd could be either jack1 or jack2. This is something I'm beginning to see as somewhat of a problem in the Linux audio community, and as the project lead of Ubuntu Studio, I'm putting it as one my goals this year to see how we who package the applications can influence the infrastructure of the audio systems for the various Linux distros - in this case Debian and its derivatives. And also how we can influence the upstream jack developers as well. Not sure if pulseaudio can be used for low latency. Haven't ever heard of anyone trying, but it is the standard sound system on most Linux distros today. Supporting it seems like a good idea. Even if you might not be able to get low latency. Since I'm not much of a coder yet, I don't know very much about how applications interact with jack. But, from a user point of view, I'd prefer pd to autostart whatever jack is installed, preferably jackdbus over jackd, for the simple reason that it offers more functionality. = About pulseaudio and jack integration (for those who are interested) pulseaudio and jack integration is getting much better. With the release of pulseaudio 3.0 a bug was fixed, allowing jack to seemlessly grab a pulseaudio reserved card. (This works for jack2 only - which as said exists in two forms: jackd and jackdbus) If having installed the jackdbus detect module (which is a part of pulseaudio source, but packaged separately), and you are running jackdbus, the module automatically creates a jack sink and source for pulseaudio, allowing the user to connect pulseaudio to jack. So, if pd is set to start jackdbus by default, it would either just cut audio from pulseaudio completely (if pulse is using the same card), or with the module - more or less seemlessly connect pulseaudio to jack, keeping desktop audio intact. There are still some problems with the module. It eats a lot of CPU. One problem is channel configuration. It's configurable nowadays, and I was able to make it default to 2 channels by default in the upstream source, which makes it go easier on the CPU, and makes it easier to use with multichannel cards (where the channel config might otherwise not make sense). It's missing the feature of profiles that audio cards otherwise have - stereo, 5.1, 7.1, etc. Another problem, which is more about convenience, is that it doesn't automatically set applications that are already streaming audio to use the jack sink and source. You need to do that manually using a pulseaudio mixer. I would say integrating pulseaudio and jack is working fairly well, but because you are dealing with two different audio systems, or three (if including alsa), as well as there being variants of jack, it is not easy to get an overview from the user point of view. There is no gui app that controls all of them. = My recommendation My recommendation at this point would be to let pd use pulseaudio by default (once it was supporting it). And if the user would set pd to use jack, it should start jackdbus if exists. And if not, jackd. In the Ubuntu Studio team, we're talking about creating a gui application for controlling jack and the integration with pulseaudio in a much less painful way. Currently, the gui controls that exist don't really do that. I believe that would help smoothen some things out a bit. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, May 29, 2013, at 05:00 PM, Jonathan Wilkes wrote: From: katja katjavet...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at pd-dev@iem.at Sent: Wednesday, May 29, 2013 8:21 AM Subject: Re: [PD-dev] jack dbus? I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear. The pulseaudio mixer allows you to set sink per application. This is under the playback tab, which only shows currently streaming applications. You can also select jack as the default output under the tab output devices, in which case all applications will use jack by default. It's the button that when hovering over it says Set as fallback. What you need to install in order for this to work automatically: jackd2 (and start jackdbus, not jackd) pulseaudio-module-jack (the jackdbus_detect module) It is possible to have PA create or destroy sink and source for jack manually as well, using the pactl tool. This will also work for jackd (jack2 only). ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
