Re: please upload pd-moonlib
A gentle ping looking for an upload. I'd love to make the Ubuntu/ oneiric import deadline. .hc On Jun 10, 2011, at 1:16 PM, Hans-Christoph Steiner wrote: pd-moonlib was uploaded before, but was rejected by the ftpmasters because the LGPL-covered files were not documented distinct from the over-arching GPL of the project. That's fixed, as well as other recent issues that have come up, and pd-moonlib is ready for upload! http://git.debian.org/?p=pkg-multimedia/pd-moonlib.git .hc Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ 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: request for sponsorship for pd-hid
On Jun 14, 2011, at 12:31 PM, Hans-Christoph Steiner wrote: On Jun 13, 2011, at 8:01 PM, Felipe Sateler wrote: On Mon, Jun 13, 2011 at 14:43, Hans-Christoph Steiner wrote: On Jun 12, 2011, at 10:53 PM, Felipe Sateler wrote: On Sat, Jun 11, 2011 at 22:15, Hans-Christoph Steiner > wrote: On Sat, 2011-06-11 at 19:30 +, Felipe Sateler wrote: On Sat, Jun 11, 2011 at 02:45, Hans-Christoph Steiner > wrote: On Wed, 09 Feb 2011 17:41 -0300, "Felipe Sateler" > wrote: On Mon, Jan 31, 2011 at 21:55, Felipe Sateler > wrote: On Fri, Jan 21, 2011 at 19:08, Felipe Sateler > wrote: On Fri, Jan 21, 2011 at 03:37, Hans-Christoph Steiner wrote: On Fri, 24 Dec 2010 15:37 -0800, "Hans-Christoph Steiner" wrote: On Dec 24, 2010, at 9:19 AM, Felipe Sateler wrote: On Wed, Dec 22, 2010 at 21:13, Hans-Christoph Steiner wrote: Just ITPed, packaged and uploaded pd-hid to git.debian.org. It is an object for Pure Data that allows you to use USB HID devices in Pd. The build system is similar in structure to pd-plugin and pd-freeverb, plus it includes the kFreeBSD and Hurd updates, so it should build on all platforms. It depends on pd-mapping and recommends pd- pddp, which are both in NEW. http://git.debian.org/?p=pkg-multimedia/pd-hid.git;a=summary There is some code that is not yours, please add Jan Truetzschler Falkenstein to the debian/copyright file (ftpmaster may reject the package for this missing information). Thanks for spotting that, I pushed the fix. Ping. Anyone willing to sponsor this one? Sorry, I lost track of this. I will try to get to this (and your other packages) during the weekend. I clearly didn't do this when promised, and this week I couldn't either. I've been extremely busy. I'm sorry about that. If someone else can look into these packages, please upload them, since I'm not likely to get any debian time anytime soon. I will, if nobody else gets to these packages, still review them as time permits. It seems that this package never got uploaded. It needs its git-dch done and the changelog finalized and then uploaded. I can finalize the changelog if that makes it easier. It seems some people want to do it themselves when uploading. I believe this package needs to be fixed for puredata >= 0.43 As far as I can tell it has already. For me, it builds on Debian/testing using puredata-dev and no puredata, and squeeze using puredata 0.42.6. Indeed, it seems to work. I have a licensing question though. The package is distributed as GPLv3+. However, Supercollider (where some code was borrowed) is GPLv2+. I think debian/copyright should document that fact. Code from 2004 cannot possibly be under GPLv3+ unless relicensed. The GPLv2+ license has that built into it. In the context of this project, the code from SuperCollider is so intermingled, there is no easily recognizable chunk that could be labeled GPLv2+. Since the project is GPLv3+, I think it would be misleading to try to say that a file is available under GPLv2+. If people want the GPLv2+ file, they should go to the original SuperCollider source. Here's the text from the GPL: "Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. " Indeed, I'm not questioning that. My point is that the objective of debian/copyright is documenting, not relicensing, even if it is permissible. From what I've seen, debian/copyright is not finer grained than files. The GPLv2+ code is mixed into two different files that are mostly GPLv3+. So if looking on a per-file basis, all of the files are GPLv3+. .hc Hey Felipe, Any chance of getting this one uploaded in the next week? I'd love to make the Ubuntu/oneiric import deadline. .hc 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 05:44 PM, Cyril Lavier wrote: 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. Hi. Here a first version, it works (I've tested it). There's a lot of things to backport, so in the next days, I will try to change audacious and audacious-plugins build dependencies to avoid backporting so many packages. It also needs the libvpx backport which I made for chromium. http://www.davromaniak.eu/vrac/backports/audacious/ If anybody can test it or review it. For testing it, you can use my repository : http://ddb.davromaniak.eu/ (deb http://ddb.davromaniak.eu/ squeeze-backports main). 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
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 (no description available) pn libmp3lame0(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
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
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
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
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
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
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 [2011-06-19 00:07]: On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof" wrote: * Hans-Christoph Steiner [2011-06-07 18:47]: On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: * Hans-Christoph Steiner [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
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
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
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
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
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+;;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
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
Re: OpenNi in Debian
* Hans-Christoph Steiner [2011-06-19 00:07]: > > On Wed, 08 Jun 2011 03:07 +0200, "Jochen Sprickerhof" > wrote: > > * Hans-Christoph Steiner [2011-06-07 18:47]: > > > > > > On Jun 7, 2011, at 6:44 PM, Jochen Sprickerhof wrote: > > > > > > >* Hans-Christoph Steiner [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