Re: ITP: libcrystalhd2 -- Library for Broadcom Crystal HD video decoder cards
On Tuesday 10 August 2010 23:38:09 Reinhard Tartler wrote: On Tue, Aug 10, 2010 at 14:39:19 (EDT), Andres Mejia wrote: Is there any progress with getting libcrystalhd2 into Debian? I would like to help if that's alright. just curious, is this a driver package? what kind of hardware does it support, and how big is the expected userbase? This is just for packaging the library. Driver is in mainstream kernel as of 2.6.34 so there's no need for us to package that. Firmware can't be included because it's under a non-free license. Here's the firmware license. FIRMWARE BINARIES ARE DISTRIBUTED UNDER THE FOLLOWING LICENSE - BINARIES COVERED WITH THIS LICENSE ARE bcm70015fw.bin and bcm70012fw.bin Copyright 2007-2010 Broadcom Corporation Redistribution and use in binary forms of this software, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Broadcom nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED “AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BROADCOM BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Note that redistribution is only allowed in binary form and *without* modification. Perhaps it's better for the firmware to be shipped with firmware-linux-nonfree anyway. -- Regards, Andres Mejia ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On 2010-08-16 03:31, Hans-Christoph Steiner wrote: I'm not a pd expert, but if I install some extensions, I expect to be able to use them right away, without having to invoke pd with special args. I'm getting the impression that we are not living up to that expectation. You can use them right away the way they are being installed right now. Just like in python when you install a library, you still need to tell it to import it before using it. In Pd its similar, but messier. There is the [import] and [declare] objects for doing this in the Pd patches themselves, and there is the -lib command line option. and of course you can tell the interpreter to load certain libraries on startup by the means of a preference system (this is most likely the most commonly used case). but it seems like the README.Debian is indeed a bit confusing; maybe someone with better control of the english language could rephrase it (ideally somebody with good Pd-knowledge like hans). the reason why this info is in README.Debian and not in (e.g.) README is, that upstream's README does not include this information (mea culpa). the reason why it ought to be mentioned somewhere, is that (upstream) zexy is special in the way, that is a library consisting of both binary and interpreter files, and Pd handles these 2 kinds differently. that's why i make all the fuzz about -path and -lib mfgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#588468: vlc should provide correct error message
Package: vlc Version: 1.1.2-1 Severity: normal Among with the error reported into bug #588468, vlc displays an error message in the gnome GUI which says there is nothing to do to correct this problem. Instead, it should tell the user to install the vlc-plugin-zbvi package. With best regards, Hugues HIEGEL -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (900, 'stable'), (100, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.29.1-initramfs (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc depends on: ii libaa1 1.4p5-38 ascii art library ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libfreetype62.4.0-2 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.4.4-8GCC support library ii libgl1-mesa-glx [libgl1 7.7.1-4 A free implementation of the OpenG ii libqtcore4 4:4.6.3-1Qt 4 core module ii libqtgui4 4:4.6.3-1Qt 4 GUI module ii libsdl-image1.2 1.2.10-2+b1 image loading library for Simple D ii libsdl1.2debian 1.2.14-6 Simple DirectMedia Layer ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3 ii libtar 1.2.11-6 C library for manipulating tar arc ii libvlccore4 1.1.2-1 base library for VLC and its modul ii libx11-62:1.3.3-3X11 client-side library ii libx11-xcb1 2:1.3.3-3Xlib/XCB interface library ii libxcb-keysyms1 0.3.6-1 utility libraries for X C Binding ii libxcb-randr0 1.6-1X C Binding, randr extension ii libxcb-shm0 1.6-1X C Binding, shm extension ii libxcb-xv0 1.6-1X C Binding, xv extension ii libxcb1 1.6-1X C Binding ii libxext62:1.1.2-1X11 miscellaneous extension librar ii ttf-dejavu-core 2.31-1 Vera font family derivate with add ii vlc-nox 1.1.2-1 multimedia player and streamer (wi ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages vlc recommends: ii vlc-plugin-notify 1.1.2-1LibNotify plugin for VLC ii vlc-plugin-pulse 1.1.2-1PulseAudio plugin for VLC Versions of packages vlc suggests: pn mozilla-plugin-vlcnone (no description available) pn videolan-doc none (no description available) Versions of packages vlc-nox depends on: ii liba52-0.7.40.7.4-14 library for decoding ATSC A/52 str ii libasound2 1.0.23-1 shared library for ALSA applicatio ii libass4 0.9.9-1 library for SSA/ASS subtitles rend ii libavahi-client30.6.26-1 Avahi client library ii libavahi-common30.6.26-1 Avahi common library ii libavc1394-00.5.3-1+b2 control IEEE 1394 audio/video devi ii libavcodec524:0.5.2-1ffmpeg codec library ii libavformat52 4:0.5.2-1ffmpeg file format library ii libavutil49 4:0.5.2-1ffmpeg utility library ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcaca00.99.beta17-1colour ASCII art library ii libcddb21.3.2-2 library to access CDDB data - runt ii libcdio10 0.81-4 library to read and control CD-ROM ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst ii libdc1394-222.1.2-3 high level programming interface f ii libdca0 0.0.5-3 decoding library for DTS Coherent ii libdirac-encoder0 1.0.2-3 open and royalty free high quality ii libdvbpsi6 0.1.7-1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-7 DVD navigation library ii libdvdread4 4.1.3-10 library for reading DVDs ii libebml00.7.7-3.1access library for the EBML format ii libfaad22.7-4freeware Advanced Audio Decoder - ii libflac81.2.1-2+b1 Free Lossless Audio Codec - runtim ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.0-2 FreeType 2 font engine, shared lib ii libfribidi0 0.19.2-1 Free Implementation of the Unicode ii libgcc1 1:4.4.4-8GCC support library ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgnutls26 2.8.6-1
Re: Licensing of gmerlin-avdecoder regression tests
Hi, hope this gets through, since I'm not subscribed. Am 14.08.2010 23:04, schrieb Jonas Smedegaard: Hi Burkhard (cc public Debian multimedia team mailinglist), I am a Debian developer and recently got involved in the maintainance of multimedia project packaging. During a copyright and licensing audit I noticed an oddity of the headers for regression tests in your gmerlin-avdecoder project: It contains a copyright and parts of the standard GPL boilerplate, but lacks the first part actually declaring GPL as the license. Technically you do not permit redistribution of those tests, which I suspect was unintentional. I suggest you adjust the headers of those files for next release of your project. Added my standard copyright header to tests/*.c in CVS. More troublesome, but maybe also more difficult to solve, I discovered that some source files are licensed as 4-clause BSD which is incompatible with GPLv2. These are the files I found containing 4-clause BSD licensing: lib/os.c (at line 93) include/bgav_sem.h lib/base64.c As IOhannes already mentioned, all stuff except lib/base64.c are fallbacks for non-Posix systems (mainly windows). We'll try to get GPLed base64 routines. Burkhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: ITP: libcrystalhd2 -- Library for Broadcom Crystal HD video decoder cards
On Mon, Aug 16, 2010 at 08:19:40 (CEST), Andres Mejia wrote: On Tuesday 10 August 2010 23:38:09 Reinhard Tartler wrote: On Tue, Aug 10, 2010 at 14:39:19 (EDT), Andres Mejia wrote: Is there any progress with getting libcrystalhd2 into Debian? I would like to help if that's alright. just curious, is this a driver package? what kind of hardware does it support, and how big is the expected userbase? This is just for packaging the library. Driver is in mainstream kernel as of 2.6.34 so there's no need for us to package that. Firmware can't be included because it's under a non-free license. Here's the firmware license. Ah, makes sense. Thanks for the explanation. I think this package makes most sense for our team if at least two members of our team can actually test and use those cards. This requires running a 2.6.34 kernel and using this firmware. Otherwise I'm not so sure. FIRMWARE BINARIES ARE DISTRIBUTED UNDER THE FOLLOWING LICENSE - BINARIES COVERED WITH THIS LICENSE ARE bcm70015fw.bin and bcm70012fw.bin Copyright 2007-2010 Broadcom Corporation Redistribution and use in binary forms of this software, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Broadcom nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED “AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BROADCOM BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Note that redistribution is only allowed in binary form and *without* modification. Perhaps it's better for the firmware to be shipped with firmware-linux-nonfree anyway. Makes sense to me. -- 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: Licensing of gmerlin-avdecoder regression tests
On Mon, Aug 16, 2010 at 11:12:29 (CEST), Burkhard Plaum wrote: More troublesome, but maybe also more difficult to solve, I discovered that some source files are licensed as 4-clause BSD which is incompatible with GPLv2. These are the files I found containing 4-clause BSD licensing: lib/os.c (at line 93) include/bgav_sem.h lib/base64.c As IOhannes already mentioned, all stuff except lib/base64.c are fallbacks for non-Posix systems (mainly windows). We'll try to get GPLed base64 routines. Just a suggestion, the gnulib contains a lot of portability functions that can be copied into your codebase: http://www.gnu.org/software/gnulib/MODULES.html#module=base64 http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/base64.c;h=4939ce749a5e7c84afd286f871582ee30f298c3b;hb=c5728261c324a75f8d23dd7d10cb42dde9420227 -- 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: gmerlin-avdecoder redux
On Mon, Aug 16, 2010 at 01:12:14AM -0400, Hans-Christoph Steiner wrote: On Sat, 2010-08-14 at 21:30 +0200, IOhannes m zmölnig wrote: Another little detail, I recall that gmerlin-avdecoder 1.0.3 depends on a certain version on gavl, I believe that's 1.1.1 or 1.1.2. Also, I don't quite understand the cdbs files, but there are a bunch of dependencies with versions in the Fink package that are probably relevant here: http://fink.cvs.sourceforge.net/fink/dists/10.4/unstable/main/finkinfo/libs/gmerlin-avdecoder1.info?view=markup Ah, thanks for that reference! I would like to examine each and every explicitly stated build-dependency thoroughly at some point, but haven't gotten that far yet. When I do, above alternative set of build-dependencies are useful for a cross-check. :-) I guess what is relevant about CDBS here is 2 things: * debian/control is autogenerated - edit debian/control.in instead * cdbs-inherited build-dependencies are auto-resolved CDBS does not resolve build-dependencies tied to upstream code, only e.g. autotools-related packages when autotools.mk is included. If it was something else about cdbs which puzzled you then please tell, and I will try clarify. Regards, - 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: Licensing of gmerlin-avdecoder regression tests
On Mon, Aug 16, 2010 at 11:12:29AM +0200, Burkhard Plaum wrote: hope this gets through, since I'm not subscribed. Worked fine (not sure if strings were pulled behind the curtain) Am 14.08.2010 23:04, schrieb Jonas Smedegaard: Hi Burkhard (cc public Debian multimedia team mailinglist), I suggest you adjust the headers of [regression tests] for next release of your project. Added my standard copyright header to tests/*.c in CVS. Good. More troublesome, but maybe also more difficult to solve, I discovered that some source files are licensed as 4-clause BSD which is incompatible with GPLv2. These are the files I found containing 4-clause BSD licensing: lib/os.c (at line 93) include/bgav_sem.h lib/base64.c As IOhannes already mentioned, all stuff except lib/base64.c are fallbacks for non-Posix systems (mainly windows). Ok. I am unsure on concensus in Debian regarding licensing of *fractions* of files. As I understand it, in principle we are safe if we can ensure that 4-clause BSD only affects code parts that are not compiled into any of the binary code that we redistribute. Ideal for us (and for other distributors, I guess) would be if those 4-clause BSD parts was placed in separate files by you upstream. That way we could strip them completely from our redistributed source (as we do already with lib/libw32dll and lib/GSM610). If we should play safe with current source, it is technically possible for us to patch away problematic file parts during source tarball repackaging, but that is ugly, as that blurs what is upstream work and what we hacked on. We'll try to get GPLed base64 routines. Good. Thanks for all your help with this. - 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
Bug#593162: marked as done (audacity: Audacity fails to load libavformat)
On Mon, Aug 16, 2010 at 12:39:13PM +0200, Reinhard Tartler wrote: On Mon, Aug 16, 2010 at 09:25:12 (CEST), Aaron Barany wrote: and the standard squeeze install has 0.5.1. (which also means that the standard squeeze libraries might experience the same problem) And I've asked you to check this. Until this happens, I'd agree to leave this bug closed. Whoops: I reopened again before above arrived in my inbox. I will simply leave this bugreport alone for a little while now - reopened and all. Kind regards, - 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: uploaded first pkg: pd-motex
On Sun, Aug 15, 2010 at 08:28:05PM -0400, Alexandre Quessy wrote: Hello, 2010/8/12 Jonas Smedegaard d...@jones.dk: 2. Release a tarball (with debian subdir stripped) I just wanted to stress out the fact that the debian directory need to be out of the upstream tarball. (and repository) It took me a few week to get that part. Once it's done, packaging is a lot easier... :) Actually, this is not necessarily true any longer. For Squeeze and newer releases, it is recommended to use the DKPG source format 3.0 (quilt), which ignores an upstream debian subdir. From the manpage of (a recent packaging of) dpkg-source: The debian tarball is extracted on top of the source directory after prior removal of any pre-existing debian directory. It is still the most elegant way to release an upstream tarball without redistribution noise IMO, even if Debian and its derivatives now are able to suppress it :-) Kind regards, - 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: Licensing of gmerlin-avdecoder regression tests
On 2010-08-16 13:21, Jonas Smedegaard wrote: As I understand it, in principle we are safe if we can ensure that 4-clause BSD only affects code parts that are not compiled into any of the binary code that we redistribute. Ideal for us (and for other distributors, I guess) would be if those 4-clause BSD parts was placed in separate files by you upstream. That i have submitted a patch to burkhard (and he has quickly incorporated it in upstream - thanks again) that does: - rebase lib/base64.c on a clause-3 BSD licensed version of the file (the new base is http://mediatools.cs.ucl.ac.uk/nets/mmedia/browser/common/trunk/src/base64.c, which is simply a re-licensed (with agreement by the copyright owner) version of the original file) - lib/os.c has the BSD-code moved away into lib/os_inet_aton.c (which can be excluded by us) - include/bgav_sem.h has the BSD-code moved out into include/bgav_sem_bsd.h (which can be excluded by us) so i think the issues are now fixed upstream... fgmar IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[Thank you] Terminal server/Workstation
I love debian GNU/Linux because this linux distro after being installed is ready for use and play music off-line. This is perfect where people don't have internet connectivity. The box installed either with Debian GNU/Linux lenny or Debian Edu 5.0.4 will run perfectly well and users/students/pupils can play music/videos/programme/ use mysql/postgresql database out the box. -- This is message was sent to you from http://thanks.debian.net ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: gmerlin-avdecoder redux
On 15/08/10 07:13, Jonas Smedegaard wrote: On Sun, Aug 15, 2010 at 11:33:51AM +0200, IOhannes m zmölnig wrote: On 08/15/2010 09:00 AM, Reinhard Tartler wrote: On Sat, Aug 14, 2010 at 21:30:32 (CEST), IOhannes m zmölnig wrote: Well, the point of symbols file is actually to review the list of symbols manually, so automatically updating it really defeats its purpose. If (and only if) you are really sure that no other package actually uses the removed symbols, then it's OK to remove them. well, libgmerlin-avdec1 has never been in Debian, so no other package can possibly depend on symbols in this package. so i guess, we are safe on this side. otoh, libgmerlin-avdec1 has been in marillat's debian-multimedia. packages that used this package and depend on the symbols, will break. how is this normally dealt with? In my opinion Debian is upstream to Marillats archive, Ubuntu, Skolelinux and a lot of others, and if any of those start being creative and do things not in Debian, then it is their own headache to untangle themselves again if it clashes with what Debian decides to do later on. In other words, it makes sense to me to have it in mind now that we happen to know about this issue, but if we cannot solve a clash with a downstream distro easily and without carrying odd baggage in the package afterwards, then we should let it clash and leave it to downstream to solve it at their end. Perhaps even be nice and inform them that we are aware of this clash (but without apologizing - it really is their own fault IMO). ...but that's me. I can very well imagine others here having different opinion, if not about Marillat then about Ubuntu. We had a recent discussion about derivative-specific package dependencies with the result that I will keep baggage in the source (but not in binary packages) regarding firefox (shipped in Ubuntu but not Debian) using dpkg-vendor. Note that there is a not so slight difference between Marillat's archive and Ubuntu. Namely, that in this team we have people that work on both debian and ubuntu (which is why it makes sense to do stuff for ubuntu too). Marillat does not work with us, and a while ago effectively worked against us. -- 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
traverso_0.49.2-1_i386.changes ACCEPTED
Accepted: traverso_0.49.2-1.debian.tar.gz to main/t/traverso/traverso_0.49.2-1.debian.tar.gz traverso_0.49.2-1.dsc to main/t/traverso/traverso_0.49.2-1.dsc traverso_0.49.2-1_i386.deb to main/t/traverso/traverso_0.49.2-1_i386.deb traverso_0.49.2.orig.tar.gz to main/t/traverso/traverso_0.49.2.orig.tar.gz Override entries for your package: traverso_0.49.2-1.dsc - source sound traverso_0.49.2-1_i386.deb - optional sound Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Introduction
Hi! My name is Thomas Maass from Germany. I am working with Debian several years. I have started with SuSe 8.0, and came to Debian with Woody. Since then I stayed on Debian. Now I want to help. I'd like to join the Debian multimedia team. I have created an alioth account and subscribed to the mailing lists. I have build several packages for private use, and I want to give my work to the Debian project. The first package I'd like to upload is called clipgrab. It is a GUI application written in QT to download from several videoportals like Youtube, MyVideo, Sevenload etc. You can also directly convert into several videoformats. I hope, you add me to your group! Thank you! Thomas signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: gmerlin-avdecoder redux
On Mon, Aug 16, 2010 at 10:32:44AM -0400, Felipe Sateler wrote: On 15/08/10 07:13, Jonas Smedegaard wrote: On Sun, Aug 15, 2010 at 11:33:51AM +0200, IOhannes m zmölnig wrote: On 08/15/2010 09:00 AM, Reinhard Tartler wrote: On Sat, Aug 14, 2010 at 21:30:32 (CEST), IOhannes m zmölnig wrote: Well, the point of symbols file is actually to review the list of symbols manually, so automatically updating it really defeats its purpose. If (and only if) you are really sure that no other package actually uses the removed symbols, then it's OK to remove them. well, libgmerlin-avdec1 has never been in Debian, so no other package can possibly depend on symbols in this package. so i guess, we are safe on this side. otoh, libgmerlin-avdec1 has been in marillat's debian-multimedia. packages that used this package and depend on the symbols, will break. how is this normally dealt with? In my opinion Debian is upstream to Marillats archive, Ubuntu, Skolelinux and a lot of others, and if any of those start being creative and do things not in Debian, then it is their own headache to untangle themselves again if it clashes with what Debian decides to do later on. In other words, it makes sense to me to have it in mind now that we happen to know about this issue, but if we cannot solve a clash with a downstream distro easily and without carrying odd baggage in the package afterwards, then we should let it clash and leave it to downstream to solve it at their end. Perhaps even be nice and inform them that we are aware of this clash (but without apologizing - it really is their own fault IMO). ...but that's me. I can very well imagine others here having different opinion, if not about Marillat then about Ubuntu. We had a recent discussion about derivative-specific package dependencies with the result that I will keep baggage in the source (but not in binary packages) regarding firefox (shipped in Ubuntu but not Debian) using dpkg-vendor. Note that there is a not so slight difference between Marillat's archive and Ubuntu. Namely, that in this team we have people that work on both debian and ubuntu (which is why it makes sense to do stuff for ubuntu too). Marillat does not work with us, and a while ago effectively worked against us. True, we represent multiple distributions here. This affect what kinds of issues we become aware of and is dear to us, and it eases tremendously some coordination for some cases where these distributions differ. I welcome this cross-distro collaboration and would love to see even more distros joining forces with us! The nature and scope of our teamwork should however not affect the packaging style/quality of our efforts, IMO. I, too, am involved in devoping derivatives of Debian (Skolelinux in particular), yet insist - even when it leads to a larger burden on myself as I sometimes then need to some tasks twice - to follow the principle of not burdening or entangling upstream with downstream diversions. - 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
Bug#591802: FTBFS on sparc: [po/fr/LC_MESSAGES/csound5.mo] Error -11
Dear release team, On 14/08/10 10:31, Felipe Sateler wrote: On 06/08/10 14:12, Cyril Brulebois wrote: Felipe Sateler fsate...@debian.org (06/08/2010): I also just managed to build it on smetana. Looks like the buildd is borked. What should I do next? I guess I'm going to give it back again and again, until it builds… I'm open to any ideas, of course. I don't have any... other than uploading the binary I built on smetana. Should I do that? And I really think this bug is not in csound. What should I do about this? -- 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: [SCM] faad2 packaging branch, master, updated. debian/2.7-4-5-ga421d73
On 16/08/10 10:36, fabian-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit a421d733a6b9f24c72326e08bddccdbd5bc0ddf3 Author: Fabian Greffrath fab...@greffrath.com Date: Mon Aug 16 16:39:32 2010 +0200 Extend file name buffers for longer path names. diff --git a/debian/patches/path_max.patch b/debian/patches/path_max.patch new file mode 100644 index 000..c606354 --- /dev/null +++ b/debian/patches/path_max.patch @@ -0,0 +1,27 @@ +Description: Extend file name buffers for longer path names. +Author: Fabian Greffrath fabian+deb...@greffrath.com +Forwarded: me...@audiocoding.com + +--- faad2.orig/frontend/main.c faad2/frontend/main.c +@@ -42,6 +42,7 @@ + #include stdlib.h + #include string.h + #include getopt.h ++#include limits.h + + #include neaacdec.h + #include mp4ff.h +@@ -1107,9 +1108,9 @@ int main(int argc, char *argv[]) + int mp4file = 0; + int noGapless = 0; + char *fnp; +-char aacFileName[255]; +-char audioFileName[255]; +-char adtsFileName[255]; ++char aacFileName[PATH_MAX + 1]; ++char audioFileName[PATH_MAX + 1]; ++char adtsFileName[PATH_MAX + 1]; I believe not all archs have PATH_MAX. I'm almost positive that hurd doesn't have it. -- 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
audacity 1.3.12-5 MIGRATED to testing
FYI: The status of the audacity source package in Debian's testing distribution has changed. Previous version: 1.3.12-4 Current version: 1.3.12-5 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jconvolver 0.8.7-2 MIGRATED to testing
FYI: The status of the jconvolver source package in Debian's testing distribution has changed. Previous version: 0.8.7-1 Current version: 0.8.7-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] faad2 packaging branch, master, updated. debian/2.7-4-5-ga421d73
On Mon, Aug 16, 2010 at 12:27:14PM -0400, Felipe Sateler wrote: +-char aacFileName[255]; +-char audioFileName[255]; +-char adtsFileName[255]; ++char aacFileName[PATH_MAX + 1]; ++char audioFileName[PATH_MAX + 1]; ++char adtsFileName[PATH_MAX + 1]; I believe not all archs have PATH_MAX. I'm almost positive that hurd doesn't have it. Exactly. The common workaround is to dynamically allocate the filename buffers depending on the actual filename length. This seems to be a pretty big patch that should be implemented upstream. As a workaround, one might get along with something like this: #ifndef PATH_MAX #define PATH_MAX 1024 #endif See http://www.gnu.org/software/hurd/hurd/porting/guidelines.html for more information. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
qsampler 0.2.2-2 MIGRATED to testing
FYI: The status of the qsampler source package in Debian's testing distribution has changed. Previous version: 0.2.2-1 Current version: 0.2.2-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[Thank you] Thanks
Thanks everyone for helping to mentor me however stupid the questions and happy Debian Appreciation Day! -- This is message was sent to you from http://thanks.debian.net ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
[Thank you] Thanks
Thanks for the effort guys. Really is much appreciated. Words are not enough to thank. -- This is message was sent to you from http://thanks.debian.net ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote: On 2010-08-16 03:31, Hans-Christoph Steiner wrote: I'm not a pd expert, but if I install some extensions, I expect to be able to use them right away, without having to invoke pd with special args. I'm getting the impression that we are not living up to that expectation. You can use them right away the way they are being installed right now. Just like in python when you install a library, you still need to tell it to import it before using it. In Pd its similar, but messier. There is the [import] and [declare] objects for doing this in the Pd patches themselves, and there is the -lib command line option. and of course you can tell the interpreter to load certain libraries on startup by the means of a preference system (this is most likely the most commonly used case). but it seems like the README.Debian is indeed a bit confusing; maybe someone with better control of the english language could rephrase it (ideally somebody with good Pd-knowledge like hans). the reason why this info is in README.Debian and not in (e.g.) README is, that upstream's README does not include this information (mea culpa). the reason why it ought to be mentioned somewhere, is that (upstream) zexy is special in the way, that is a library consisting of both binary and interpreter files, and Pd handles these 2 kinds differently. that's why i make all the fuzz about -path and -lib mfgasdr IOhannes I don't see why this is Debian-specific though. It really is an upstream issue, this should be documented as part of zexy, not Debian. .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On 16/08/10 14:24, Hans-Christoph Steiner wrote: On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote: On 2010-08-16 03:31, Hans-Christoph Steiner wrote: I'm not a pd expert, but if I install some extensions, I expect to be able to use them right away, without having to invoke pd with special args. I'm getting the impression that we are not living up to that expectation. You can use them right away the way they are being installed right now. Just like in python when you install a library, you still need to tell it to import it before using it. In Pd its similar, but messier. There is the [import] and [declare] objects for doing this in the Pd patches themselves, and there is the -lib command line option. and of course you can tell the interpreter to load certain libraries on startup by the means of a preference system (this is most likely the most commonly used case). but it seems like the README.Debian is indeed a bit confusing; maybe someone with better control of the english language could rephrase it (ideally somebody with good Pd-knowledge like hans). the reason why this info is in README.Debian and not in (e.g.) README is, that upstream's README does not include this information (mea culpa). the reason why it ought to be mentioned somewhere, is that (upstream) zexy is special in the way, that is a library consisting of both binary and interpreter files, and Pd handles these 2 kinds differently. that's why i make all the fuzz about -path and -lib I don't see why this is Debian-specific though. It really is an upstream issue, this should be documented as part of zexy, not Debian. I think I understand now, and I agree with Hans. That documentation should go upstream, not in a debian readme. -- 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
Bug#593162: marked as done (audacity: Audacity fails to load libavformat)
Well, for exactly reasons like this, I find installing libraries from 3rd party repositories problematic at least. I agree it's not ideal, but unfortunately there's some functionality that isn't present in the main repositories. (for example, a build of gtkpod that supports AAC) And I've asked you to check this. Until this happens, I'd agree to leave this bug closed. It would be great if you could help with filling the gaps. Since that's the case, I can try both the testing and experimental versions, but most likely it will be this weekend or the next when I have the time. Aaron On Mon, Aug 16, 2010 at 3:39 AM, Reinhard Tartler siret...@tauware.dewrote: On Mon, Aug 16, 2010 at 09:25:12 (CEST), Aaron Barany wrote: Just to provide a bit more information, I'm using debian-multimedia, which is why my ffmpeg libraries are newer than what's in the standard debian repositories. This thread on Audacity forums ( http://forum.audacityteam.org/viewtopic.php?f=18t=28048) documents the problem, and also includes a patch. According to that thread, the change appeared in ffmpeg 0.5.1. If I'm reading the version numbers correctly, both debian-multimedia and experimental have ffmpeg 0.6 (with slightly newer version in debian-multimedia), the package distributed by debian-multimedia is not based on ffmpeg 0.6, it is just horribly and confusingly named. It is based on SVN trunk, were a lot of development is going on, and such compatibility bugs still need to be found and ironed out. Christian Marillat is obviously not helping with that at all. and the standard squeeze install has 0.5.1. (which also means that the standard squeeze libraries might experience the same problem) And I've asked you to check this. Until this happens, I'd agree to leave this bug closed. I would prefer not to try to install a different version of the libraries since I don't have any experience working with different repositories like that, especially since I would have to deal with the dependencies. Well, for exactly reasons like this, I find installing libraries from 3rd party repositories problematic at least. (I'm mainly worried about getting everything back together again when I'm done...) If somebody could try it on a standard testing and/or experimental install that would be great. Well, you've reported an imcomplete bug, and I've told you what information is missing. It would be great if you could help with filling the gaps. -- 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: gmerlin-avdecoder redux
On 2010-08-12 19:33, Hans-Christoph Steiner wrote: Do you think you could do the upstream-tarball.mk thing to the gmerlin-avdecoder package? The folders in question are: lib/libwin32dll lib/GSM610 regarding the lib/GSM610 folder, on the gmerlin list people don't see why it shouldn't be compatible with GPL: On 2010-08-16 16:47, Romain Beauxis wrote: Le lundi 16 août 2010 07:36:05, IOhannes m zmoelnig a écrit : the Debian packages currently - exclude the libw32dll stuff (see other post) - exclude the GSM610stuff (see other post) I fail to see why this piece of code had to be removed. Its licence is: Copyright 1992, 1993, 1994 by Jutta Degener and Carsten Bormann, Technische Universitaet Berlin Any use of this software is permitted provided that this notice is not removed and that neither the authors nor the Technische Universitaet Berlin are deemed to have made any representations as to the suitability of this software for any purpose nor are held responsible for any defects of this software. THERE IS ABSOLUTELY NO WARRANTY FOR THIS SOFTWARE. As a matter of courtesy, the authors request to be informed about uses this software has found, about bugs in this software, and about any improvements that may be of general interest. It DOES seem to be DFSG-compatible. This code is already present in several other packages with the same licence. See gnuradio for instance. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#593162: marked as done (audacity: Audacity fails to load libavformat)
On Mon, Aug 16, 2010 at 20:45:45 (CEST), Aaron Barany wrote: Well, for exactly reasons like this, I find installing libraries from 3rd party repositories problematic at least. I agree it's not ideal, but unfortunately there's some functionality that isn't present in the main repositories. (for example, a build of gtkpod that supports AAC) If this requires faac, then right, we don't support non-free stuff and actually do care for licensing issues. And I've asked you to check this. Until this happens, I'd agree to leave this bug closed. It would be great if you could help with filling the gaps. Since that's the case, I can try both the testing and experimental versions, but most likely it will be this weekend or the next when I have the time. Thanks! -- 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: uploaded first pkg: pd-motex
On Mon, 2010-08-16 at 14:30 -0400, Felipe Sateler wrote: On 16/08/10 14:24, Hans-Christoph Steiner wrote: On Mon, 2010-08-16 at 09:38 +0200, IOhannes m zmoelnig wrote: On 2010-08-16 03:31, Hans-Christoph Steiner wrote: I'm not a pd expert, but if I install some extensions, I expect to be able to use them right away, without having to invoke pd with special args. I'm getting the impression that we are not living up to that expectation. You can use them right away the way they are being installed right now. Just like in python when you install a library, you still need to tell it to import it before using it. In Pd its similar, but messier. There is the [import] and [declare] objects for doing this in the Pd patches themselves, and there is the -lib command line option. and of course you can tell the interpreter to load certain libraries on startup by the means of a preference system (this is most likely the most commonly used case). but it seems like the README.Debian is indeed a bit confusing; maybe someone with better control of the english language could rephrase it (ideally somebody with good Pd-knowledge like hans). the reason why this info is in README.Debian and not in (e.g.) README is, that upstream's README does not include this information (mea culpa). the reason why it ought to be mentioned somewhere, is that (upstream) zexy is special in the way, that is a library consisting of both binary and interpreter files, and Pd handles these 2 kinds differently. that's why i make all the fuzz about -path and -lib I don't see why this is Debian-specific though. It really is an upstream issue, this should be documented as part of zexy, not Debian. I think I understand now, and I agree with Hans. That documentation should go upstream, not in a debian readme. It seems that this thread gets easily hijacked ;) Returning to the Subject, I think pd-motex is ready for upload, thanks all for the feedback! Also, I think it would be quite helpful if people change the subject when they hijack threads. That's my two bits... .hc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote: On 16/08/10 17:47, Hans-Christoph Steiner wrote: It seems that this thread gets easily hijacked ;) Returning to the Subject, I think pd-motex is ready for upload, thanks all for the feedback! How are you editing debian/changelog? The timestamp is old! Ah, oops, I forgot dch. I've been using emacs. The changelog is still something I am somewhat confused by. I get the idea of course, but the not the specifics. I was under the impression that pkg- multimedia uses git-dch to automatically generate the changelog, so I stopped editing it. Also, since this package hasn't been released yet, should I still be adding things to the changelog? Also, there is no need to ship the GPL text in the package. It seems like no patch or file tries to read the license, so no need to ship it (we already have the copyright file). The LICENSE.txt file is part of the standard library format. [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On 16/08/10 19:03, Hans-Christoph Steiner wrote: On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote: On 16/08/10 17:47, Hans-Christoph Steiner wrote: It seems that this thread gets easily hijacked ;) Returning to the Subject, I think pd-motex is ready for upload, thanks all for the feedback! How are you editing debian/changelog? The timestamp is old! Ah, oops, I forgot dch. I've been using emacs. The changelog is still something I am somewhat confused by. I get the idea of course, but the not the specifics. I was under the impression that pkg-multimedia uses git-dch to automatically generate the changelog, so I stopped editing it. Also, since this package hasn't been released yet, should I still be adding things to the changelog? Well, it depends on how many things you had to do. In this case, it appears that not much (other than fixing minor mistakes not found in a previous release). But you should still run dch. Please read the manpage, specially the section about the release heuristics. I use the changelog one, which seems to work well for our workflow. Also, there is no need to ship the GPL text in the package. It seems like no patch or file tries to read the license, so no need to ship it (we already have the copyright file). The LICENSE.txt file is part of the standard library format. Does anything break if we don't ship it? -- 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: uploaded first pkg: pd-motex
On Aug 16, 2010, at 8:04 PM, Felipe Sateler wrote: On 16/08/10 19:03, Hans-Christoph Steiner wrote: On Aug 16, 2010, at 6:22 PM, Felipe Sateler wrote: On 16/08/10 17:47, Hans-Christoph Steiner wrote: It seems that this thread gets easily hijacked ;) Returning to the Subject, I think pd-motex is ready for upload, thanks all for the feedback! How are you editing debian/changelog? The timestamp is old! Ah, oops, I forgot dch. I've been using emacs. The changelog is still something I am somewhat confused by. I get the idea of course, but the not the specifics. I was under the impression that pkg-multimedia uses git-dch to automatically generate the changelog, so I stopped editing it. Also, since this package hasn't been released yet, should I still be adding things to the changelog? Well, it depends on how many things you had to do. In this case, it appears that not much (other than fixing minor mistakes not found in a previous release). But you should still run dch. Please read the manpage, specially the section about the release heuristics. I use the changelog one, which seems to work well for our workflow. Ok makes sense. I updated the timestamp with dch and pushed the commit. The last question for me here is what should go into the changelog for this initial release? Also, there is no need to ship the GPL text in the package. It seems like no patch or file tries to read the license, so no need to ship it (we already have the copyright file). The LICENSE.txt file is part of the standard library format. Does anything break if we don't ship it? On all other platforms/distros it'll have that file there, and its visible using the library browser, so it would be only on Debian that you didn't see the license file. I think that sounds like minor but actual breakage. .hc ¡El pueblo unido jamás será vencido! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: uploaded first pkg: pd-motex
On Tue, Aug 17, 2010 at 01:03:57 (CEST), Hans-Christoph Steiner wrote: How are you editing debian/changelog? The timestamp is old! Ah, oops, I forgot dch. I've been using emacs. You might want to install the 'dpkg-dev-el' package, which features debian-changelog-mode. Here, you can easily update the timestamp with C-c C-f. See the mode documentation for details. The changelog is still something I am somewhat confused by. I get the idea of course, but the not the specifics. I was under the impression that pkg- multimedia uses git-dch to automatically generate the changelog, so I stopped editing it. Also, since this package hasn't been released yet, should I still be adding things to the changelog? I'm using git-dch to get a template, but most of the time, I end up fine tuning it with debian-changelog-mode. -- 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: uploaded first pkg: pd-motex
On Tue, Aug 17, 2010 at 00:22:25 (CEST), Felipe Sateler wrote: On 16/08/10 17:47, Hans-Christoph Steiner wrote: It seems that this thread gets easily hijacked ;) Returning to the Subject, I think pd-motex is ready for upload, thanks all for the feedback! How are you editing debian/changelog? The timestamp is old! Also, there is no need to ship the GPL text in the package. It seems like no patch or file tries to read the license, so no need to ship it (we already have the copyright file). Uh, why do you want to have the LICENSE.txt file removed from the upstream tarball? That seems rather blunt to me. However, It is indeed formatted in an unusual way and lacks the preamble, as well as the section How to Apply These Terms to Your New Programs. Hans, maybe you can include the full text of the GPL-2 as found in /usr/share/common-licenses/GPL-2 in a file named 'COPYING' in the next release tarball? That's what the FSF commonly does. -- 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
