Re: OpenNi in Debian
* Hans-Christoph Steiner h...@eds.org [2011-06-19 00:07]: On Wed, 08 Jun 2011 03:07 +0200, Jochen Sprickerhof joc...@sprickerhof.de wrote: * Hans-Christoph Steiner h...@eds.org [2011-06-07 18:47]: On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner h...@eds.org [2011-06-06 13:05]: I have not been in contact with avin. Is Bayer images support something that is in the original from PrimeSense, or something that you want added? If the idea is to maintain new features in the package, I think that should probably be done in a separate git repo to keep the development and the packaging separately. If you want to maintain a fork of the primesense/sensor repo, we could base the package off of that for now. it's something we have added. Should we put it on github and merge it with the avin2 branch? That works for me. Here it is: https://github.com/ros-pkg-git/Sensor/tree/master. It's not based on the avin2 branch (as they are not really based to the official OpenNI once), let me know if you that's ok for you. By the way, why is the Debian git not connected to the github one? I mean this one: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/primesense-kinect-sensor.git These packages are packaged using standard Debian git-buildpackage style. That means that the upstream code is imported from release tarballs, and the git master branch is all about the debian packaging. That's why this repo is not a fork of the upstream repo. According to the git-buildpackage documentation [1] the upstream-branch can either be imported or a branch you can pull from. So generating tarballs from a git and then importing them into git again seems to be superfluous and makes the upstream branch hard to track. But if it works for you, I'm fine with it. So if we decide to make primesense-kinect-sensor based off of your git fork, then a release tarball would need to be imported using git-import-orig. I'm thinking perhaps its a better idea if you make a separate package of your fork. I used the avin2 fork rather than the offical repo for this package because it seems that the official sources don't fully work. It should be really easy to create a ros package since the code is so close. It could be something like primesense-kinect-sensor-ros or whatever. This has nothing to do with ROS (apart from that it's living in their repository. I'm one of the authors of PCL [2] where we use the features of my version. As there is a ITP [3] for it, it would be nice if the package would include it, so the OpenNI part of PCL would work as well, once it's packages. Regarding the base for the package I'm fine with the avin2 fork, as long as we can put the Bayer patches from my branch inside debian/patches, but for me it would almost make more sense to base it of the OpenNI branch (as this is the official version) and put the avin2 patches in debian/patches as well. Speaking of it, did you see the Fedora patches over there [4]? .hc Cheers, Jochen [1] /usr/share/doc/git-buildpackage/manual-html/gbp.intro.html#GBP.REPOSITORY [2] http://pointclouds.org [3] http://bugs.debian.org/624178 [4] https://github.com/OpenNI/OpenNI/pull/10 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Sun, Jun 19, 2011 at 09:05:46 (CEST), Jochen Sprickerhof wrote: According to the git-buildpackage documentation [1] the upstream-branch can either be imported or a branch you can pull from. So generating tarballs from a git and then importing them into git again seems to be superfluous and makes the upstream branch hard to track. But if it works for you, I'm fine with it. That's the price of the overhead of team work. As a team, we want to use the same workflow on all packages. Since not all upstreams maintain the sources in git, we need to come down to the lowest common denominator, which boils down to importing tarballs. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#629871: missing man pages for ecasound-iam, ecatools, ecalength
retitle 629871 Move ecasound-iam manpage from ecatools to ecasound package
tags 629871 pending
thanks
Hi Joel,
sorry for the late reply.
On Thu, Jun 09, 2011 at 12:20:38PM -1000, Joel Roth wrote:
On Thu, Jun 09, 2011 at 10:21:20AM +0200, Alessandro Ghedini wrote:
On Wed, Jun 08, 2011 at 04:34:42PM -1000, Joel Roth wrote:
No result for 'man' command.
According to http://packages.debian.org/sid/amd64/ecasound/filelist
There should be man pages in /usr/share/man/man1/
However removing and reinstalling the package, the man files
are not present.
Please note that the ecatools (as well as their manpages) have been moved
to the 'ecatools' package since version 2.8.0-1, to avoid a circular
dependency between ecasound and python-ecasound.
$ dpkg -L ecatools | grep man1
/usr/share/man/man1/ecalength.1.gz
/usr/share/man/man1/ecatools.1.gz
/usr/share/man/man1/ecasound-iam.1.gz
/usr/share/man/man1/ecasignalview.1.gz
/usr/share/man/man1/ecanormalize.1.gz
/usr/share/man/man1/ecamonitor.1.gz
/usr/share/man/man1/ecafixdc.1.gz
/usr/share/man/man1/ecaplay.1.gz
/usr/share/man/man1/ecaconvert.1.gz
That's all good, however the man page for ecasound-iam,
which is necessary to use ecasound interactively, is
in ecatools. I think it should be moved to ecasound.
Finally, someone trying out ecasound may be expecting the
docs and ecatools utilities. These packages are relatively
small. Could they be recommended (so they are pulled in
automatically)? IMO they should be suggested, at least.
Also, the file list on packages.d.o is quite outdated :)
Good to know, also about dpkg -L.
Thanks again for what has turned out to be a rather complex
packaging job!
I've pushed to git the changes that you suggested (moving the manpage and
Suggests: ecatools in the ecasound package).
Alessio, I've prepared a new upload on git, could you please have a look?
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: retitle 629871 Move ecasound-iam manpage from ecatools to ecasound package Bug #629871 [ecasound] missing man pages for ecasound-iam, ecatools, ecalength Changed Bug title to 'Move ecasound-iam manpage from ecatools to ecasound package' from 'missing man pages for ecasound-iam, ecatools, ecalength' tags 629871 pending Bug #629871 [ecasound] Move ecasound-iam manpage from ecatools to ecasound package Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 629871: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629871 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Please Backport Audacious
On 16/06/11 17:47, Cyril Lavier wrote: On 06/16/2011 05:47 PM, rent0n wrote: Hello everyone, Would anybody be interested in backporting 'audacious' and 'audacious-plugins' from testing to Squeeze? I don't think Audacious needs any presentation, being one of the most used and loved music players. The testing version (2.4,4) brings some very nice improvements and new features over 2.3. Plus, it also fix some very annoying bugs. Volunteers? Thanks! Hi. For this purpose, I've added the Debian Multimedia Maintainers list, maybe somebody will be available to fulfill your request. Also, there is a 2.5.1 released mid may, and an alpha released few days ago. Maybe it will make more sense to wait until the 2.5.1 is uploaded to testing to think about a backport. I also think the packaging team is focused on including the 3.0 release in testing. Thanks. Hi, Thanks for cc'ing the Debian Multimedia Maintainers list, I guess there might be some folks interested in backporting Audacious there. I see your point, waiting for 2.5 could make sense, but in my view 2.4 is already a big improvement over 2.3 and has the advantage of being already in testing, ready to be backported. So, if anyone's interested, please raise your hand, having 2.4 in Squeeze would be great! Thanks, -- rent0n ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Jun 19, 2011, at 4:00 AM, Reinhard Tartler wrote: On Sun, Jun 19, 2011 at 09:05:46 (CEST), Jochen Sprickerhof wrote: According to the git-buildpackage documentation [1] the upstream- branch can either be imported or a branch you can pull from. So generating tarballs from a git and then importing them into git again seems to be superfluous and makes the upstream branch hard to track. But if it works for you, I'm fine with it. That's the price of the overhead of team work. As a team, we want to use the same workflow on all packages. Since not all upstreams maintain the sources in git, we need to come down to the lowest common denominator, which boils down to importing tarballs. The other side of it is that the upstream git repos are a mess. The PrimeSense repo is not used for development, and has a quite unusual structure. It looks like to me they are just importing releases and not doing any development out of that git, plus they are using the two branches as separate repos, one called 'master' which is the stable releases, and the other called 'unstable'. As code is pushed to the stable releases, it is not merged from the 'unstable' branch into master. Then it looks like the avin2 fork is a new reconstruction of the git repo to be more git-like, but then that doesn't follow the original git. But I think if I was avin2, I'd do the same. .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
LAME status
Is there going to be another try at including lame into debian? Last time was rejected due to concerns over the LGPL license and added restrictions: http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2011-April/017869.html Rogerio is part of upstream so can probably help clarify this? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
jack-stdio 1.4-1 MIGRATED to testing
FYI: The status of the jack-stdio source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 1.4-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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: openni package for Debian
On Jun 1, 2011, at 6:57 AM, Cosimo Alfarano wrote: On 31/05/11 03:49, Hans-Christoph Steiner wrote: Ah, cool, so we have an uploader :) I'm just a DM. I'm not sure about Cosimo. I'm a DD. BTW, update to the pkgs status: I tried yesterday the three repos, they worked. I just pushed a couple of patches to fix small (but necessary) things. I just realized that we need to fix the .ini file for Kinect, I had to change InputFormat=1 which was commented, to make it work. Also, udev rules, does anybody know if we need OWNER=root or it can be xxx as set by upstream? Next steps: - Enable Mono in openni so that it can be re-enabled in NITE. - the Makefile for NITE OpenNI relies on the presence of the mono exec to compile mono, which means that in a chroot env it compiles without problems, but when build outside in an env which has mono installed it will fail. The reason of the failure is that the upstream install.sh script do not detach the build from the (post) installation process. As per my mono understanding (noob) we need to compile GAC in postinst, while create the DLL at build time. Until we split this behaviour (should be easy) we cannot build mono package and both openni and NITE are inherently broken. It would be nice to have the Mono stuff working, but I don't think it should be a blocker on getting the package uploaded. So far, most of the useful stuff I've seen done with openni has not involved Mono/.NET/ C#. - Re-enable quilt, so that we can patch the Samples to be able to find their XML in a different location than ../../../../Data, and package it as openni-samples, the same for nite and kinect IIRC. - Fix all the lintian complaints and the .ini :) I fixed the man page complaints, tho the man pages I just made could definitely improved a lot. .hc - Fix the SONAME and .so versioning issue, it depends on the email I still have to send to upstream about their build system :) So far this is not a real problem, until we'll have more than one version we need to be able to link at the same time. After that we might be able to consider an upload to unstable, IMHO. cheers, C. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Please Backport Audacious
On 06/19/2011 04:14 PM, rent0n wrote: On 16/06/11 17:47, Cyril Lavier wrote: On 06/16/2011 05:47 PM, rent0n wrote: Hello everyone, Would anybody be interested in backporting 'audacious' and 'audacious-plugins' from testing to Squeeze? I don't think Audacious needs any presentation, being one of the most used and loved music players. The testing version (2.4,4) brings some very nice improvements and new features over 2.3. Plus, it also fix some very annoying bugs. Volunteers? Thanks! Hi. For this purpose, I've added the Debian Multimedia Maintainers list, maybe somebody will be available to fulfill your request. Also, there is a 2.5.1 released mid may, and an alpha released few days ago. Maybe it will make more sense to wait until the 2.5.1 is uploaded to testing to think about a backport. I also think the packaging team is focused on including the 3.0 release in testing. Thanks. Hi, Thanks for cc'ing the Debian Multimedia Maintainers list, I guess there might be some folks interested in backporting Audacious there. I see your point, waiting for 2.5 could make sense, but in my view 2.4 is already a big improvement over 2.3 and has the advantage of being already in testing, ready to be backported. So, if anyone's interested, please raise your hand, having 2.4 in Squeeze would be great! Thanks, Hi. If there is nobody from the Debian Multimedia Maintainers team which is interested. I may fill the void, and try to do some work on the backport. Thanks. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
invada-studio-plugins-lv2 1.2.0+repack0-1 MIGRATED to testing
FYI: The status of the invada-studio-plugins-lv2 source package in Debian's testing distribution has changed. Previous version: 1.2.0-1 Current version: 1.2.0+repack0-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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: OpenNi in Debian
On Jun 19, 2011, at 3:05 AM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner h...@eds.org [2011-06-19 00:07]: On Wed, 08 Jun 2011 03:07 +0200, Jochen Sprickerhof joc...@sprickerhof.de wrote: * Hans-Christoph Steiner h...@eds.org [2011-06-07 18:47]: On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner h...@eds.org [2011-06-06 13:05]: I have not been in contact with avin. Is Bayer images support something that is in the original from PrimeSense, or something that you want added? If the idea is to maintain new features in the package, I think that should probably be done in a separate git repo to keep the development and the packaging separately. If you want to maintain a fork of the primesense/sensor repo, we could base the package off of that for now. it's something we have added. Should we put it on github and merge it with the avin2 branch? That works for me. Here it is: https://github.com/ros-pkg-git/Sensor/tree/master. It's not based on the avin2 branch (as they are not really based to the official OpenNI once), let me know if you that's ok for you. By the way, why is the Debian git not connected to the github one? I mean this one: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/primesense-kinect-sensor.git These packages are packaged using standard Debian git-buildpackage style. That means that the upstream code is imported from release tarballs, and the git master branch is all about the debian packaging. That's why this repo is not a fork of the upstream repo. According to the git-buildpackage documentation [1] the upstream- branch can either be imported or a branch you can pull from. So generating tarballs from a git and then importing them into git again seems to be superfluous and makes the upstream branch hard to track. But if it works for you, I'm fine with it. So if we decide to make primesense-kinect-sensor based off of your git fork, then a release tarball would need to be imported using git-import-orig. I'm thinking perhaps its a better idea if you make a separate package of your fork. I used the avin2 fork rather than the offical repo for this package because it seems that the official sources don't fully work. It should be really easy to create a ros package since the code is so close. It could be something like primesense-kinect-sensor-ros or whatever. This has nothing to do with ROS (apart from that it's living in their repository. I'm one of the authors of PCL [2] where we use the features of my version. As there is a ITP [3] for it, it would be nice if the package would include it, so the OpenNI part of PCL would work as well, once it's packages. Regarding the base for the package I'm fine with the avin2 fork, as long as we can put the Bayer patches from my branch inside debian/patches, but for me it would almost make more sense to base it of the OpenNI branch (as this is the official version) and put the avin2 patches in debian/patches as well. [1] /usr/share/doc/git-buildpackage/manual-html/ gbp.intro.html#GBP.REPOSITORY [2] http://pointclouds.org [3] http://bugs.debian.org/624178 Sounds to me like you are much deeper in this code than I am, so I would defer to you on that topic :) I'm mostly am thinking of the long term policy for this package, and what makes sense for the code that's out there. So I don't have strong opinions on how it shaped for the most part. My guess is that the package should try to stick to the primesense code as much as possible, as long as they are accepting patches so that their codebase is usable for Debian. So yes, all changes as patches in debian/patches makes sense to me. I've mostly achieved my goal, which was making it really easy to use skeleton tracking with other media software, but I'm happy to stay involved as much as I am useful. I'm about to have a baby, so I'll probably be not around for a while, so don't worry about waiting on me to get stuff done. Speaking of it, did you see the Fedora patches over there [4]? [4] https://github.com/OpenNI/OpenNI/pull/10] That looks very useful, I hope they accept it. .hc It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
easytag 2.1.6+git20110423-3 MIGRATED to testing
FYI: The status of the easytag source package in Debian's testing distribution has changed. Previous version: 2.1.6+git20110423-1 Current version: 2.1.6+git20110423-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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#631046: mediatomb: FTBFS against iceweasel 4.0 or 5.0
Source: mediatomb Version: 0.12.1-2 Severity: serious Tags: sid wheezy User: pkg-mozilla-maintain...@lists.alioth.debian.org Usertags: xulrunner-2.0 Hi, your package fails to build against iceweasel 4.0 (currently in experimental). iceweasel 5.0 will soon be uploaded to unstable, so your package needs to be updated to cope with the new version, or will have to be removed. Build logs are available at http://people.debian.org/~glandium/iceweasel4-transition.logs.tbz2 Cheers, Julien ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#631068: audacity: Commercial use of nyquist not allowed
Package: audacity Version: 1.3.12-6 Severity: serious Justification: Policy 2.1.6 User: gnewsense-...@nongnu.org Usertags: gnewsense libreplanet The file lib-src/libnyquist/nyquist/xlisp/xlbfun.c contains the following license notice: /* Copyright (c) 1985, by David Michael Betz All Rights Reserved Permission is granted for unrestricted non-commercial use */ This clearly does not permit commercial use. In the worst interpretation it also doesn't allow modification or distribution. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages audacity depends on: ii audacity-data 1.3.12-6 A fast, cross-platform audio edito ii libasound2 1.0.23-1 shared library for ALSA applicatio ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libflac++6 1.2.1-2+b1Free Lossless Audio Codec - C++ ru ii libflac8 1.2.1-2+b1Free Lossless Audio Codec - runtim ii libgcc11:4.4.4-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-02.20.1-1+b1 The GTK+ graphical user interface ii libid3tag0 0.15.1b-10ID3 tag reading library from the M ii libjack0 [libjack-0.11 1:0.118+svn3796-7 JACK Audio Connection Kit (librari ii libmad00.15.1b-5 MPEG audio decoder library ii libogg01.2.0~dfsg-1 Ogg bitstream library ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsndfile11.0.21-3 Library for reading/writing audio ii libsoundtouch1c2 1.3.1-2 sound stretching library ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3 ii libtwolame00.3.12-1 MPEG Audio Layer 2 encoding librar ii libvamp-hostsdk3 2.1-1 helper library for Vamp hosts writ ii libvorbis0a1.3.1-1 The Vorbis General Audio Compressi ii libvorbisenc2 1.3.1-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.3.1-1 The Vorbis General Audio Compressi ii libwxbase2.8-0 2.8.10.1-3+b1 wxBase library (runtime) - non-GUI ii libwxgtk2.8-0 2.8.10.1-3+b1 wxWidgets Cross-platform C++ GUI t Versions of packages audacity recommends: ii libavcodec52 4:0.5.2-6.1 ffmpeg codec library ii libavformat524:0.5.2-6.1 ffmpeg file format library Versions of packages audacity suggests: pn ladspa-plugin none (no description available) pn libmp3lame0 none (no description available) -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
