Bug#670608: jackd2: Please transition libjack-jackd2-0 for multiarch
Source: jackd2 Version: 1.9.8~dfsg.3+20120418gitf82ec715-4 User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hello: Please make this package compatible with multiarch, as described at http://wiki.debian.org/Multiarch/Implementation. More info: http://wiki.debian.org/ReleaseGoals/MultiArch Thanks, Miguel ___ 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: Helping with Maintenance of Packages in Debian
Am 26.04.2012 18:18, schrieb Hans-Christoph Steiner: When I read statements like Uploading ffmpeg would be a bad idea, it seems to me that the Debian-multimedia team has taken sides on the ffmpeg-libav fork dispute. That is not a position that a Debian team should take. Both ffmpeg and libav remain valuable free software that people want to use. And if someone is willing to do the work, Debian and Debian Multimedia should welcome both ffmpeg and libav. I disagree and second Andres' statement that uploading ffmpeg into Debian *now* in its current state is a bad idea. This is not because ffmpeg is bad per se - it isn't - it's just that we decided to go the libav route. This switch is not irrevocable, but so far no general problems have occured with libav and I think it fits better to Debian's release model. There is simply no pressing reason to switch back. Furthermore, currently libav and ffmpeg share the same library name space without being binary compatible - they are just not drop-in replacements for each other. This is also the reason for most of the bug reports we receive from users, who mixed up Debian packages built against libav with ffmpeg libraries from d-m.o. If we would re-introduce ffmpeg into Debian now, alongside libav, we'd have two choices. Either we get ffmpeg and libav binary-compatible and sustain this compatibility for all subsequent releases. Or we can live with the incompatibility, but then we sould have to rename the libraries of one of the projects and have to build each and every depending package twice, once against libav and once against ffmpeg - with appropriate package dependency declarations and migration plans. Do you think any of these alternatives is worth the effort? I don't! - Fabian ___ 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: tagging 660139
Processing commands for cont...@bugs.debian.org: tags 660139 + pending Bug #660139 [src:multicat] multicat: FTBFS(!linux) Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 660139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660139 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
Processed: tagging 660139
Processing commands for cont...@bugs.debian.org: tags 660139 - pending Bug #660139 [src:multicat] multicat: FTBFS(!linux) Removed tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 660139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660139 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#660139: Fwd: 660...@bugs.debian.org
I've filled CC wrongly, so resending this with a proper CC field set. Sorry for the inconvenience. -- Forwarded message -- From: Alessio Treglia ales...@debian.org Date: Fri, Apr 27, 2012 at 2:59 PM Subject: 660...@bugs.debian.org To: mass...@via.ecp.fr Hi Christophe, thanks for your patch. Unfortunately the package seems to fail to build on kFreeBSD again: make[1]: Entering directory `/tmp/buildd/multicat-2.0' cc -Wall -Wformat-security -O3 -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_ISOC99_SOURCE -D_BSD_SOURCE -g -c -o multicat.o multicat.c cc -Wall -Wformat-security -O3 -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -D_ISOC99_SOURCE -D_BSD_SOURCE -g -c -o util.o util.c util.c: In function 'GetInterfaceIndex': util.c:238:15: error: 'struct ifreq' has no member named 'ifr_ifindex' util.c: In function 'OpenSocket': util.c:600:33: error: storage size of 'imr' isn't known util.c:606:55: error: invalid application of 'sizeof' to incomplete type 'struct ip_mreqn' util.c:600:33: warning: unused variable 'imr' [-Wunused-variable] util.c: In function 'GetInterfaceIndex': util.c:242:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [util.o] Error 1 make[1]: Leaving directory `/tmp/buildd/multicat-2.0' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Regards, -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Transition of Ruby packages to the new Ruby policy
Hi! In a few weeks from now, Wheezy will be frozen. One of the goals of the Ruby Team for Wheezy is to try to push as far as possible the transition to a new policy for Ruby library. You receive this email because you are listed as the maintainer or uploader of a Ruby package which has been detected as not using this new policy. See the list of maintainers/packages at the end of this email. The Debian Ruby Team have put a lot of effort on this goal, converting (most of) the packages they maintain to this policy. The success of this effort can be measured on the graph [0]. 0: http://pkg-ruby-extras.alioth.debian.org/wheezy/ The data used for this graph taken into account *all* Ruby libraries contained in Debian, and not only those maintained by the Ruby packaging team. In order to improve the overall quality of Ruby packages in Debian and to ensure consistency in the way Ruby packages are installed and used, we need to finish the transition, and therefore we strongly encourage all maintainers of Ruby packages in Debian to update their packages to reflect these changes. These changes concern three different aspects: the package naming convention, the path where libraries are installed, and the execution of test suites at build time. These aspects are briefly described below and detailed in the draft of the Ruby policy [1], most of which being taken care of automatically by our packaging tool gem2deb. 1: http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-policy.git;=summary 2: http://packages.debian.org/sid/gem2deb Naming conventions == The source packages libfoo-ruby should be renamed ruby-foo. If these packages provide extensions needing to be compiled for the various Ruby versions, these should nevertheless be shipped in the same binary package, also called ruby-foo. If the package is mainly used as an application, then it can be named just foo. The naming convention can be of course adapted in the case of the packaging of utilities (chef, rails, redmine...). With the convention we used before, not only were we shipping distinct Ruby packages per interpreter version (i.e. libfoo-ruby1.8 and libfoo-ruby1.9.1) and needed to hold large-scale repackaging on ABI jumpis (as in the latest 1.9 → 1.9.1 change). With this new convention (and build system – read on for details) only one binary package will be built, and will carry all of the needed components, either in a common place or in the version-specific directories. For more extensive information see our guidelines for Ruby packaging [3]. 3: http://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging Install locations for libraries === Libraries not bundled with the Ruby interpreters should be installed somewhere in /usr/lib/ruby/vendor_ruby directory, instead of /usr/lib/ruby/1.8 or /usr/lib/ruby/1.9.1. A Pure Ruby library working for all Ruby version would go in /usr/lib/ruby/vendor_ruby. Files specific to a version of the interpreter should go in /usr/lib/ruby/vendor_ruby/$RUBYVER (vendorlibdir). Code compiled specifically for the host architecture should go to /usr/lib/ruby/vendor_ruby/$RUBYVER/$ARCH (vendorarchdir). For the moment, MRI Ruby 1.8 and 1.9 can use the libraries installed in these directories. JRuby would need to have theses directories added to $LOAD_PATH and advertised by RbConfig (see #663342). Running test suites during package build A large number of Ruby libraries provide a test suite. It is recommended to run these tests during the construction of the package in order to check that the package will (at least partially) work with the interpreters and other libraries included in the distribution. A new packaging tool: gem2deb = The gem2deb tool takes care of most of the points mentioned above in an automatised way. Running gem2deb on your orig tarball or a gem package from your upstream will get you most of the way towards making your package compatible with the new draft Ruby policy. Instructions for the transition to gem2deb are available on the wiki page [4] of the team. 4: http://wiki.debian.org/Teams/Ruby/Packaging#Howto:_converting_a_package_from_ruby-pkg-tools_to_gem2deb gem2deb builds binary packages which are amenable to all of the currently existing Ruby interpreters, and is future-proofed so that when a new one is included in Debian, all of our packages will gain support with just a rebuild. It also adds niceties such as proper Gem following via debian/watch or packaging with simple, current practices for debian/*. Please do consider repackaging using it! To conclude, we encourage you to update these Ruby packages packages so that they follow the guidelines above. Everyone willing to team maintain their Ruby packages is of course welcome to join the Ruby Packaging team (pkg-ruby-extras on alioth) and import their packages in the team repository. We
Bug#670647: liblilv-0-0: Please upgrade package to latest upstream 0.14.2
Package: liblilv-0-0 Version: 0.5.0+dfsg0-1 Severity: normal As per http://drobilla.net/software/lilv/, there is a much newer version out. Ardour 3 (yes I know it's not in Debian yet) needs it in order to work with LV2 plugins. Antony -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages liblilv-0-0 depends on: ii libc62.13-30 ii libserd-0-0 0.5.0+dfsg0-2 ii libsord-0-0 0.5.0+dfsg0-2 liblilv-0-0 recommends no packages. liblilv-0-0 suggests no packages. -- 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#670647: liblilv-0-0: Please upgrade package to latest upstream 0.14.2
severity 670647 wishlist block 670647 by 669232 thanks Hi Antony, thanks for reporting this. On Fri, Apr 27, 2012 at 5:31 PM, Antony Gelberg antony.gelb...@gmail.com wrote: Package: liblilv-0-0 Version: 0.5.0+dfsg0-1 Severity: normal As per http://drobilla.net/software/lilv/, there is a much newer version out. Yes, I know and I'm waiting for the new lv2 package to be accepted by the FTP masters to upgrade this along with the whole LV2 stack. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ 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: Re: Bug#670647: liblilv-0-0: Please upgrade package to latest upstream 0.14.2
Processing commands for cont...@bugs.debian.org: severity 670647 wishlist Bug #670647 [liblilv-0-0] liblilv-0-0: Please upgrade package to latest upstream 0.14.2 Severity set to 'wishlist' from 'normal' block 670647 by 669232 Bug #670647 [liblilv-0-0] liblilv-0-0: Please upgrade package to latest upstream 0.14.2 670647 was not blocked by any bugs. 670647 was not blocking any bugs. Added blocking bug(s) of 670647: 669232 thanks Stopping processing here. Please contact me if you need assistance. -- 670647: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670647 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
tsdecrypt 8.0-2 MIGRATED to testing
FYI: The status of the tsdecrypt source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 8.0-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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Helping with Maintenance of Packages in Debian
On Apr 26, 2012, at 3:31 PM, Reinhard Tartler wrote: On Thu, Apr 26, 2012 at 6:18 PM, Hans-Christoph Steiner h...@at.or.at wrote: ffmpeg provides many things that libav does not. For example, I have written an audio redaction plugin for ffmpeg. Such a plugin is not possible in libav. Please elaborate. What makes this impossible. Maybe you can point to your plugin? From what I can tell, they improved the audio plugin API in ffmpeg 0.9 quite a bit. When I was programming my plugin, I looked at both libav and ffmpeg. It wasn't until I looked at ffmpeg 0.9 that it seemed feasible. I attached my plugin source code: af_aredact.c Description: Binary data .hc “We must become the change we want to see. - Mahatma Gandhi ___ 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: Helping with Maintenance of Packages in Debian
On Apr 27, 2012, at 7:21 AM, Fabian Greffrath wrote: Am 26.04.2012 18:18, schrieb Hans-Christoph Steiner: When I read statements like Uploading ffmpeg would be a bad idea, it seems to me that the Debian-multimedia team has taken sides on the ffmpeg-libav fork dispute. That is not a position that a Debian team should take. Both ffmpeg and libav remain valuable free software that people want to use. And if someone is willing to do the work, Debian and Debian Multimedia should welcome both ffmpeg and libav. I disagree and second Andres' statement that uploading ffmpeg into Debian *now* in its current state is a bad idea. This is not because ffmpeg is bad per se - it isn't - it's just that we decided to go the libav route. This switch is not irrevocable, but so far no general problems have occured with libav and I think it fits better to Debian's release model. There is simply no pressing reason to switch back. We do not disagree at all on this point. I'm not saying that we should just upload ffmpeg as is, obviously it would be stupid to upload ffmpeg if it broke things. But we should welcome anyone who wants to do the work to make it possible to install libav and ffmpeg at the same time, or any other reasonable solution. And since this is a very political issue, we do need to speak carefully and clearly. That's why I object to the statement Uploading ffmpeg would be a bad idea. It is very broad, and wrong from some legitimate Debian-specific points of view. Furthermore, currently libav and ffmpeg share the same library name space without being binary compatible - they are just not drop-in replacements for each other. This is also the reason for most of the bug reports we receive from users, who mixed up Debian packages built against libav with ffmpeg libraries from d-m.o. From what I know, this really seems to me a question for libav itself. IMHO, it is a version of the code with a new name, so that seems that the burden falls on libav to do it. And for the record, I have zero interest in getting involved in the politics, and I don't even want to know what happened to cause the libav fork. I am just offering a Debian user's perspective on two pieces of valuable software that have some technical conflicts. If we would re-introduce ffmpeg into Debian now, alongside libav, we'd have two choices. Either we get ffmpeg and libav binary-compatible and sustain this compatibility for all subsequent releases. Or we can live with the incompatibility, but then we sould have to rename the libraries of one of the projects and have to build each and every depending package twice, once against libav and once against ffmpeg - with appropriate package dependency declarations and migration plans. Do you think any of these alternatives is worth the effort? I don't! I'm specifically interested in the ffmpeg command line util, I don't really need all the libraries. That wouldn't be hard to package. As for libraries, how about putting the ffmpeg versions into /usr/include/ffmpeg and /usr/lib/ffmpeg? Then if someone wants to build against them, they can add -I/usr/include/ffmpeg and -L/usr/lib/ffmpeg. For most projects that use the libav* libraries, there probably wouldn't be any difference between using the ffmpeg or libav versions, so it would be silly to make all packages for both. And of course, I'm not telling anyone that they should do the work here. I am saying we should welcome anyone who wants to do it. Oops, I guess I already said that ;) .hc All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
HALLO ...
I have send a mail to you before but not yet heard from you. do you get my mail? I am still waiting for your urgent response. Yours alone, Akpa Blessing. Ich habe eine Mail an Sie vor, aber noch nicht von dir gehört. bekommst du meine E-Mails? Ich warte immer noch auf Ihre dringende Antwort. Mit freundlichen allein, Akpa Segen.___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
