Processed: Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages
Processing commands for cont...@bugs.debian.org: reassign 589689 release.debian.org Bug #589689 [jackd2] transition to libjack-jackd2-0 breaks many packages Bug reassigned from package 'jackd2' to 'release.debian.org'. stop Stopping processing here. Please contact me if you need assistance. -- 589689: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589689 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#589689: transition to libjack-jackd2-0 breaks many packages
reassign 589689 release.debian.org stop On Tue, Jul 20, 2010 at 01:23:27 (CEST), Pedro R wrote: Package: jackd2 Severity: grave Tags: sid Justification: renders package unusable Hi, the recent transition to jackd2 causes a mess in my system. Yes, that is sort-of expected. I don't want to downgrade to jackd2. This doesn't make sense. I assume that you meant jackd1 here. After being forced to use it for a couple of months, I find it is much more reliable. Yes, that's why we want to ship it as default jackd flavor in squeeze. However, we discovered that squeeze is better off with both jackd1 and jackd2 versions, and have applications compiled against libjack0 from the jackd1 package. If I try to install jackd2 by hand, it forces me to uninstall jackd1 plus loads of packages, including mplayer, aqualung, alsaplayer, gstreamer-plugins, libpurple, pidgin, libxine, xine-ui, vdr plugins and many others. Those packages need to be rebuilt against the updated jackd1 package. The release team is already on it with scheduling binNMUs. I'm therefore reassigning this issue to release.debian.org so that we can reuse this bug for tracking purposes. please CC pkg-multimedia-maintainers@lists.alioth.debian.org in your followups. -- 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: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jonas and the team, I'm finally managing to put some more time on this. I spent a few weeks without much Internet access. Meanwhile, we applied you patch upstream and made a new release. There are issues to fix, though, since we changed the way the Python is packaged with autotools. On 10-06-21 12:04 PM, Jonas Smedegaard wrote: On Mon, Jun 21, 2010 at 10:58:47AM -0400, Alexandre Quessy wrote: What I know for sure, is that the Python modules are not shipped with any Debian package anymore. :( Yeah, I did not dispute that, and do not even claim to know for sure that your attempts are wrong, only that they _seem_ wrong from a quick glance. When the below build problems have been solved or worked around, I can actually build some packages and _then_ help figure out how to solve above issue. Hmmm. Actually, our release doesn't quit fix these. I guess it's better to apply patches and then push them upstream. (remove my author hat, and wear the packager one) You were right about this. Python scripts are invoked directly, causing default Python to always be used, ignoring autotools $(PYTHON) variable. This is only an issue on systems that wants to build for a non-default Python version (i.e. not currently a problem with Debian). I believe the best fix is to use the autotools-provided $(PYTHON) (and the related python prefix variable - I forgot its variable name) to compose the hashbang from a .in file of the scripts, instead of the current /usr/bin/env python construct. Reading the automake manual (#1) I guess it could be $(PYTHON_VERSION). #1: http://www.gnu.org/software/hello/manual/automake/Python.html Since the scripts have some automake variables already expanded, I could put #!/usr/bin/python@@PYTHON_VERSION@@ there, or something similar? I am no expert in autotools, so do not know what is the most proper or elegant approach. I just wanted to point out that to me it seems the problem lies somewhere in the autotools files. If (as is seems) you are not familiar with (Python-specific parts of) autotools either, then I suggest looking at other project for inspiration on how they do things, and use official documentation only for reference and verification rather than as educational tool. I will ask around for help on this. Python scripts rely on local modules that are a) not declared and b) not yet built. I fixed a) with a patch, but b) still fails. I believe the help2man rules need to depend on module building, and the patch then changed to use build dir instead of source dir (which is wrong to use in any case). I think this is the most critical issue right now. Indeed: This is what made me give up for now trying to actually fully build packages so that I could help figure out how to most properly include the Python parts. Help2man calls the Python scripts, which it turn makes Python byte-compile the modules with the wrong Python version. (?) To fix this, the man page rule in man/Makefile.am should depend on building the Python modules. What target would that be ? scenic_PYTHON and rtpmidi_PYTHON ? Sorry - don't know :-( . But sounds like you are looking in the right direction (if that is of any help or at least of some encouragement). Ah! We thought about putting the call to help2man in the make dist target, not make. We would put them in the tarball, but they would not be rebuilt when running git-buildpackage. That would solve this issue. (the *.pyc files are not distributed in the tarball) Another more annoying issue is that upstream autotools do not use AM_MAINTAINER_MODE, causing normal builds to regenerate autotools if too old which might happen accidentally, especially when using a VCS as we do. The fix upstream is simple: Add AM_MAINTAINER_MODE to configure.am and all should be fine. Until then we need to do a clumsy workaround of preserving upstream autotools and restoring in our clean rule. I just filled a bug (#2) report upstream about it. It will be in the next release. Fixed in upstream 0.6.3. Ok, so we have two major bugs to fix. 1) Call help2man in the make dist target and distribute the man pages in the tarball. 2) Replace the shebang by the proper Python version It seems to me that packaging Python stuff is so difficult that it's what is actually slowing down the whole release of the next stable Debian. At least, that's my impression reading http://en.wikipedia.org/wiki/Debian#Release_history Not giving up! Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMRcnWAAoJEJQ0pOgl2qx1iTUP+wfk66Z0apOjQ+mO84KbU/8U tNuMD2Vzabzo+aWvQ+m/wgbQGaNJHAPTfN2nx0puWwR7R5AeBehkZVD37kq+BGmM CfOvznxMrZfiriJZvlrx+sF7uVIciDVbXmh/9oo/XhS/Ps59cHBIx0e4hA+BF7E6 v+U8ufPlD79tZR7Rxyg+4sT5tj/fOWDD0Od+y5RnNCNB/tlVxDOhgac00sUhiMUA
Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages
I don't want to downgrade to jackd2. This doesn't make sense. I assume that you meant jackd1 here. Yes, that's what I meant. Yes, that's why we want to ship it as default jackd flavor in squeeze. However, we discovered that squeeze is better off with both jackd1 and jackd2 versions, and have applications compiled against libjack0 from the jackd1 package. Can't you run apps compiled against libjack0 with libjack-jackd2-0? That probaby works, since the interface is the same. Or am I completely off the mark here? Those packages need to be rebuilt against the updated jackd1 package. The release team is already on it with scheduling binNMUs. I'm therefore reassigning this issue to release.debian.org so that we can reuse this bug for tracking purposes. please CC pkg-multimedia-maintainers@lists.alioth.debian.org in your followups. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 Thanks for letting me know, and thank you for your work in Debian. Regards, Pedro ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again, I just remebered that the man page bug has been fixed upstream! They are now distributed with the tarball, and not rebuilt by git-buildpackage. On 10-07-20 12:07 PM, Alexandre Quessy wrote: Ok, so we have two major bugs to fix. 1) Call help2man in the make dist target and distribute the man pages in the tarball. 2) Replace the shebang by the proper Python version We still need to set up the /usr/bin/python2.6 thing. Also, I have problems with installing the Python modules in the right package. (the scenic and midistream binary packages are the ones that contain Python modules. Namely the scenic and midistream modules) a -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMRcvmAAoJEJQ0pOgl2qx1eYEP/RRuMKZAi/WhkKJ6QaqZqHZB asyGtiK2hyr9zMQSJ/ORfQnvxm+o0YCgSqtuOOcdmSt2Vcpq2asqRxsGrKxBRgSK xNE4+znU7jjnhJ3r0ywBIQNxDCN4H0W2VqTjfzT4Q349GHEDH4/QJToJi9Zsefst KUwxCxKcKP/QUFvo6KJ2JOzucNLJFY/4gsa0XIaOlQX2u3EEMt08sqhLSpayLc5H NRl8YDaFddNzB1n2rmf+F2MSiOzsfLZwqNUJRcrQrO6+Xn7e0H5SdGFBXP47oVNN ALhZy94Y0pzAX5fVD7OQApvYS7+PrPOa0bimMx9TPJN9zA/Y9MKt5+8LqiEL1fVl y5cfjzGdMcZaUj5qcDFRTsIx1V+EAyfKD079vxvAELNSKhmOY4Q5nCaA3X5+qZSA xlQODCWDT0Qrvo/lG+EnZMRv/sH8aori9bi1JiH/ovMJqxMg8exTMTVzXptdSG4e 9L01AkvanCi1w7aGzKZJJPTq1fAy4PwxpTSWTBRjxPDuozKLB5ECd27HUT5WV+b3 qboDesZezoZ8btBm2vN2qU0jOXAkjAjJ37CL9EHZPudTUjdN3AXypDqa85BzDJ2+ Ltz/7uJYxTzO8UW7r81aD7WR3v4gIsmQ/7vJPJ4gNYWYo77FzfQ3z2b+cGAHkLb2 fFGDpDmhrztqp1EIc331 =SXIC -END PGP SIGNATURE- ___ 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-3 MIGRATED to testing
FYI: The status of the clalsadrv source package in Debian's testing distribution has changed. Previous version: 2.0.0-2 Current version: 2.0.0-3 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
mhwaveedit 1.4.19-1 MIGRATED to testing
FYI: The status of the mhwaveedit source package in Debian's testing distribution has changed. Previous version: 1.4.15-2 Current version: 1.4.19-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackeq 0.4.1-2 MIGRATED to testing
FYI: The status of the jackeq source package in Debian's testing distribution has changed. Previous version: 0.4.1-1 Current version: 0.4.1-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] projectm packaging branch, master, updated. upstream/2.0.1+dfsg-50-ge93b6ff
On Tue, Jul 20, 2010 at 17:42:51 (CEST), ximion-gu...@users.alioth.debian.org
wrote:
The following commit has been merged in the master branch:
commit e93b6ff9e70186f5fafef5e1c3da94d07829872c
Author: Matthias Klumpp matth...@nlinux.org
Date: Tue Jul 20 17:42:18 2010 +0200
Added get-orig-source script
* Included script to build a DFSG-compliant
tarball from original upstream tar.
diff --git a/debian/get-orig-source.sh b/debian/get-orig-source.sh
new file mode 100755
index 000..31ac732
--- /dev/null
+++ b/debian/get-orig-source.sh
@@ -0,0 +1,101 @@
+#!/bin/sh
+#
+# Script to create a 'pristine' tarball for the debian projectM source
package
+# Copyright (C) 2010 Matthias Klumpp
+# based on script by Reinhard Tartler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+set -eu
+
+usage() {
+ cat 2 EOF
+usage: $0 [-dh]
+ -h : display help
+ -t : original upstream tarball
+ -o : output tarball name
+ -v : upstream version
+ -c : path to cleanup script
+EOF
+}
+
+debug () {
+ $DEBUG echo DEBUG: $* 2
+}
+
+error () {
+ echo $1 2
+ exit 1;
+}
+
+set +e
+PARAMS=`getopt ht:v: $@`
+if test $? -ne 0; then usage; exit 1; fi;
+set -e
+
+eval set -- $PARAMS
+
+DEBUG=false
+USVERSION=2.0.1
+
+while test $# -gt 0
+do
+ case $1 in
+ -h) usage; exit 1 ;;
+ -t) ORIGTAR=$2; shift ;;
+ -v) USVERSION=$2; shift ;;
+ --) shift ; break ;;
+ *) echo Internal error! ; exit 1 ;;
+ esac
+ shift
+done
+
+# sanity checks now
+dh_testdir
+
+if [ -z $ORIGTAR ]; then
+ error you need to specify the original upstream tarball!
+fi
this totally changes the semantics of what I'd expect from a
get-orig-source target. The purpose of the get-orig-source.sh script was
to fetch the source from the internet, while strip.sh is meant to be run
in the temporary directory and is called by get-orig-source.sh.
Please either follow that philosophy or rename the script to something
that matches its intend better in order to avoid future confusion.
thanks.
+
+PACKAGENAME=projectm
+TARBALL=./${PACKAGENAME}_${USVERSION}+dfsg.orig.tar.gz
+
+TMPDIR=`mktemp -d`
+trap 'rm -rf ${TMPDIR}' EXIT
+
+mkdir ${TMPDIR}/${PACKAGENAME}
+ODIR=`pwd`
+cd ${TMPDIR}/${PACKAGENAME}
+tar xzf ${ORIGTAR}
+cd projectM-complete-${USVERSION}-Source
+
+rm -rf ./src/WinLibs
+rm -rf ./src/macos
+rm -rf ./src/win32
+rm -f ./src/projectM-sdlvis/a.out
+rm -rf ./presets_test
+rm -f ./INSTALL-iTunes-macos.txt
+rm -rf ./playlists
+rm -rf ./src/projectM-iTunes-VizKit
+rm -rf ./src/projectM-iTunes
+rm -rf ./src/projectM-moviegen
+rm -rf ./src/projectM-screensaver
+rm -rf ./src/projectM-wmp
+find . -type d -name CVS -exec rm -rf {} +
+find . -type d -name *~ -exec rm {} +
+
+cd ${ODIR}
+
+tar czf ${TARBALL} -C ${TMPDIR} ${PACKAGENAME}
diff --git a/debian/rules b/debian/rules
index 0523ceb..86ee035 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,7 @@ BUILD_DIR=$(CURDIR)/src/build
%:
dh $@
-.PHONY: override_dh_strip
+.PHONY: override_dh_strip get-orig-source
is this intentional? I don't see a get-orig-source target here?
override_dh_auto_clean:
[ ! -f $(BUILD_DIR) ] || $(MAKE) --directory=$(BUILD_DIR) clean
@@ -37,12 +37,3 @@ override_dh_auto_install:
override_dh_strip:
dh_strip --dbg-package=projectm-dbg
-
-upstream:
- rm -rf $(CURDIR)/src/WinLibs
- rm -rf $(CURDIR)/src/macos
- rm -rf $(CURDIR)/src/win32
- rm -f $(CURDIR)/src/projectM-sdlvis/a.out
- rm -rf $(CURDIR)/presets_test
- find . -type d -name CVS -exec rm -rf {} +
- find . -type d -name *~ -exec rm {} +
--
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: [SCM] projectm packaging branch, master, updated. upstream/2.0.1+dfsg-50-ge93b6ff
[snip] this totally changes the semantics of what I'd expect from a get-orig-source target. The purpose of the get-orig-source.sh script was to fetch the source from the internet, while strip.sh is meant to be run in the temporary directory and is called by get-orig-source.sh. Please either follow that philosophy or rename the script to something that matches its intend better in order to avoid future confusion. I cannot fetch the source from web, cause wget can't handle the weird mirror system of Sourceforge. I could just fetch the stuff from SVN. I'll rename the script then. -.PHONY: override_dh_strip +.PHONY: override_dh_strip get-orig-source is this intentional? I don't see a get-orig-source target here? It's not. The next commit fixes this too. Thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hi Alexandre (and others following this thread), On Tue, Jul 20, 2010 at 12:16:38PM -0400, Alexandre Quessy wrote: I just remebered that the man page bug has been fixed upstream! They are now distributed with the tarball, and not rebuilt by git-buildpackage. On 10-07-20 12:07 PM, Alexandre Quessy wrote: Ok, so we have two major bugs to fix. 1) Call help2man in the make dist target and distribute the man pages in the tarball. 2) Replace the shebang by the proper Python version We still need to set up the /usr/bin/python2.6 thing. Also, I have problems with installing the Python modules in the right package. (the scenic and midistream binary packages are the ones that contain Python modules. Namely the scenic and midistream modules) Do you mean we as upstream or hack it in packaging? - 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: Bug#589689: transition to libjack-jackd2-0 breaks many packages
On Tue, Jul 20, 2010 at 05:13:23PM +0100, Pedro Ribeiro wrote: Yes, that's why we want to ship it as default jackd flavor in squeeze. However, we discovered that squeeze is better off with both jackd1 and jackd2 versions, and have applications compiled against libjack0 from the jackd1 package. Can't you run apps compiled against libjack0 with libjack-jackd2-0? That probaby works, since the interface is the same. Or am I completely off the mark here? It works (on the library level), but the packages need to depend on the newly introduced virtual package libjack-0.116 which is provided by either libjack0 or libjack-jackd2-0. (to be precise, they'll depend on (libjack-jackd2-0 | libjack-0.116), and that's what the binNMUs are for) For more information, see the rather lengthy http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583916 and the even longer discussion on the pkg-multimedia-maintainer mailing list. (trust me, you don't want to read this, it took us some 200 mails or more to agree on the right strategy. We now believe we got it right ;) ) HTH -- 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
Bug#578150: closable?
Hi. It seems 0.1.1 has been packaged?! Can we close this? btw: Are you going to incorporate the upstream svn changes? And are there any plans to package python-pycdio ? Cheers, Chris. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578150: marked as done (please package new upstream version 0.1.1)
Your message dated Wed, 21 Jul 2010 00:54:49 +0200 with message-id 20100720225449.gd5...@jones.dk and subject line Re: Bug#578150: closable? has caused the Debian Bug report #578150, regarding please package new upstream version 0.1.1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 578150: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578150 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: morituri Version: 0.1.0-1 Severity: wishlist Thomas has kindly sent us the announcement of a new upstream version of morituri. I'm herby converting it to a wishlist bug. See the attached mail: ---BeginMessage--- This mail announces the release of Morituri 0.1.1 'Dead'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket morituri is a CD ripper aiming for accuracy over speed. Its features are modeled to compare with Exact Audio Copy on Windows. This is morituri 0.1.1 Dead. This is intended as a release for daring and curious people who've had enough of the fact that Windows has a more accurate CD ripper than Linux. Coverage in 0.1.1: 64 % (1575 / 2440), 61 python tests Features added in 0.1.1: - added 'rip image encode' command to encode an image to a lossy codec. - provided lossy codec profiles for vorbis, mp3, and mp3vbr - added a complete list of known drive offsets from AccurateRip - added a generated man page - better exception handling in tasks - tag audio files with musicbrainz id's - added 'rip image retag' command to retag audio files in an image Bugs fixed in 0.1.1: - 11: AccurateRip failure on similar URL - 12: morituri: 'rip -h' shows gstreamer help, not morituri help, but 'rip help' works fine. - 14: AttributeError: 'NoneType' object has no attribute 'name' - 16: Fatal error passing unescaped unicode strings to GStreamer - 17: Incorrect file permissions - 19: Use sortname in filenames morituri 0.1.1 is brought to you by: Peter Oliver Thomas Vander Stichele ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ---End Message--- -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ---End Message--- ---BeginMessage--- On Tue, Jul 20, 2010 at 10:24:39PM +, Christoph Anton Mitterer wrote: It seems 0.1.1 has been packaged?! Can we close this? Ah, yes. Thanks for noticing. Closed now. btw: Are you going to incorporate the upstream svn changes? No, I currently do not intend to track unreleased code. And are there any plans to package python-pycdio ? No concrete plans, no. But I could probably be convinced to do it - especially if helped a bit: First step is to file an ITP. If you do so, feel free to include me or this list as pseudo-cc to the bugreport to remind me/us of it :-) - 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 ---End Message--- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
