Processing of bristol_0.60.4-1_amd64.changes
bristol_0.60.4-1_amd64.changes uploaded successfully to localhost along with the files: bristol_0.60.4-1.dsc bristol_0.60.4.orig.tar.gz bristol_0.60.4-1.diff.gz bristol_0.60.4-1_amd64.deb bristol-data_0.60.4-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
Re: Request to join the Debian Multimedia Team
On Fr, Mai 28, 2010 at 21:01:04 (CEST), Alexandre Quessy wrote: Hello, I want to join the Debian Multimedia Package Maintainers Team. (whatever it's called) My alioth username is alexandrequessy-guest. I've just added you to the team, welcome on board. I assume that you have already read and understood our wiki pages: http://wiki.debian.org/DebianMultimedia http://wiki.debian.org/DebianMultimedia/DevelopPackaging They are certainly not perfect and need improvements/polishing, but they at least should document the most important things we've agreed on in the past. Please help us to improve them by discussions and/or edits! My name is Alexandre Quessy. I am a developer from Montreal. I am interested in free software for new media arts, nameyl audio, video and electronics. I have been using free software for many years now. I am the co-author of some free software projects such as those listed above. I am mostly interested in the Python and C++ languages. Amongst the tools I like are Twisted, GTK+, GStreamer, gettext, the GNU Autotools, bash and vim. I have a strong background in image processing, music theory, web development, communication protocols and software process management. Sounds cool! Are you also familiar with packaging python applications? I have to admit that I've lost my interest because of the internal python affair and helper scripts war, so I more or less try to avoid such packages. Having someone on the team that knows how do package python apps properly would be a great benefit for pkg-multimedia! I also see that you are familiar with jack. The most pressing question is to if we do want to enable users to switch their jack implementation in squeeze. Currently that's not possible, but ideas how to rearrange packages, shlibs files and provides have been proposed. I have to admit that I've lost track and don't know if they are still being considered of if everyone has lost motivation to actually implement them. Perhaps you (or someone else) can try to pickup that discussion? I've already announced on #debian-release a few days ago that we might require such a transition, but we'd also need to write a more formal email to debian-release for that. I am motivated to become a Debian maintainer, and soon an uploader. Debian and Ubuntu are my favourite operating systems. I have ongoing art projects with free software, and you can read about them on http://alexandre.quessy.net Project on which in am author or co-author: (I intend to package the three packages listed first.) * toonloop: Live frame by frame animation tool http://toonloop.com * scenic: Desktop application to stream audio, video and MIDI over RTP http://svn.sat.qc.ca/trac/scenic/ * lunch: Distributed process launcher http://svn.sat.qc.ca/trac/lunch * Other listed on http://bitbucket.org/aalex/ Cool! Again, welcome to the team! -- 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: csound_5.12.1~dfsg-2_amd64.changes ACCEPTED
On Sa, Mai 29, 2010 at 08:54:45 (CEST), Alessio Treglia wrote: Felipe, On Sat, May 29, 2010 at 6:42 AM, Felipe Sateler fsate...@gmail.com wrote: I'm pretty sure that patch is broken. _csnd.so is a binary, and as such I don't think you can really move it from one python version to another. Has anyone tested that patch? IIRC, Scott introduced it and at the time I asked him about that and he wasn't really convincing/convinced that it worked. so csound doesn't support Python 2.6, is this the problem? Given that squeeze is going to install python 2.6 by default, I'd say yes. I guess python-2.5 is going to be around for squeeze, so I'm not sure how severe the problem is. Maybe check with debian-release and/or the python team? -- 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
Bug#583639: Vlc crashes when i close the Quick Open File window and open it again
Hello, Le Sat 29 May 10 à 02:41 -0300, Daniel Correa a écrit : Package: vlc When I open the Quick Open File window to open a file, I close it with the X button (this not happend when i just press Cancel), and then I try to open it again (the Quick Open File Window), vlc crashes and say something about GTK. I paste the output here: (.:3165): Gtk-CRITICAL **: gtk_propagate_event: assertion `GTK_IS_WIDGET (widget)' failed ^Csignal 2 received, terminating vlc - do it again in case it gets stuck ^Cuser insisted too much, dying badly What do you call crash ? Because here i see that you pressed several times Ctrl+C to force-quit VLC. Also could you provide verbose logs (-vvv) -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via dh_makeshlibs -V). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! - 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#582238: libebml: New upstream release 0.8.0
On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via dh_makeshlibs -V). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! Good idea. I'll finish the libebml version upgrade and upload, but please give me a few days. -- 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
libva_1.0.1-1_i386.changes REJECTED
Hi, several MIT-licensed files miss copyright holders in debian/copyright. i965_drv_video/intel_batchbuffer.c: Copyright 2006 Tungsten Graphics, Inc., Cedar Park, Texas. (some) src/x11/va_dri*: Copyright © 2008 Red Hat, Inc. src/x11/va_nvctrl.*: Copyright (c) 2008 NVIDIA, Corporation src/va_version.h.in: Copyright (C) 2009 Splitted-Desktop Systems Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] Free Firewire Audio Drivers (ffado.org) packaging branch, master, updated. debian/2.0.0+svn1813-1-19-g2960efd
On Sa, Mai 29, 2010 at 14:39:45 (CEST), adiknoth-gu...@users.alioth.debian.org
wrote:
The following commit has been merged in the master branch:
commit 2960efd7fc5899d9efdae12346813937ed1d4dab
Author: Adrian Knoth a...@drcomp.erfurt.thur.de
Date: Sat May 29 14:18:39 2010 +0200
Relax strict dependency for libffado-dev and ffado-mixer-qt4
lintian complained (E) about too strict dependency for the arch_any
packages, making them non-binNMUable.
This should fix it.
diff --git a/debian/control b/debian/control
index ecb4113..a1a891c 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,7 @@ Vcs-Browser:
http://git.debian.org/?p=pkg-multimedia/ffado.git;a=summary
Package: libffado-dev
Section: libdevel
-Architecture: all
+Architecture: i386 amd64 powerpc
Wouldn't be a better fix to just make the packages arch: any?
Depends: libffado2 (= ${binary:Version}),
${misc:Depends},
libxml2-dev,
@@ -105,7 +105,7 @@ Description: FFADO D-Bus server
Package: ffado-mixer-qt4
Section: sound
Architecture: all
-Depends: ffado-dbus-server (= ${binary:Version}),
+Depends: ffado-dbus-server (= ${source:Version}),
${python:Depends},
python,
python-dbus,
diff --git a/debian/control.in b/debian/control.in
index 1faeee8..d4e4b3c 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -31,7 +31,7 @@ Vcs-Browser:
http://git.debian.org/?p=pkg-multimedia/ffado.git;a=summary
Package: libffado-dev
Section: libdevel
-Architecture: all
+Architecture: i386 amd64 powerpc
Depends: libffado2 (= ${binary:Version}),
${misc:Depends},
libxml2-dev,
@@ -101,7 +101,7 @@ Description: FFADO D-Bus server
Package: ffado-mixer-qt4
Section: sound
Architecture: all
-Depends: ffado-dbus-server (= ${binary:Version}),
+Depends: ffado-dbus-server (= ${source:Version}),
${python:Depends},
python,
python-dbus,
--
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] Free Firewire Audio Drivers (ffado.org) packaging branch, master, updated. debian/2.0.0+svn1813-1-19-g2960efd
On Sa, Mai 29, 2010 at 14:46:23 (CEST), Adrian Knoth wrote:
On Sat, May 29, 2010 at 12:39:41PM +,
adiknoth-gu...@users.alioth.debian.org wrote:
Hi!
I could use some help on this issue:
Set arch to all for libffado-dev and ffado-mixer-qt4
Alessio Treglia writes:
* {ffado-mixer-qt4,libffado-dev} provide only arch-indep stuff, so
the proper value of the Architecture fields is all.
Package: libffado-dev
Section: libdevel
-Architecture: i386 amd64 powerpc
+Architecture: all
Depends: libffado2 (= ${binary:Version}),
With this change, lintian complains about libffado-dev being no longer
binNMU'able and proposes to relax the dependency.
it's not only a complaint, this indeed causes practical causes. The fact
that lintian mentions this is not the important point here :-)
When I relax the dependency to (= ${source:Version}), it complains
about weak-library-dev-dependency. I tried the proposed workaround, but
either didn't get it right or it simply doesn't work.
Which is correct as well, no?
What's the right approach here? I now decided to switch the architecture
back and go for a strict dependency. Though this wastes some bytes on
the mirrors, it at least works. ;)
IMO making them arch:all causes more headaches and labor than the
benefit we gain from saving a few bytes on the mirrors.
--
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: Bug#582238: libebml: New upstream release 0.8.0
On Sa, Mai 29, 2010 at 12:46:43 (CEST), Reinhard Tartler wrote: On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via dh_makeshlibs -V). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! Good idea. actually, not, this is a c++ lib. I know that dpkg-gensymbols in unstable supports c++ unmangled symbol names, but I cannot figure out how to make it create templates with unmangled symboles. I'm certainly not going to do this step by hand! Jonas, do you know how to do that? If not, I think the package is good to test and upload after debian/changelog has been updated. -- 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] Free Firewire Audio Drivers (ffado.org) packaging branch, master, updated. debian/2.0.0+svn1813-1-19-g2960efd
On Sat, May 29, 2010 at 3:57 PM, Jonas Smedegaard d...@jones.dk wrote: Arrgh - make sure at least to avoid such patch trickling upstream, as it is tied to the use of the Debian-specific python-shared framework! Could it be enough this change? [1] http://paste.debian.net/75335/ -- Alessio Treglia quadris...@ubuntu.com Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Sat, May 29, 2010 at 05:41:40PM +0200, Reinhard Tartler wrote: On Sa, Mai 29, 2010 at 12:46:43 (CEST), Reinhard Tartler wrote: On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via dh_makeshlibs -V). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! Good idea. actually, not, this is a c++ lib. I know that dpkg-gensymbols in unstable supports c++ unmangled symbol names, but I cannot figure out how to make it create templates with unmangled symboles. I'm certainly not going to do this step by hand! Jonas, do you know how to do that? Not that I am expert on the subject, but a quick googling seems to indicate that filtering through c++filt (part of the binutils package) should do the trick. - 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
libva_1.0.1-2_i386.changes is NEW
(new) i965-va-driver_1.0.1-2_i386.deb optional libs Video Acceleration (VA) API for Linux -- i965 VA driver Video Acceleration API (VA API) is a library (libVA) and API specification which enables and provides access to graphics hardware (GPU) acceleration for video processing on Linux and UNIX based operating systems. Accelerated processing includes video decoding, video encoding, subpicture blending and rendering. The specification was originally designed by Intel for its GMA (Graphics Media Accelerator) series of GPU hardware, the API is however not limited to GPUs or Intel specific hardware, as other hardware and manufacturers can also freely use this API for hardware accelerated video decoding. . This package provides the Intel i965 VA backend driver. (new) libva-dev_1.0.1-2_all.deb optional libdevel Video Acceleration (VA) API for Linux -- development files Video Acceleration API (VA API) is a library (libVA) and API specification which enables and provides access to graphics hardware (GPU) acceleration for video processing on Linux and UNIX based operating systems. Accelerated processing includes video decoding, video encoding, subpicture blending and rendering. The specification was originally designed by Intel for its GMA (Graphics Media Accelerator) series of GPU hardware, the API is however not limited to GPUs or Intel specific hardware, as other hardware and manufacturers can also freely use this API for hardware accelerated video decoding. . This package provides the development environment for libva. (new) libva-x11-1_1.0.1-2_i386.deb optional libs Video Acceleration (VA) API for Linux -- X11 runtime Video Acceleration API (VA API) is a library (libVA) and API specification which enables and provides access to graphics hardware (GPU) acceleration for video processing on Linux and UNIX based operating systems. Accelerated processing includes video decoding, video encoding, subpicture blending and rendering. The specification was originally designed by Intel for its GMA (Graphics Media Accelerator) series of GPU hardware, the API is however not limited to GPUs or Intel specific hardware, as other hardware and manufacturers can also freely use this API for hardware accelerated video decoding. . This package provides the libva-x11 library. (new) libva1_1.0.1-2_i386.deb optional libs Video Acceleration (VA) API for Linux -- runtime Video Acceleration API (VA API) is a library (libVA) and API specification which enables and provides access to graphics hardware (GPU) acceleration for video processing on Linux and UNIX based operating systems. Accelerated processing includes video decoding, video encoding, subpicture blending and rendering. The specification was originally designed by Intel for its GMA (Graphics Media Accelerator) series of GPU hardware, the API is however not limited to GPUs or Intel specific hardware, as other hardware and manufacturers can also freely use this API for hardware accelerated video decoding. . This package provides the main libva library. (new) libva_1.0.1-2.diff.gz optional libs (new) libva_1.0.1-2.dsc optional libs (new) libva_1.0.1.orig.tar.gz optional libs (new) vainfo_1.0.1-2_i386.deb optional libs Video Acceleration (VA) API for Linux -- info program Video Acceleration API (VA API) is a library (libVA) and API specification which enables and provides access to graphics hardware (GPU) acceleration for video processing on Linux and UNIX based operating systems. Accelerated processing includes video decoding, video encoding, subpicture blending and rendering. The specification was originally designed by Intel for its GMA (Graphics Media Accelerator) series of GPU hardware, the API is however not limited to GPUs or Intel specific hardware, as other hardware and manufacturers can also freely use this API for hardware accelerated video decoding. . This package provides the vainfo program. Changes: libva (1.0.1-2) unstable; urgency=low . * Fix copyright issues. * Added 'DM-Upload-Allowed: yes' entry. . libva (1.0.1-1) unstable; urgency=low . * New upstream release. (Closes: #569635) * Rework debianization. . libva (0.24-1) unstable; urgency=low . * Updated to v0.24 * Display attributes added * H264 parameter fixes * Swapped vaGetConfigAttributes and vaQueryConfigAttributes . libva (0.22-1) unstable; urgency=low . * Updated to v0.22 * VAImage and VASubpicture added . libva (0.20-1) unstable; urgency=low . * Updated to v0.20 * Clean up exporting DRI interface . libva (0.20~-1) unstable; urgency=low . * Add VA_INVALID_SURFACE . libva (0.20~~-1) unstable; urgency=low . * Initial release of libva Override entries for your package: Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 569635 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the
Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
Moving this to a new thread to make sure it gets noticed. On Sat, May 29, 2010 at 10:08:24AM +0200, Reinhard Tartler wrote: On Fr, Mai 28, 2010 at 21:01:04 (CEST), Alexandre Quessy wrote: Hello, I want to join the Debian Multimedia Package Maintainers Team. (whatever it's called) My alioth username is alexandrequessy-guest. I also see that you are familiar with jack. The most pressing question is to if we do want to enable users to switch their jack implementation in squeeze. Currently that's not possible, but ideas how to rearrange packages, shlibs files and provides have been proposed. I have to admit that I've lost track and don't know if they are still being considered of if everyone has lost motivation to actually implement them. Perhaps you (or someone else) can try to pickup that discussion? I've already announced on #debian-release a few days ago that we might require such a transition, but we'd also need to write a more formal email to debian-release for that. My current understanding is that, yes, we want it to happen. The main issue is people who know how having the time to make it happen. If memory serves, Adrian knows the jack code and upstream the best of anyone here. Reinhard knows about library magic stuff from working on ffmpeg. Jonas knows lots of cdbs magic that might be helpful. Do any of the three of you have time in the very near future to push this forward? Are there others on the team paying attention with time, interest and knowledge not mentioned above? For reference in case anyway is new to the discussion or needs to review, I think most of the relevant information is in this thread: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/008854.html -edrz (who can't claim to understand the details at all well, but looks forward to learning a great deal from watching from the wings whenever it does happen.) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
On Sat, May 29, 2010 at 02:34:45PM -0500, Gabriel M. Beddingfield wrote: Hi, On Sat, 29 May 2010, Eric Dantan Rzewnicki wrote: I want to join the Debian Multimedia Package Maintainers Team. (whatever it's called) My alioth username is alexandrequessy-guest. I also see that you are familiar with jack. The most pressing question is to if we do want to enable users to switch their jack implementation [snip] My current understanding is that, yes, we want it to happen. The main issue is people who know how having the time to make it happen. IIRC, the consensus was that the squeeze release was way too close to make the drastic changes required for this to happen. That it would need to happen after that. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/009046.html That contained Adrian putting his foot down to stop the debate and say: we switch to jackd2 now. No one disagreed. But, he went on to say we could then still try to make the swapping possible in time for squeeze. Maybe I misuderstood, am misremembering or missed some further discussion. -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: csound_5.12.1~dfsg-2_amd64.changes ACCEPTED
On Sat, May 29, 2010 at 09:18, Alessio Treglia quadris...@ubuntu.com wrote:
Ops, forgot the URLs:
[1]
http://debomatic.debian.net/maverick/pool/csound_5.12.1~dfsg-2ubuntu1/csound_5.12.1~dfsg-2ubuntu1.buildlog
for pyvers in 2.6; do \
mkdir -p
/tmp/buildd/csound-5.12.1~dfsg/debian/tmp/usr/lib/python$pyvers/$(basename
$(_py_=; python${_py_#python*} -c 'from distutils import sysconfig;
print(sysconfig.get_python_lib())')); \
cp csnd.py _csnd.so \
/tmp/buildd/csound-5.12.1~dfsg/debian/tmp/usr/lib/python$pyvers/$(basename
$(_py_=; python${_py_#python*} -c 'from distutils import sysconfig;
print(sysconfig.get_python_lib())')); \
done
Basically it only installs for 2.6 because that is the only version
supported right now. If/when that changes, csound would install one
working and one broken module.
The real solution to this problem is to build the csound source twice,
once for each python version. One could probably do some magic to
rebuild only needed parts, but that is not (as Jonas hoped) at all
generic.
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
On Sat, 29 May 2010, Eric Dantan Rzewnicki wrote: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-April/009046.html That contained Adrian putting his foot down to stop the debate and say: we switch to jackd2 now. No one disagreed. But, he went on to say we could then still try to make the swapping possible in time for squeeze. Maybe I misuderstood, am misremembering or missed some further discussion. Nope, that's right: jack2 now. Enable (easy) user switching later. -gabriel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Rekindle jack implementation swapping discussion (was Re: Request to join the Debian Multimedia Team)
On Sat, May 29, 2010 at 03:55:36PM -0400, Eric Dantan Rzewnicki wrote: we switch to jackd2 now. No one disagreed. Nope, that's right: jack2 now. Enable (easy) user switching later. + possibly in time for squeeze, which is Reinhard's question: are we still going to try for it, and therefore, do we need to get a more detailed note to release-team (last week) about what it entails for coordination between this team and them. I think it's not too hard to revive the jackd1 package, so we can at least provide jackd1 and jackd2 in squeeze. Given the tons of C++ symbols in jackd2, I'd also suggest to make the jackd1 package the official dev package and also the donator of the symbols file. If possible, we should file a bug report against release.debian.org to coordinate the transition, but I'm not debian-experienced enough to take the lead. 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
Hi...From/Sgt Liliana Tavera
Proposal /Sgt. Liliana Tavera
Hi, Please accept my sincere apologies if my proposal does not meet
your business or personal ethics. I'm contacting you for solidarity
on behalf of our United States troops here in Iraq to receive funds
in your custody for safekeeping pending our troop's final dismissal
anytime this year...
All machinery would be put in place to ensure that this claim is hitch
free if you are capable of putting your time and efforts towards the
venture, kindly contact me immediately with the following information (1.)
Your Full names And Address (2.) A scanned copy of your photo ID (3.)
Telephone and fax number, and I'll get back to you immediately with the
basic condition of this proposal.
In waiting of your response...
Sgt. Liliana Tavera {Ms}
Baghdad,
E-mail: sgtlitav...@terra.com
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Request to join the Debian Multimedia Team
Hello Reinhard, and the pkg-multimedia team! 2010/5/29 Reinhard Tartler siret...@tauware.de: On Fr, Mai 28, 2010 at 21:01:04 (CEST), Alexandre Quessy wrote: Hello, I want to join the Debian Multimedia Package Maintainers Team. (whatever it's called) My alioth username is alexandrequessy-guest. I've just added you to the team, welcome on board. Thanks a lot! I'm on the IRC channel every week day, if anyone wants to chat with me... :) I assume that you have already read and understood our wiki pages: http://wiki.debian.org/DebianMultimedia http://wiki.debian.org/DebianMultimedia/DevelopPackaging They are certainly not perfect and need improvements/polishing, but they at least should document the most important things we've agreed on in the past. Please help us to improve them by discussions and/or edits! Yes, I am often a wiki gnome that polishes the doc. That should come a little later, when I will be more comfortable with how Debian and the team works. My name is Alexandre Quessy. I am a developer from Montreal. I am interested in free software for new media arts, nameyl audio, video and electronics. I have been using free software for many years now. I am the co-author of some free software projects such as those listed above. I am mostly interested in the Python and C++ languages. Amongst the tools I like are Twisted, GTK+, GStreamer, gettext, the GNU Autotools, bash and vim. I have a strong background in image processing, music theory, web development, communication protocols and software process management. Sounds cool! Are you also familiar with packaging python applications? I have to admit that I've lost my interest because of the internal python affair and helper scripts war, so I more or less try to avoid such packages. Having someone on the team that knows how do package python apps properly would be a great benefit for pkg-multimedia! Yes, I am currently packaging my first Python package that will be pushed into Debian. For the same reasons as you mentionned, I personaly prefer packaging Python applications with the GNU autotools myself. :) There might be some progress in the next few months, though, with the Distribute fork of the Python setuptools. I also see that you are familiar with jack. The most pressing question is to if we do want to enable users to switch their jack implementation in squeeze. Currently that's not possible, but ideas how to rearrange packages, shlibs files and provides have been proposed. I have to admit that I've lost track and don't know if they are still being considered of if everyone has lost motivation to actually implement them. Perhaps you (or someone else) can try to pickup that discussion? I will forward this to my colleague who knows more than I about the JACK library itself. He developed one of the JACK Gstreamer element, so he should know more than me. I think both JACK and jackdmp (or jack 2?) are API and ABI-compatible... But I am not sure about this at all. I've already announced on #debian-release a few days ago that we might require such a transition, but we'd also need to write a more formal email to debian-release for that. I am motivated to become a Debian maintainer, and soon an uploader. Debian and Ubuntu are my favourite operating systems. I have ongoing art projects with free software, and you can read about them on http://alexandre.quessy.net Project on which in am author or co-author: (I intend to package the three packages listed first.) * toonloop: Live frame by frame animation tool http://toonloop.com * scenic: Desktop application to stream audio, video and MIDI over RTP http://svn.sat.qc.ca/trac/scenic/ * lunch: Distributed process launcher http://svn.sat.qc.ca/trac/lunch * Other listed on http://bitbucket.org/aalex/ Cool! Again, welcome to the team! -- 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 Later, -- Alexandre Quessy http://alexandre.quessy.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
