Bug#578144: clalsadrv: Please sync latest upstream version
Package: clalsadrv Severity: wishlist I was about to update to lastest release of jaaa and it depends on recent version of this lib... Also I am about to set jaaa under maintenance by the same team (DMM) the sources are allready on alioth Regards -- http://rzr.online.fr/q/jaaa -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd1, jackd2, jackd3, tschack
Hi! Yesterday, somebody digged out Suse's announcement of our coordinated distro approach for switching to jackd2. A lot has happened during the past hours on the mailing lists and via IRC. Basically, the jackd1 camp isn't really happy. And some people think we should really provide a choice which version to use. Foremost, jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Think of exim|sendmail|qmail. So what do we have? jackd1 -- stable, containing jack_session (that's something new) tschack -- jackd1 derivative with SMP support, jack_session jackd2 -- C++ reimplementation, SMP, no jack_session yet, but on the horizon, card reservation via DBUS (pulseaudio integration) jackd3 -- upcoming C++ reimplementation of jackd1 If we can only have one jack version in Debian, we probably really use jackd2 now, mostly because of card reservation. However, this would more or less be a version lock-in. Perhaps we should free ourselves and come up with a solution that allows for different jackd implementations in Debian. Other distros can do this, too. ;) We can't make libjack0 virtual, right? Can we put everything into a single package, let's say jackd1 and jackd2, both containing the stuff which is now present in libjack0, libjack-dev and the jackd package itself? And then let them all Provide: jack-audio-connection-kit or something like this. We might even use alternatives. Could this work? If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. However, there has already been one good result: somebody is coding jack-session for jackd2 now, because if we really move to jackd2, it wouldn't make sense to only have it in jackd1. Cheerio -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
clalsadrv_2.0.0-2_amd64.changes ACCEPTED
Accepted: clalsadrv_2.0.0-2.diff.gz to main/c/clalsadrv/clalsadrv_2.0.0-2.diff.gz clalsadrv_2.0.0-2.dsc to main/c/clalsadrv/clalsadrv_2.0.0-2.dsc libclalsadrv-dev_2.0.0-2_amd64.deb to main/c/clalsadrv/libclalsadrv-dev_2.0.0-2_amd64.deb libclalsadrv2_2.0.0-2_amd64.deb to main/c/clalsadrv/libclalsadrv2_2.0.0-2_amd64.deb Override entries for your package: clalsadrv_2.0.0-2.dsc - source libs libclalsadrv-dev_2.0.0-2_amd64.deb - optional libdevel libclalsadrv2_2.0.0-2_amd64.deb - optional libs Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
On Sat, Apr 17, 2010 at 12:37:45PM +0200, Adrian Knoth wrote: jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Wauw! Please post a URL to some (more official) summary of the dispute if available somewhere. So what do we have? jackd1 -- stable, containing jack_session (that's something new) tschack -- jackd1 derivative with SMP support, jack_session jackd2 -- C++ reimplementation, SMP, no jack_session yet, but on the horizon, card reservation via DBUS (pulseaudio integration) jackd3 -- upcoming C++ reimplementation of jackd1 If we can only have one jack version in Debian, we probably really use jackd2 now, mostly because of card reservation. However, this would more or less be a version lock-in. Perhaps we should free ourselves and come up with a solution that allows for different jackd implementations in Debian. Other distros can do this, too. ;) We can't make libjack0 virtual, right? Can we put everything into a single package, let's say jackd1 and jackd2, both containing the stuff which is now present in libjack0, libjack-dev and the jackd package itself? And then let them all Provide: jack-audio-connection-kit or something like this. We might even use alternatives. Could this work? If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. How about this: 1. Rename jack as jackd1, including empty transitional packages. 2. Try package jackd2 with libraries renamed to not clash. 3. Update jackd1 to similarly use renamed libraries. That way no other packages are affected until step 3, where they need to decide which of the libraries to link against. If both implementations really do stay both ABI and API compatible that should not matter, and we can perhaps provide symlinks from one of the libraries to the old unbranched location as a convenience. I imagine that we won't do step 3 before freeze of Squeeze, but might reach the other two quickly. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
Hi guys,
I'm new to the list but joined to see if I could help with
the {j,tsch}ack{1,2,3} issue. :-)
On Sat, 17 Apr 2010, Jonas Smedegaard wrote:
On Sat, Apr 17, 2010 at 12:37:45PM +0200, Adrian Knoth wrote:
jackd2 shouldn't be considered the successor of jackd1, but an alternative
implementation.
Wauw!
Please post a URL to some (more official) summary of the dispute if available
somewhere.
It's on the jack-devel and linux-audio-dev lists on
16-Apr-2010.
LAD:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/thread.html
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027285.html
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027310.html
(***)
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-April/027316.html
Jack-Devel: (must be a member to view archives)
http://lists.jackaudio.org/private.cgi/jack-devel-jackaudio.org/2010-April/thread.html
(Most messages are the same, though.)
How about this:
1. Rename jack as jackd1, including empty transitional packages.
2. Try package jackd2 with libraries renamed to not clash.
3. Update jackd1 to similarly use renamed libraries.
If I understand correctly, the *only* packages that need to
be virtual are libjack and libjack-dev. The actual
libjack-jack1 and libjack-jack2 would then have a dependency
on the jackd implementation.
-gabriel
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
On Sat, Apr 17, 2010 at 12:37:45 (CEST), Adrian Knoth wrote: Yesterday, somebody digged out Suse's announcement of our coordinated distro approach for switching to jackd2. A lot has happened during the past hours on the mailing lists and via IRC. Basically, the jackd1 camp isn't really happy. And some people think we should really provide a choice which version to use. Foremost, jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Think of exim|sendmail|qmail. perhaps it shouldn't have been named jackd2 in the first place then, uh? So what do we have? jackd1 -- stable, containing jack_session (that's something new) tschack -- jackd1 derivative with SMP support, jack_session jackd2 -- C++ reimplementation, SMP, no jack_session yet, but on the horizon, card reservation via DBUS (pulseaudio integration) jackd3 -- upcoming C++ reimplementation of jackd1 I think this amount of variability is just madness. Do we really want to support any combination of application and jack daemon listed above? I feel we hardly manage to keep a single jack version in shape, and increasing the number of combinations to test is not going to make this easier. If we can only have one jack version in Debian, we probably really use jackd2 now, mostly because of card reservation. However, this would more or less be a version lock-in. I wouldn't necessarily consider such a lock-in as bad, as it reduces the number of tests, see above. Perhaps we should free ourselves and come up with a solution that allows for different jackd implementations in Debian. Other distros can do this, too. ;) We can't make libjack0 virtual, right? Can we put everything into a single package, let's say jackd1 and jackd2, both containing the stuff which is now present in libjack0, libjack-dev and the jackd package itself? And then let them all Provide: jack-audio-connection-kit or something like this. Technically, we could play tricks with the shlibs file, I'm doing such dirty tricks already in the FFmpeg package, and I think it could work with jack as well. For this, we would need to decide which implementation is going to provide the headers and library that shall be used for application packages at build time. The trick would be this: - rename the library package libjack0 to libjack0-jackd1 - make 'libjack0-jackd1' provide 'libjack0' - introduce other implementations in the same way, e.g., libjack0-jackd2 would provide libjack0 as well - install a (common) shlibs file in all implementations to make application packages refer to libjack0 in their dependencies - pray that we will never need to bump shlibs The obvious drawback of this madness is that we cannot use versioned dependencies anymore. E.g. newer jack libraries after 0.116.2 introduced some new symbols. If some application does not work with an earlier version than 0.116.2 of jack, then we cannot express that situation in terms of package dependencies anymore. In that case we need to rename the name of the virtual package, e.g., libjack0a and recompile the world! I don't know about the implementation of jackd1 vs. jackd2 or future implementation, but my impression of this whole mess makes me feel that something like this is not unlikely at all, despite the fact upstream is trying really hard to preserve both forward and reverse binary compatibility. And now a reality check: currently, libjack0's shlibs file looks like this: ,[/var/lib/dpkg/info/libjack0.shlibs] | libjack 0 libjack0 (= 0.118+svn3796) | libjackserver 0 libjack0 (= 0.118+svn3796) ` this means that we already declare that applications that have been built against squeeze's libjack won't work with lenny's libjack0. If this is really the case, then we have already lost. We might even use alternatives. Could this work? the Debian science team is doing something very similar to this as well. The release team first had some concerns, but eventually agreed to this approach. I'd rather like to avoid it because of the reasons outlined above. If this is too much trouble, we should stick to our jackd2 plans and wait for jackd3 to come. this would only defer the problem to later, AFAIUI. I'm thinking about something like the nvidia vdpau approach: introduce a new abstraction lib, that checks at runtime for available real implementations and uses them then. But given that the jack API is not exactly trivial, this might be infeasible as well :-( However, there has already been one good result: somebody is coding jack-session for jackd2 now, because if we really move to jackd2, it wouldn't make sense to only have it in jackd1. How about implementing a pulseaudio module that implements the jack ABI? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org
packaging jack...
hi... i just want to make sure you leave the option open to package alternative jack versions. adi said that you somehow seem to believe that there cant be virtual packages containing libraries. this is not true. if you create debian/libjack0.shlibs and put --- libjack 0 WHATEVER in it, this will get installed into /var/libs/dpkg/info/libjack0.shlibs and it will result in dh_shlibs generating WHATEVER as a dependency when it encouters something linked against libjack.so.0 so its pretty easy to make libjack0 a virtual package. we already have 3 implementations of jack which are all ABI compatible. and we really want users to be able to use them. its fine if the default is jack2. but please leave the door open for people who have problems with jack2 and are better off with tschack. we (upstream) will make sure they are binary compatible. all symbols added since jack-0.116 are mandated to be weak. if there are any issues with binary compatibility these are bugs. -- torben Hohn ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
LASH - updated package for squeeze
Hi, I would be happy to get lash (adopted package) updated for squeeze. The upload would fix these bugs: 547032, 548432, 550636, 553794, 555075, 557491 If someone is interested upload this package please use files from debian-mentors: http://mentors.debian.net/debian/pool/main/l/lash/ There is problem with md5 in git repository (will be solved by uploading new upstream release). best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: LASH - updated package for squeeze
Hi Mira (and others), On Sat, Apr 17, 2010 at 03:54:23PM +0200, Jaromír Mikeš wrote: I would be happy to get lash (adopted package) updated for squeeze. I'll have a look on this as soon as I have updated morituri. (looks like jack packaging needs nore discussion) The upload would fix these bugs: 547032, 548432, 550636, 553794, 555075, 557491 Great! If someone is interested upload this package please use files from debian-mentors: http://mentors.debian.net/debian/pool/main/l/lash/ No need to use mentors: we are a team! :-) Please update the git at git.debian.org:/git/pkg-multimedia/lash instead. If you do not have write access to that, then let us help guide you to get access. There is problem with md5 in git repository (will be solved by uploading new upstream release). Ok. Thanks for mentioning. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578161: liblivemedia-dev: GPL patch is incompatible with LGPL distribution
Package: liblivemedia-dev Version: 2010.02.10-1 Severity: serious Justification: Policy 2.3 Hello, The liblivemedia-dev packages applies a patch explicitly licensed under the GPL. In my understanding, this makes the resulting binaries GPL. Yet the copyright file claims Debian provides the package under LGPL. Please remove the setlocale patch or fix the licensing informations. Thanks in advance, -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (100, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32.9 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578161: liblivemedia-dev: GPL patch is incompatible with LGPL distribution
On Sat, Apr 17, 2010 at 07:26:52PM +0300, Rémi Denis-Courmont wrote: Le samedi 17 avril 2010 18:11:07 Reinhard Tartler, vous avez écrit : The patch in question [1] seems to be written by you and Felix last year. Would you and Felix be willing to relicense the patch under LGPL? I will relicense to LGPL if/when upstream live uses a publicly accessible source control system with an open protocol. He refused to do that [1], and hence I am unwilling to cooperate. [1] http://lists.live555.com/pipermail/live-devel/2009-December/011590.html This would not require applications that use liblivemedia to be licensed under the GPL as well. Debian (and I assume Ubuntu) only use live555 from VLC and MPlayer. Both of those are already GPL'd, so that's not really an issue. dvswitch's development branch also uses it. Not yet in Debian and also GPL, but, just to say there are more than 2 apps ... -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#568272: mplayer: Overwrites configuration file it generated itself
On Wed, Feb 03, 2010 at 16:57:50 (CET), Josselin Mouette wrote: Package: mplayer Version: 1.0~rc3+svn20090405-1+b1 Severity: serious After an upgrade from lenny, mplayer asked for a conffile replacement, in /etc/mplayer.conf. However I never touched this file, it was generated by mplayer itself using the debconf configuration. Can you please send me the md5sum of the conffile that was generated for you in the default install? I'll add it then to our maintainer scripts to avoid this conffile prompt. This package probably needs to use ucf to detect whether this file was changed from the debconf-generated one. lenny's mplayer package used debconf to ask various weird questions. Since then, we just install a default config file with sane defaults and rely on dpkg's conffile mechanism. This should in the long run cause less trouble, but for the lenny-squeeze upgrade, I agree that this is unpleasent. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd1, jackd2, jackd3, tschack
On Sat, Apr 17, 2010 at 03:17:46PM +0200, Reinhard Tartler wrote: On Sat, Apr 17, 2010 at 12:37:45 (CEST), Adrian Knoth wrote: Yesterday, somebody digged out Suse's announcement of our coordinated distro approach for switching to jackd2. A lot has happened during the past hours on the mailing lists and via IRC. Basically, the jackd1 camp isn't really happy. And some people think we should really provide a choice which version to use. Foremost, jackd2 shouldn't be considered the successor of jackd1, but an alternative implementation. Think of exim|sendmail|qmail. perhaps it shouldn't have been named jackd2 in the first place then, uh? yeah. it shouldnt. but at the time that happened it seemed right to the people in charge. jackdmp was the only other implementation and being SMP capable and in c++ it seemed right to them. So what do we have? jackd1 -- stable, containing jack_session (that's something new) tschack -- jackd1 derivative with SMP support, jack_session jackd2 -- C++ reimplementation, SMP, no jack_session yet, but on the horizon, card reservation via DBUS (pulseaudio integration) jackd3 -- upcoming C++ reimplementation of jackd1 I think this amount of variability is just madness. Do we really want to support any combination of application and jack daemon listed above? I feel we hardly manage to keep a single jack version in shape, and increasing the number of combinations to test is not going to make this easier. i wouldnt advocate you support any combination. i just want that you leave the door open for people who want to install an alternative. iE right now tschack didnt have its share of broad testing. i have around 10 users. and these confirm that it works better than jack2. thats by no means representative. (and having problems with jack2 drove them to using tschack... so far this is a 100% success rate that it indeed fixed peoples problems with jack2) i myself dont have problems with jack2 (except its codebase ;) so if i were to play a gig, i would use jack2 since its got a broader testing) If we can only have one jack version in Debian, we probably really use jackd2 now, mostly because of card reservation. However, this would more or less be a version lock-in. I wouldn't necessarily consider such a lock-in as bad, as it reduces the number of tests, see above. i am not advocating that you use a broader testing base. i dont even mind you really do the switch and drop jack1. but you should still leave the door open via a virtual libjack0 dependency so that its possible to provide alternative jack packages. Perhaps we should free ourselves and come up with a solution that allows for different jackd implementations in Debian. Other distros can do this, too. ;) We can't make libjack0 virtual, right? Can we put everything into a single package, let's say jackd1 and jackd2, both containing the stuff which is now present in libjack0, libjack-dev and the jackd package itself? And then let them all Provide: jack-audio-connection-kit or something like this. Technically, we could play tricks with the shlibs file, I'm doing such dirty tricks already in the FFmpeg package, and I think it could work with jack as well. For this, we would need to decide which implementation is going to provide the headers and library that shall be used for application packages at build time. The trick would be this: - rename the library package libjack0 to libjack0-jackd1 - make 'libjack0-jackd1' provide 'libjack0' - introduce other implementations in the same way, e.g., libjack0-jackd2 would provide libjack0 as well - install a (common) shlibs file in all implementations to make application packages refer to libjack0 in their dependencies - pray that we will never need to bump shlibs The obvious drawback of this madness is that we cannot use versioned dependencies anymore. E.g. newer jack libraries after 0.116.2 introduced some new symbols. If some application does not work with an earlier version than 0.116.2 of jack, then we cannot express that situation in terms of package dependencies anymore. In that case we need to rename the name of the virtual package, e.g., libjack0a and recompile the world! all these symbols after 0.116.0 are weak. and they are only optional stuff. every app needs to check for their presence and would only activate some functionality if it finds these symbols. and app using these symbols without checking is buggy. I don't know about the implementation of jackd1 vs. jackd2 or future implementation, but my impression of this whole mess makes me feel that something like this is not unlikely at all, despite the fact upstream is trying really hard to preserve both forward and reverse binary compatibility. And now a reality check: currently, libjack0's shlibs file looks like this: ,[/var/lib/dpkg/info/libjack0.shlibs] | libjack 0
Processed: found 524805 in 1.0~rc2-17
Processing commands for cont...@bugs.debian.org: found 524805 1.0~rc2-17 Bug #524805 [mplayer] mplayer: CVE-2009-0385 integer signedness error Bug Marked as found in versions mplayer/1.0~rc2-17. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote: we (upstream) will make sure they are binary compatible. all symbols added since jack-0.116 are mandated to be weak. if there are any issues with binary compatibility these are bugs. Sounds like a promise of a stable API. How about then bumping the API from 0 to 1? (sorry if my question is silly - I am a scripter, not a C/C++ coder) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
aeolus_0.8.4-1_amd64.changes ACCEPTED
Accepted: aeolus_0.8.4-1.diff.gz to main/a/aeolus/aeolus_0.8.4-1.diff.gz aeolus_0.8.4-1.dsc to main/a/aeolus/aeolus_0.8.4-1.dsc aeolus_0.8.4-1_amd64.deb to main/a/aeolus/aeolus_0.8.4-1_amd64.deb aeolus_0.8.4.orig.tar.gz to main/a/aeolus/aeolus_0.8.4.orig.tar.gz Override entries for your package: aeolus_0.8.4-1.dsc - source sound aeolus_0.8.4-1_amd64.deb - extra sound Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
On Sat, Apr 17, 2010 at 09:48:41PM +0200, Reinhard Tartler wrote: On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote: On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote: we (upstream) will make sure they are binary compatible. all symbols added since jack-0.116 are mandated to be weak. if there are any issues with binary compatibility these are bugs. Sounds like a promise of a stable API. How about then bumping the API from 0 to 1? if you mean the SONAME, then you would require rebuilding all applications for no reason. There is absolutely no need for this. Then packages could depend unversioned on libjack1, instead of versioned on libjack0 = 0.116.0. That would make it possible to offer alternative jackd implementations: Alternative implementations simply should not provide a *-dev package, to enforce build-depending against the main jackd implementation (for now that means jakcd1, might change to a different one in the future). I suspect that is the simplest approach to multiple jack implementations in Debian. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
On Sat, 17 Apr 2010, Jonas Smedegaard wrote: stop right here. the library and the daemon are tied together. the protocol between jackd and libjack is NOT fixed. (basically i consider it a mistake to even have libjack and jackd in different packages) but it might make sense to have that. The separation of library and daemon is so that an application can link against the library without forcing the daemon to be installed: the JACK support might be optional for that application (without it being a plugin that can be packaged separately from the main application. When you register with libjack, it will start the daemon if it is not already running. So, you can't have the library without the daemon.[*] -gabriel [*] There is a trivial case where an application is using libjack only for the ringbuffer implementation. This wouldn't require the daemon, and I doubt that any applications are /only/ using this part. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
On Sat, 17 Apr 2010, Jonas Smedegaard wrote: When you register with libjack, it will start the daemon if it is not already running. So, you can't have the library without the daemon.[*] That sounds like trouble: if such application is invoked inside a chroot, it causes a mess! Debian mandates ability to enforce daemons to not be started (it is called policy.d - see e.g. the Debian package policyrcd-script-zg2 for more info (and probably somewhere in Debian Policy itself - too lazy to look it up right now). jackd is not Not NOT a system daemon and should never be started by an rc.d script. jackd is a user daemon that should started and stopped by a normal user. -gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of ffmpeg-debian_0.svn20080206-18+lenny1_amd64.changes
ffmpeg-debian_0.svn20080206-18+lenny1_amd64.changes uploaded successfully to localhost along with the files: ffmpeg-debian_0.svn20080206-18+lenny1.dsc ffmpeg-debian_0.svn20080206.orig.tar.gz ffmpeg-debian_0.svn20080206-18+lenny1.diff.gz ffmpeg_0.svn20080206-18+lenny1_amd64.deb ffmpeg-dbg_0.svn20080206-18+lenny1_amd64.deb ffmpeg-doc_0.svn20080206-18+lenny1_all.deb libavutil49_0.svn20080206-18+lenny1_amd64.deb libavcodec51_0.svn20080206-18+lenny1_amd64.deb libavdevice52_0.svn20080206-18+lenny1_amd64.deb libpostproc51_0.svn20080206-18+lenny1_amd64.deb libavformat52_0.svn20080206-18+lenny1_amd64.deb libswscale0_0.svn20080206-18+lenny1_amd64.deb libavutil-dev_0.svn20080206-18+lenny1_amd64.deb libavcodec-dev_0.svn20080206-18+lenny1_amd64.deb libavdevice-dev_0.svn20080206-18+lenny1_amd64.deb libpostproc-dev_0.svn20080206-18+lenny1_amd64.deb libavformat-dev_0.svn20080206-18+lenny1_amd64.deb libswscale-dev_0.svn20080206-18+lenny1_amd64.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack...
On Sat, Apr 17, 2010 at 04:01:17PM -0500, Gabriel M. Beddingfield wrote: On Sat, 17 Apr 2010, Jonas Smedegaard wrote: When you register with libjack, it will start the daemon if it is not already running. So, you can't have the library without the daemon.[*] That sounds like trouble: if such application is invoked inside a chroot, it causes a mess! Debian mandates ability to enforce daemons to not be started (it is called policy.d - see e.g. the Debian package policyrcd-script-zg2 for more info (and probably somewhere in Debian Policy itself - too lazy to look it up right now). jackd is not Not NOT a system daemon and should never be started by an rc.d script. jackd is a user daemon that should started and stopped by a normal user. I know it is not a system daemon. If policy.d only is tied only to sysV scripts then I apologize for causing confusion: I do *not* mean to say that jack should be handled as a sysV system daemon. My point is that even as a user-invoked daemon I still believe that it should be possible to suppress it due to being a daemon. I believe (but have now investigated) that user dbus (in addition to system dbus) is can be suppressed too, for the same reason. It has been some time since I looked at this last: When using diskless systems like LTSP this issue becomes relevant. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: RELEASE: Morituri 0.1.1 'Dead'
On Sat, Apr 17, 2010 at 12:51:17AM +0200, tho...@apestaart.org wrote: This mail announces the release of Morituri 0.1.1 'Dead'. Unfortunately there seem to be a fatal (for Debian packaging) bug: Your build routines seem to now require unicode-enabled terminal (earlier only required for regression tests) not possible to ensure on Debian build daemons. Please make it possible to do normal builds on an ascii terminal - and preferrably also the regression tests, allowing me to enable those on normal builds for Debian. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: RELEASE: Morituri 0.1.1 'Dead'
Yikes. Why anyone would choose to run things in a non-utf-8 locale these days is beyond me. However, especially for this case I just commited revision 401. It seems to work for me, I ran make distcheck with LANG=C Feel free to carry that revision as a patch for now, or alternatively disable epydoc builds since really the docs are internal anyway and should not be packaged. Consequently, the testsuite now requires twisted and trial to support skipping tests. Thomas On Sat, 2010-04-17 at 23:33 +0200, Jonas Smedegaard wrote: On Sat, Apr 17, 2010 at 12:51:17AM +0200, tho...@apestaart.org wrote: This mail announces the release of Morituri 0.1.1 'Dead'. Unfortunately there seem to be a fatal (for Debian packaging) bug: Your build routines seem to now require unicode-enabled terminal (earlier only required for regression tests) not possible to ensure on Debian build daemons. Please make it possible to do normal builds on an ascii terminal - and preferrably also the regression tests, allowing me to enable those on normal builds for Debian. Kind regards, - Jonas -- Oh what do you do when you feel like you're living a lie -- Flumotion - the only way to stream! http://www.flumotion.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of ams_2.0.1-3_amd64.changes
ams_2.0.1-3_amd64.changes uploaded successfully to localhost along with the files: ams_2.0.1-3.dsc ams_2.0.1-3.diff.gz ams_2.0.1-3_amd64.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of morituri_0.1.1-1_amd64.changes
morituri_0.1.1-1_amd64.changes uploaded successfully to localhost along with the files: morituri_0.1.1-1.dsc morituri_0.1.1.orig.tar.bz2 morituri_0.1.1-1.debian.tar.gz morituri_0.1.1-1_all.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
ams_2.0.1-3_amd64.changes ACCEPTED
Accepted: ams_2.0.1-3.diff.gz to main/a/ams/ams_2.0.1-3.diff.gz ams_2.0.1-3.dsc to main/a/ams/ams_2.0.1-3.dsc ams_2.0.1-3_amd64.deb to main/a/ams/ams_2.0.1-3_amd64.deb Override entries for your package: ams_2.0.1-3.dsc - source sound ams_2.0.1-3_amd64.deb - optional sound Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
