Bug#593162: marked as done (audacity: Audacity fails to load libavformat)
Am 16.08.2010 22:54, schrieb Reinhard Tartler: If this requires faac, then right, we don't support non-free stuff and actually do care for licensing issues. No, but it requires libmp4v2 which is licensed under the MPL whereas gtkpod itself is licensed under the GPL. So, yes, this is a licensing issue and we have to care for it... - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
libmp4v2 is needed for AAC support
gtkpot 1.0.0, which has been released last week, is able to dlopen() libmp4v2: http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/gtkpod;a=commitdiff;h=a165455ff50c43e6c0973ffa315b77a5d8a416d9 ___ 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
Am 16.08.2010 18:41, schrieb Adrian Knoth: 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 Thanks for the feedback! I wasn't yet finished with this patch, anyway, because there is still a potential buffer overrun when an even longer pathname is given on the command line and strcpy'ed into the string buffer. Regarding PATH_MAX, I believe I'll set it to the original value of 255 for archs that have undef PATH_MAX. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Hi again! Another package I finished is panucci. It is an audio and podcast player with resuming function. It interacts great with gpodder. This is a pre- version from git, but works very good! I hope to get an invitation to your group! 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: libmp4v2 is needed for AAC support
On Tue, Aug 17, 2010 at 08:49:08 (CEST), Fabian Greffrath wrote: gtkpot 1.0.0, which has been released last week, is able to dlopen() libmp4v2: http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/gtkpod;a=commitdiff;h=a165455ff50c43e6c0973ffa315b77a5d8a416d9 Yay! that's great news! -- 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: libmp4v2 is needed for AAC support
17.08.2010 15:32, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 08:49:08 (CEST), Fabian Greffrath wrote: gtkpot 1.0.0, which has been released last week, is able to dlopen() libmp4v2: http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/gtkpod;a=commitdiff;h=a165455ff50c43e6c0973ffa315b77a5d8a416d9 Yay! that's great news! Actually, that was the case in the previous version 0.99.16, which, like 1.0.0, never made it into Debian because its old team is inactive. I'm not sure about the best way to handle this situation. I sent an email to their mailing list, but the only reply I got was from the NMU uploader for libgpod who is not a team member. ___ 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 07:37:11 (CEST), Reinhard Tartler wrote: 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. Ah no, you meant to not ship it in the binary package, not to remove it from the orig.tar.gz. Yes, that's a valid concern. This patch to the Makefile should fix this: diff --git a/Makefile b/Makefile index acbd0da..11feccf 100644 --- a/Makefile +++ b/Makefile @@ -192,8 +192,6 @@ install-doc: test -z $(strip $(PDOBJECTS)) || \ $(INSTALL_FILE) $(PDOBJECTS:.pd=-help.pd) \ $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME) - $(INSTALL_FILE) README.txt $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/README.txt - $(INSTALL_FILE) LICENSE.txt $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/LICENSE.txt install-examples: test -z $(strip $(EXAMPLES)) || \ Hans, what do you think about removing these two lines upstream? Users are very unlikely to look these two files up in those places anyway. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] faad2 packaging branch, master, updated. debian/2.7-4-5-ga421d73
Alright, it's not a secret anymore that I am better at reading C-code than writing it. ;) Would you please have another look at the patch and tell me if you see something obviously bogus? Thanks, - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of gigedit_0.2.0-1~exp1_amd64.changes
gigedit_0.2.0-1~exp1_amd64.changes uploaded successfully to localhost along with the files: gigedit_0.2.0-1~exp1.dsc gigedit_0.2.0.orig.tar.gz gigedit_0.2.0-1~exp1.debian.tar.gz gigedit_0.2.0-1~exp1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
gigedit_0.2.0-1~exp1_amd64.changes ACCEPTED
Accepted: gigedit_0.2.0-1~exp1.debian.tar.gz to main/g/gigedit/gigedit_0.2.0-1~exp1.debian.tar.gz gigedit_0.2.0-1~exp1.dsc to main/g/gigedit/gigedit_0.2.0-1~exp1.dsc gigedit_0.2.0-1~exp1_amd64.deb to main/g/gigedit/gigedit_0.2.0-1~exp1_amd64.deb gigedit_0.2.0.orig.tar.gz to main/g/gigedit/gigedit_0.2.0.orig.tar.gz Override entries for your package: gigedit_0.2.0-1~exp1.dsc - source sound gigedit_0.2.0-1~exp1_amd64.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
pd-zexy
ok, i think the pd-zexy package is almost ready for release. i rephrased the README.Debian, hopefully it's clearer now debian/changelog has better wording for quiltification maintainer is now pkg-multimedia-maintainers@ (at least in debian/control.in; how do i update debian/control from that; shouldn't it be done automagically?) comments, uploads? 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
Re: [SCM] gigedit packaging branch, master, updated. upstream/0.2.0-26-ge081da2
Hi Adrian! On Tue, Aug 17, 2010 at 11:40 AM, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: Do you have any plans? If not, I could imagine to start to package LS, though it would end up in non-free. We've already started: http://git.debian.org/?p=pkg-multimedia/linuxsampler.git and yes, having it in non-free would be great but there is a big license issue, I think. The commercial exception breaks GPL license itself and makes the application undistributable for everyone but the original author. -- Alessio Treglia ales...@alessiotreglia.com Debian Ubuntu Developer | Homepage: http://www.alessiotreglia.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] gigedit packaging branch, master, updated. upstream/0.2.0-26-ge081da2
Forgot this: On Tue, Aug 17, 2010 at 11:40 AM, Adrian Knoth a...@drcomp.erfurt.thur.de wrote: We should also polish liblscp a bit, version 0.5.6 has been released. I'll take a look ASAP. -- Alessio Treglia ales...@alessiotreglia.com Debian Ubuntu Developer | Homepage: http://www.alessiotreglia.com 0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy
On Tue, Aug 17, 2010 at 12:55:37PM +0200, IOhannes m zmoelnig wrote: ok, i think the pd-zexy package is almost ready for release. i rephrased the README.Debian, hopefully it's clearer now debian/changelog has better wording for quiltification maintainer is now pkg-multimedia-maintainers@ (at least in debian/control.in; how do i update debian/control from that; shouldn't it be done automagically?) comments, uploads? When you clean the source in cdbs maintainer mode, control file is updated[1]. Like this: DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean Would you mind me adding the CDBS copyright-check routine? I can imagine how that may feel odd since you yourself are upstream for the code, but it does seem to me that you missed out some copyright and licensing pieces. Not licensing conflicts, so nothing for you to worry about as upstream, but for Debian we care not only about that but also of properly recognizing all upstreams - not only main ones. Upstream you might want to consider improving the licensing headers to (more clearly) declare copyright years. Currently you state copyright like this: * copyleft (c) IOhannes m zmölnig * * 1999:forum::für::umläute:2004 There are multiple problems with this (IANAL, so YMMV): * the term copyleft have no legal meaning * strings are expressed in latin1 (or latin13 or similar) * it is unclear if the second string is copyright years I recommend to instead use the following one-liner: * copyright 1999-2004, IOhannes m zmölnig I also recommend to encode using utf8, if that does not cause problems with the compiler or the resulting code. But this is less important. Regards, - Jonas [1] True, that is lousily documented. And no, I do not intend to offer that functionality separate from CDBS. -- * 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: Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations
Hello Jonas, Here is a little update about the libscenic-dev that we should create as well. (I have never packaged C++ libraries. Should be relatively simple, no?) 2010/8/15 Alexandre Quessy alexan...@quessy.net: 2010/8/15 Jonas Smedegaard d...@jones.dk: Manpage of milhouse says There is also a shared video library. If we expect this to be ever used, we should not ship the header files together with the binary (in scenic-utils) but instead provide libscenic (or is that the proper name? that's the folder - there seem to be no central library in it) and libscenic-dev packages. That's right. I thought about this. There is no central library/header called scenic, but rather a few libraries that are in a directory called scenic. I think libscenic is the name it should have. The files that are intended to be public are: ./usr/include/scenic/videoSize.h ./usr/include/scenic/sharedVideoBuffer.h ./usr/lib/scenic/libshared_video.* That libscenic-dev library should have the following dependencies : libboost-dev, libboost-thread-dev, libboost-date-time-dev, libboost-system-dev Best, -- Alexandre Quessy http://alexandre.quessy.net/ ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy
On 2010-08-17 14:56, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 12:55:37PM +0200, IOhannes m zmoelnig wrote: ok, i think the pd-zexy package is almost ready for release. i rephrased the README.Debian, hopefully it's clearer now debian/changelog has better wording for quiltification maintainer is now pkg-multimedia-maintainers@ (at least in debian/control.in; how do i update debian/control from that; shouldn't it be done automagically?) comments, uploads? When you clean the source in cdbs maintainer mode, control file is updated[1]. Like this: DEB_MAINTAINER_MODE=1 fakeroot debian/rules clean right, i also found out about DEB_AUTO_UPDATE_DEBIAN_CONTROL=1 Would you mind me adding the CDBS copyright-check routine? i don't object, but: I can imagine how that may feel odd since you yourself are upstream for the code, but it does seem to me that you missed out some copyright and licensing pieces. Not licensing conflicts, so nothing for you to worry about as upstream, but for Debian we care not only about that but also of properly recognizing all upstreams - not only main ones. Upstream you might want to consider improving the licensing headers to (more clearly) declare copyright years. Currently you state copyright like this: * copyleft (c) IOhannes m zmölnig * * 1999:forum::für::umläute:2004 There are multiple problems with this (IANAL, so YMMV): * the term copyleft have no legal meaning but i guess that (c) is clear enough. * strings are expressed in latin1 (or latin13 or similar) this is surely no legal requirement * it is unclear if the second string is copyright years I recommend to instead use the following one-liner: * copyright 1999-2004, IOhannes m zmölnig you translated it correctly :-) the thing is, that this piece of software is also to be seen in an art context (phew!). the entire copyright headers are in a way a logo. also the encoding confusion has a historic (for me) relevance. i would hate to change these. (for what it's worth, nowadays i most often use the more traditional copyright clauses) 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
Re: uploaded first pkg: pd-motex
On Aug 17, 2010, at 4:35 AM, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 07:37:11 (CEST), Reinhard Tartler wrote: 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. Ah no, you meant to not ship it in the binary package, not to remove it from the orig.tar.gz. Yes, that's a valid concern. This patch to the Makefile should fix this: diff --git a/Makefile b/Makefile index acbd0da..11feccf 100644 --- a/Makefile +++ b/Makefile @@ -192,8 +192,6 @@ install-doc: test -z $(strip $(PDOBJECTS)) || \ $(INSTALL_FILE) $(PDOBJECTS:.pd=-help.pd) \ $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME) - $(INSTALL_FILE) README.txt $(DESTDIR)$(objectsdir)/$(LIBRARY_NAME)/ README.txt - $(INSTALL_FILE) LICENSE.txt $(DESTDIR)$(objectsdir)/$ (LIBRARY_NAME)/LICENSE.txt install-examples: test -z $(strip $(EXAMPLES)) || \ Hans, what do you think about removing these two lines upstream? Users are very unlikely to look these two files up in those places anyway. README.txt and LICENSE.txt are part of the Pd library format. They are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. I'll read up on the emacs changelog mode, I already have dpkg-dev-el installed already I guess I didn't realize I needed to trigger the timestamp manually. .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/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-zexy
Am 17.08.2010 15:34, schrieb IOhannes m zmoelnig: but i guess that (c) is clear enough. According to lintian (C) is not considered as a valid way to express the copyright ownership. The word Copyright or the © symbol should be used instead or in addition to (C). http://lintian.debian.org/tags/copyright-with-old-dh-make-debian-copyright.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processing of liblscp_0.5.6-1_amd64.changes
liblscp_0.5.6-1_amd64.changes uploaded successfully to localhost along with the files: liblscp_0.5.6-1.dsc liblscp_0.5.6.orig.tar.gz liblscp_0.5.6-1.debian.tar.gz liblscp-dev_0.5.6-1_all.deb liblscp6_0.5.6-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
liblscp_0.5.6-1_amd64.changes is NEW
liblscp-dev_0.5.6-1_all.deb to main/libl/liblscp/liblscp-dev_0.5.6-1_all.deb (new) liblscp6_0.5.6-1_amd64.deb optional libs LinuxSampler Control Protocol wrapper library This package is for use with the LinuxSampler audio sampling engine / library and packages. Wraps the LinuxSampler network protocol and offers a convenient API in form of a C library. liblscp_0.5.6-1.debian.tar.gz to main/libl/liblscp/liblscp_0.5.6-1.debian.tar.gz liblscp_0.5.6-1.dsc to main/libl/liblscp/liblscp_0.5.6-1.dsc liblscp_0.5.6.orig.tar.gz to main/libl/liblscp/liblscp_0.5.6.orig.tar.gz Changes: liblscp (0.5.6-1) experimental; urgency=low . * Imported Upstream version 0.5.6. * Bump SONAME: liblscp2 - liblscp6. * Add git-buildpackage config file. * New maintainer: Debian Multimedia Maintainers Team (Closes: #474527). * Add myself to Uploaders list. * Switch to format 3.0 (quilt). * Drop dpatch support, delete all obsolete patches. * Update watch file. * Add .gitignore file. * Switch to DH 7 + autotools_dev add-on. * Remove README.Debian, no longer necessary. * Build-Depends on autoconf, refresh automake build-dep. * Set the architecture of the -DEV package to all, make all required changes to keep it binNMUable. * Remove and skip debian/Makefile.*, they were provided by upstream's packaging and we don't need them anymore. * Drop static objects, drop libtool's junk (*.la files). * Update debian/copyright, adopt DEP-5 style proposal. * Nothing to install under /usr/share/aclocal, update install file. * Build and install the documentation. * Improve packages short description. * Update Standards to 3.9.1. * Move upstream's URL to source stanza. Override entries for your package: liblscp-dev_0.5.6-1_all.deb - optional libdevel liblscp_0.5.6-1.dsc - source libs Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 474527 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction
Am Dienstag, den 17.08.2010, 12:23 +0200 schrieb Reinhard Tartler: On Tue, Aug 17, 2010 at 08:55:40 (CEST), Thomas Maass wrote: Hi again! Another package I finished is panucci. It is an audio and podcast player with resuming function. It interacts great with gpodder. This is a pre- version from git, but works very good! Some questions: - Can we have a look at your proposed packages? - Does someone in the team endorse panucci and clibgrab - What's your alioth account id? - Have you been active somewhere else in debian before, or is the multimedia team the first point of contact with debian developers? My ID is mase-guest. I haven't been acvite in Debian before. I only built some packages for personal use. I thought, why not giving it all back to debian. I packaged different things, not only multimedia. But I think, the most help I can provide is in that section. I am really new to the community stuff. I still have to learn, how to use all the things. Where can I upload? 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: libmp4v2 is needed for AAC support
On 17/08/10 04:34, Maia Kozheva wrote: 17.08.2010 15:32, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 08:49:08 (CEST), Fabian Greffrath wrote: gtkpot 1.0.0, which has been released last week, is able to dlopen() libmp4v2: http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/gtkpod;a=commitdiff;h=a165455ff50c43e6c0973ffa315b77a5d8a416d9 Yay! that's great news! Actually, that was the case in the previous version 0.99.16, which, like 1.0.0, never made it into Debian because its old team is inactive. I'm not sure about the best way to handle this situation. I sent an email to their mailing list, but the only reply I got was from the NMU uploader for libgpod who is not a team member. I think it would be interesting to bring gtkpod into the team. Any other team members use gtkpod? I've not used it in a while, so that is why I didn't answer to your previous email, to let other interested people speak first. -- 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 Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote: README.txt and LICENSE.txt are part of the Pd library format. They are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. I guess that both the license and the README.txt actually belongs to /usr/share/doc/$package, that's what debian policy tells us to do. IIRC, documentation browsers like dhelp and the default webserver's configurations publish /usr/share/doc so that users can browse package documentation. So moving these files and symlink them to where the package expect them seems to me the right thing to do. I'll read up on the emacs changelog mode, I already have dpkg-dev-el installed already I guess I didn't realize I needed to trigger the timestamp manually. Yeah, I've really got used to that 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: pd-zexy
On 2010-08-17 15:45, Fabian Greffrath wrote: Am 17.08.2010 15:34, schrieb IOhannes m zmoelnig: but i guess that (c) is clear enough. According to lintian (C) is not considered as a valid way to express the copyright ownership. The word Copyright or the © symbol should be used instead or in addition to (C). http://lintian.debian.org/tags/copyright-with-old-dh-make-debian-copyright.html ok. but still, we are talking about copyright notices in the upstream sources and not about debian/copyright! debian/copyright should of course be correctly formatted, and to my knowledge already is: snip This package was debianized by Guenter Geiger gei...@debian.org on Wed, 6 Nov 2002 12:38:33 +0100. Downloaded from pure-data.sf.net Copyright: Copyright 1999-2010 IOhannes m zmoelnig optimization (abs~, abssgn~, dirac~): Copyright 2005-2006 Tim Blechmann OSC-pattern matching: Copyright 1998-2004 Matt Wright This software is distributed under the GPL version 2 (see /usr/share/common-licenses/GPL-2). /snip 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
Re: uploaded first pkg: pd-motex
On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote: README.txt and LICENSE.txt are part of the Pd library format. They are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. I guess that both the license and the README.txt actually belongs to /usr/share/doc/$package, that's what debian policy tells us to do. IIRC, documentation browsers like dhelp and the default webserver's configurations publish /usr/share/doc so that users can browse package documentation. So moving these files and symlink them to where the package expect them seems to me the right thing to do. This is wrong, actually: Code must not depend on /usr/share/doc existing on the machine, so when a file is needed both by runtime and below /usr/share/doc then the actual file should be placed elsewhere and a symlink be placed below /usr/share/doc. Not sure if this is explicitly clarified in Debian Policy or only a result of close-reading FHS (File Hierarchy Standard) or some such. Perhaps look for sections regarding example scripts. - 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: Introduction
On Tue, Aug 17, 2010 at 17:05:30 (CEST), Thomas Maass wrote: Am Dienstag, den 17.08.2010, 12:23 +0200 schrieb Reinhard Tartler: On Tue, Aug 17, 2010 at 08:55:40 (CEST), Thomas Maass wrote: Hi again! Another package I finished is panucci. It is an audio and podcast player with resuming function. It interacts great with gpodder. This is a pre- version from git, but works very good! Some questions: - Can we have a look at your proposed packages? - Does someone in the team endorse panucci and clibgrab - What's your alioth account id? - Have you been active somewhere else in debian before, or is the multimedia team the first point of contact with debian developers? My ID is mase-guest. I haven't been acvite in Debian before. I only built some packages for personal use. I thought, why not giving it all back to debian. Excellent, you are on the right track! :-) I packaged different things, not only multimedia. But I think, the most help I can provide is in that section. I am really new to the community stuff. I still have to learn, how to use all the things. Sure, and working in a team is a very efficient way to learn! BTW, packaging new stuff is not the only way to contribute. You could also take a look at existing packages of our team and post patches to this list! If they are good and can be integrated, we will make sure that we retain your full attribution. Where can I upload? Either you have some private webspace somewhere, or you can upload to mentors.debian.net and tell us the download url here! Or technically, you could also use the service http://revu.tauware.de, although is rather targeted for ubuntu. Espc. for new packagers, I've made the experimence that getting the package in shape before uploading it to git.debian.org is more efficient than ironing out all problems via git. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] faad2 packaging branch, master, updated. debian/2.7-4-5-ga421d73
On 17/08/10 04:44, Fabian Greffrath wrote: Alright, it's not a secret anymore that I am better at reading C-code than writing it. ;) Would you please have another look at the patch and tell me if you see something obviously bogus? No, I don't see anything weird. I do not know the codebase, so I don't know if it is complete, though. -- 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] liblscp packaging branch, master, updated. upstream/0.5.6-24-gb1fc5f6
On Tue, Aug 17, 2010 at 15:54:42 (CEST), ales...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit a436731657591414a809722093c6085715da3a42 Author: Alessio Treglia ales...@debian.org Date: Tue Aug 17 15:50:44 2010 +0200 Build and install the documentation. diff --git a/debian/control b/debian/control index 12d733b..b402e50 100644 --- a/debian/control +++ b/debian/control @@ -5,8 +5,9 @@ Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alio Uploaders: Paul Brossier p...@debian.org, Free Ekanayaka fr...@debian.org, Alessio Treglia ales...@debian.org -Build-Depends: debhelper (= 7), +Build-Depends: debhelper (= 7.0.50~), autotools-dev (= 20100122.1~), + doxygen, automake, autoconf, libtool diff --git a/debian/rules b/debian/rules index dcf6189..8f26c23 100755 --- a/debian/rules +++ b/debian/rules @@ -2,3 +2,7 @@ %: dh $@ --with autotools_dev + +override_dh_auto_build: + dh_auto_build + $(MAKE) -C doc From the csound package we have learned that this approach leads to calling doxygen unnecesarily on all architectures on the buildd. On sparc, doxygen currently seems broken, thus the package FTBFS there. How about making a team policy that doxygen should not be executed on the buildds? That should be of course accompanied with instructions how to implement that advice. -- 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 2010-08-17 17:39, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote: README.txt and LICENSE.txt are part of the Pd library format. They this should read: are part of a Pd library format under discussion. are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. if other pd-libraries have other licenses, they would obviously either link to ../../../common-licenses/BSD (or whatever) or if there is no license in common-licenses leave it as it is. 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
Re: separate discussion and development lists
On Sun, Aug 15, 2010 at 20:15:40 (CEST), Andreas Tille wrote: On Sat, Aug 14, 2010 at 10:10:45AM +0200, Reinhard Tartler wrote: Perhaps? My biggest concern is that with 3 lists, it becomes more and more challenging to decide to which list to post. Replies to -vcs mails currently go to -maintainers because of the reply-to, so I guess that would remain. But what about discussion mails on -maintainers, that are supposed to go to debian-multime...@l.d.o? This overhead of meta-discussion about a topic being ontopic or offtopic is the price I see for having a third list. (it could be mitigated with a proper and clear charter, I imagine). For me the maintainers list is way to noisy and I guess a lot of users will see it the same way. Moreover I'm afraid that just because of the name of the list as well as the location users will not even consider subscribing this list (as I would never have done if I would not explicitely asked to raise the Blends topic here). IMHO we have no proper place to discuss the issues of multimedia users inside Debian and that's a pity because we might loose users (and potential developers) because of this. I've had a small private followup conversation with Andreas about this. He basically came up with the suggestion to turn debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. While I don't think that this will significantly lower the amount of traffic (well, we actually widen the set of topics), I still think that it will be benefitial for pkg-multimedia, because: - we get more contact with our actual users - we learn what's pressing and bugging them - we hopefully get more potential and real contributors, ideally even new developers WDYT? -- 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: separate discussion and development lists
On 17/08/10 11:58, Reinhard Tartler wrote: On Sun, Aug 15, 2010 at 20:15:40 (CEST), Andreas Tille wrote: On Sat, Aug 14, 2010 at 10:10:45AM +0200, Reinhard Tartler wrote: Perhaps? My biggest concern is that with 3 lists, it becomes more and more challenging to decide to which list to post. Replies to -vcs mails currently go to -maintainers because of the reply-to, so I guess that would remain. But what about discussion mails on -maintainers, that are supposed to go to debian-multime...@l.d.o? This overhead of meta-discussion about a topic being ontopic or offtopic is the price I see for having a third list. (it could be mitigated with a proper and clear charter, I imagine). For me the maintainers list is way to noisy and I guess a lot of users will see it the same way. Moreover I'm afraid that just because of the name of the list as well as the location users will not even consider subscribing this list (as I would never have done if I would not explicitely asked to raise the Blends topic here). IMHO we have no proper place to discuss the issues of multimedia users inside Debian and that's a pity because we might loose users (and potential developers) because of this. I've had a small private followup conversation with Andreas about this. He basically came up with the suggestion to turn debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. I thought this was the idea the whole time? While I don't think that this will significantly lower the amount of traffic (well, we actually widen the set of topics), I still think that it will be benefitial for pkg-multimedia, because: - we get more contact with our actual users - we learn what's pressing and bugging them - we hopefully get more potential and real contributors, ideally even new developers WDYT? Every time I think about it, I like it more. I think we should do that. And announce it to the world via d-d-a. -- 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: Introduction
Am Dienstag, den 17.08.2010, 17:40 +0200 schrieb Reinhard Tartler: On Tue, Aug 17, 2010 at 17:05:30 (CEST), Thomas Maass wrote: Am Dienstag, den 17.08.2010, 12:23 +0200 schrieb Reinhard Tartler: On Tue, Aug 17, 2010 at 08:55:40 (CEST), Thomas Maass wrote: Hi again! Another package I finished is panucci. It is an audio and podcast player with resuming function. It interacts great with gpodder. This is a pre- version from git, but works very good! Some questions: - Can we have a look at your proposed packages? - Does someone in the team endorse panucci and clibgrab - What's your alioth account id? - Have you been active somewhere else in debian before, or is the multimedia team the first point of contact with debian developers? My ID is mase-guest. I haven't been acvite in Debian before. I only built some packages for personal use. I thought, why not giving it all back to debian. Excellent, you are on the right track! :-) I packaged different things, not only multimedia. But I think, the most help I can provide is in that section. I am really new to the community stuff. I still have to learn, how to use all the things. Sure, and working in a team is a very efficient way to learn! BTW, packaging new stuff is not the only way to contribute. You could also take a look at existing packages of our team and post patches to this list! If they are good and can be integrated, we will make sure that we retain your full attribution. Where can I upload? Either you have some private webspace somewhere, or you can upload to mentors.debian.net and tell us the download url here! Or technically, you could also use the service http://revu.tauware.de, although is rather targeted for ubuntu. Espc. for new packagers, I've made the experimence that getting the package in shape before uploading it to git.debian.org is more efficient than ironing out all problems via git. Here are 2 of my packages: http://mentors.debian.net/debian/pool/main/c/clipgrab http://mentors.debian.net/debian/pool/main/p/panucci 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: separate discussion and development lists
Am Dienstag, den 17.08.2010, 12:08 -0400 schrieb Felipe Sateler: On 17/08/10 11:58, Reinhard Tartler wrote: On Sun, Aug 15, 2010 at 20:15:40 (CEST), Andreas Tille wrote: On Sat, Aug 14, 2010 at 10:10:45AM +0200, Reinhard Tartler wrote: Perhaps? My biggest concern is that with 3 lists, it becomes more and more challenging to decide to which list to post. Replies to -vcs mails currently go to -maintainers because of the reply-to, so I guess that would remain. But what about discussion mails on -maintainers, that are supposed to go to debian-multime...@l.d.o? This overhead of meta-discussion about a topic being ontopic or offtopic is the price I see for having a third list. (it could be mitigated with a proper and clear charter, I imagine). For me the maintainers list is way to noisy and I guess a lot of users will see it the same way. Moreover I'm afraid that just because of the name of the list as well as the location users will not even consider subscribing this list (as I would never have done if I would not explicitely asked to raise the Blends topic here). IMHO we have no proper place to discuss the issues of multimedia users inside Debian and that's a pity because we might loose users (and potential developers) because of this. I've had a small private followup conversation with Andreas about this. He basically came up with the suggestion to turn debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. I thought this was the idea the whole time? While I don't think that this will significantly lower the amount of traffic (well, we actually widen the set of topics), I still think that it will be benefitial for pkg-multimedia, because: - we get more contact with our actual users - we learn what's pressing and bugging them - we hopefully get more potential and real contributors, ideally even new developers WDYT? Every time I think about it, I like it more. I think we should do that. And announce it to the world via d-d-a. I am new to this list and I can share your thoughts. Some posts are to get lost in the huge amount of posts. 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: separate discussion and development lists
On Tue, Aug 17, 2010 at 05:58:43PM +0200, Reinhard Tartler wrote: I've had a small private followup conversation with Andreas about this. He basically came up with the suggestion to turn debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. Sounds good to me. I also digged out some mails from the archive with subject closing down debian-multimedia alioth project and l.d.o list, dating back to April 2009. I never noticed there was still traffic on debian-multime...@l.d.o. Anyway, make this the place for users and keep pkg-multimedia-maintainers for internal discussion. Also note that we should change the maintainer address in the following packages: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org If we want to make debian-multimedia a place for users anytime soon, we'd probably need to change all those packages upfront, IOW, before we release squeeze. I'm not entirely sure the release team is happy if we'll upload 17 packages just because of a maintainer's email address change, but given the long release cycle, I see no other way if we want to use debian-multime...@l.d.o, unless it's acceptable to see a bug reports now and then on this list. BTW: Many of these packages are pretty old, e.g. no new upload since 2007 for hexter. They are also not available on git.debian.org. It might be a good first step for beginners to get some experience with git, git-buildpackage, team guidelines (multiline fields) and housekeeping in general to help with these 17 packages. WDYT? ;) -- 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
Re: pd-zexy
On Tue, Aug 17, 2010 at 03:34:57PM +0200, IOhannes m zmoelnig wrote: On 2010-08-17 14:56, Jonas Smedegaard wrote: Would you mind me adding the CDBS copyright-check routine? i don't object, but: I can imagine how that may feel odd since you yourself are upstream for the code, but it does seem to me that you missed out some copyright and licensing pieces. Not licensing conflicts, so nothing for you to worry about as upstream, but for Debian we care not only about that but also of properly recognizing all upstreams - not only main ones. Please note that above is about redistribution for Debian and derived systems, i.e. debian/copyright and semi-automatically maintaining it. Below is about upstream packaging, i.e. what might cause uncertainty for users and redistributors on what exactly thy are permitted to do with all the pieces that you offer them. So I dare ignore your but above and (parallel to continuing below discussion) I will start working on copyright-check and rewriting debian/copyright using DEP5 machine-readable format. If you disagree with that, please shout, so I can stop wasting time on something that you will revert anyway afterwards :-) Upstream you might want to consider improving the licensing headers to (more clearly) declare copyright years. Currently you state copyright like this: * copyleft (c) IOhannes m zmölnig * * 1999:forum::für::umläute:2004 There are multiple problems with this (IANAL, so YMMV): * the term copyleft have no legal meaning but i guess that (c) is clear enough. * strings are expressed in latin1 (or latin13 or similar) this is surely no legal requirement * it is unclear if the second string is copyright years I recommend to instead use the following one-liner: * copyright 1999-2004, IOhannes m zmölnig you translated it correctly :-) the thing is, that this piece of software is also to be seen in an art context (phew!). the entire copyright headers are in a way a logo. also the encoding confusion has a historic (for me) relevance. I do not understand how that header is a logo, but that magic word art make me bow down in respect and not want to discuss any further. It was just a suggestion (or, really, a recommendation), not a requirement (for you as upstream). We (Debian) do need, however, to make sure that upstream copyright claims and licensing permissions are properly identified. If the file headers do not (in our understanding of legal requirements for *redistributors* - not for *upstreams*) contain clear statements of both copyright and licensing, then we will need a written statement from those authors stating clearly the info we need. This also, as I see it, implies that if e.g. a README file in the topmost directory of the upstream tarball claims that this project is Copyright authors A, B and C, but one file claims Copyright author D, then file takes presedence over README, and if then that file cannot be parsed reliably regarding *both* copyright and licensing, then that file is deemed unsatifiably licensed for redistribution. You are free to not want to improve clarity of upstream copyright and licensing, but you risk some distributors then choosing not to want to redistribute your fine code. i would hate to change these. Ah, that is a language I understand :-D - 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: separate discussion and development lists
On Tue, Aug 17, 2010 at 12:08:20PM -0400, Felipe Sateler wrote: debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. I thought this was the idea the whole time? Yes. Every time I think about it, I like it more. I think we should do that. And announce it to the world via d-d-a. In fact announcing this (together with the tasks pages for Debian Multimedia) is a really good idea and I was just intending to make the project more popular this way all the time. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: separate discussion and development lists
On Tue, Aug 17, 2010 at 06:30:11PM +0200, Adrian Knoth wrote: Anyway, make this the place for users and keep pkg-multimedia-maintainers for internal discussion. Also note that we should change the maintainer address in the following packages: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org If we want to make debian-multimedia a place for users anytime soon, we'd probably need to change all those packages upfront, IOW, before we release squeeze. This is actually the wrong move IMHO, because users should NOT be spammed by package maintenance mails. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] liblscp packaging branch, master, updated. upstream/0.5.6-24-gb1fc5f6
On Tue, Aug 17, 2010 at 05:45:47PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 15:54:42 (CEST), ales...@users.alioth.debian.org wrote: + +override_dh_auto_build: + dh_auto_build + $(MAKE) -C doc From the csound package we have learned that this approach leads to calling doxygen unnecesarily on all architectures on the buildd. On sparc, doxygen currently seems broken, thus the package FTBFS there. How about making a team policy that doxygen should not be executed on the buildds? That should be of course accompanied with instructions how to implement that advice. How do we ensure *very* prominently to make the surrounding world (buildd maintainers of possibly broken hardware in particular) aware of such team-wide workaround? If we do not, then we effectively hide a problem IMO. - 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: separate discussion and development lists
On Tue, Aug 17, 2010 at 06:44:17PM +0200, Andreas Tille wrote: Also note that we should change the maintainer address in the following packages: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org If we want to make debian-multimedia a place for users anytime soon, we'd probably need to change all those packages upfront, IOW, before we release squeeze. This is actually the wrong move IMHO, because users should NOT be spammed by package maintenance mails. Not sure if we're talking the same: currently, 17 (16 if you count the fixed gigedit package in experimental) contain debian-multime...@lists.debian.org as the maintainer field. If I correctly understand the proposal, then this very address should be used for discussions with users. Hence, to avoid users being spammed by bug reports from the BTS, we need to change the maintainer fields in all those packages to pkg-mmm. -- 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
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: several user groups. If there are applications which are useful for more groups just list the application in question for all of them. Interesting. Is there some easy way to query in what tasks a given package is used? I'm just using grep on the tasks files in SVN. IMHO for developers this is OK. Do you have any other purpose in mind? is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? I tried to enable selection of Blends tasks immediately after installation (see bug #186085) but failed. So for the moment you just install the metapackages as any other package with your favourite package management tool. Let's imagine the following depends in the 'multimedia-consumer' metapackage: Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc I guess that if we the user first selects to install an KDE system in tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Yes (but untested). Assuming that an 'LXDE' task does not install any media player and is selected first in the installer, does the 'multimedia-consumer' metapackage only install mplayer and nothing else? Yes (also untested). If I get that correctly, this sounds pretty useful to me! If apt works as I expect it to work than this is exactly the case. Interesting. Just curious, did you have a look at the 'ubuntustudio-meta' source package? http://packages.ubuntu.com/source/lucid/ubuntustudio-meta. I should do this later. It's implementation might be different (it uses germinate), but it seems to me that blends-dev and germinate/ubuntustudio-meta share very similar goals, right? I imagine that we could use that at least as source of inspiration what multimedia tasks would be useful for a DeMuDi Blend. BTW, do Blends provide their own, customized installation media? What about live CDs? We should probably make a FAQ about this. The answer is: There *should* be a script to simplify this but probably it does not exist yet. Somebody has prepared something for Debian Med at svn://svn.debian.org/svn/debian-med/trunk/community/infrastructure/livecd In principle metapackages make the lice CD preparation quite simple by using live-helper but I would be really happy if somebody would write a generalised script + configured hooks which just needs a blend-build-livecd blendname and similar with to build d-i images. It's just a matter of finding the nneded time to do this, but in principle it should not be that hard. For comparison, ubuntustudio-meta in lucid creates these metapackages: $ grep -E ^Package debian/control Package: ubuntustudio-desktop Package: ubuntustudio-audio Package: ubuntustudio-graphics Package: ubuntustudio-audio-plugins Package: ubuntustudio-video Package: ubuntustudio-font-meta So this matches your suggestion pretty closely. Perhaps somebody could browse the list and adapt our tasks. I see. Well, I think we'd first need to get an idea what kinds of configuration options would be interesting for a DeMuDi Blend, but it's great to know that we have a place for this. :-) About what content are you thinking of at this point? Multimedia related packages which are in Ubuntu or debian-multimedia.org but not (yet) in Debian. I guess there are some of them, but I'm not that deeply involved in this field. Thinking further in this direction we could think about adding Debian-Multimedia.org package information to UDD and add this to the tasks page. Well, with the experiences we've made so far from bug reports, I don't think that we can endorse using that archive with good conscience. Well, we are not really *using* this but we are providing information about packages which can be used in principle by our users (they do it anyway). Moreover it saves us some work to maintain the metainformation about potentially interesting packages for our users in the tasks files explicitely. (This probably needs some detailed demonstration and is hard to explain in a short mail.) Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Defining interesting multimedia tasks
So, what are interesting multimedia tasks? I'm thinking: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? -- 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: remaining packages on the other list
On Tue, Aug 17, 2010 at 01:22:27PM -0400, Felipe Sateler wrote: On 17/08/10 12:30, Adrian Knoth wrote: On Tue, Aug 17, 2010 at 05:58:43PM +0200, Reinhard Tartler wrote: I've had a small private followup conversation with Andreas about this. He basically came up with the suggestion to turn debian-multime...@lists.debian.org from a *development* oriented mailing list to a *user* focused list. This way users can share their thoughts, concerns and kudos. Sounds good to me. I also digged out some mails from the archive with subject closing down debian-multimedia alioth project and l.d.o list, dating back to April 2009. I never noticed there was still traffic on debian-multime...@l.d.o. Anyway, make this the place for users and keep pkg-multimedia-maintainers for internal discussion. Also note that we should change the maintainer address in the following packages: http://qa.debian.org/developer.php?login=debian-multime...@lists.debian.org If we want to make debian-multimedia a place for users anytime soon, we'd probably need to change all those packages upfront, IOW, before we release squeeze. I'm not entirely sure the release team is happy if we'll upload 17 packages just because of a maintainer's email address change, but given the long release cycle, I see no other way if we want to use debian-multime...@l.d.o, unless it's acceptable to see a bug reports now and then on this list. BTW: Many of these packages are pretty old, e.g. no new upload since 2007 for hexter. They are also not available on git.debian.org. It might be a good first step for beginners to get some experience with git, git-buildpackage, team guidelines (multiline fields) and housekeeping in general to help with these 17 packages. WDYT? ;) Housekeeping on old packages is indeed a gentle way to learn packaging. Most gentle on release managers, however, is to carefully change only what is sensible for the scope of Squeeze, which I suspect is not so easy for new packagers to do. Also, I agree with Felipe that we should look at the relevancy of these packages first, so as to not accidentally keep alive abandoned software through training sessions. For all of them, we should really get in touch with last persons actually working on the packages! I got quite upset when the VOIP team requested ftpmaster removal of a package I cared for, after a week of mailinglist discussion where I happened to be offline. gmerlin: Is this taken care of by gmerlin-avdecoder? No. From the long description of gmerlin_avdecoder: Gmerlin_avdecoder is a general purpose media decoding library. It was written as a support library for gmerlin, but it can also be used by other applications. You don't even need gmerlin installed, only gavl. I believe gavl is packaged as libgavl1 for Debian (hmm - if true then perhaps we should improve the long description to mention that package name?) I care for this, and will pour some love at it if noone else steps up in a day or two. milkytracker: Upstream page is 403-Forbidden. I think we can drop a dead-upstream project. Popcon ~= 250 Sometimes it makes sense to continue upstream-dead software. But only if really relevant (and probably not as a beginner task!). Perhaps simply needs update to the Homepage stanza? Is it perhaps the software now located at http://milkytracker.org/ ? I have no special interest in this myself, though. openmovieeditor: Has a new upstream release from 2009, but the project seems dead. Popcon 1000. Movie editors have different target groups and there are not too many of them. I care for this, and will pour some love at it if noone else steps up in a day or two. stops: Definitions and instrument for aeolus. No upstream release since 2007. Popcon 200. Well, aeolus *depends* on it! vkeybd: A virtual keyboard. No new upstream release. Popcon ~= 350 I find this kind of tool relevant, and know of no alternative for this particular package. Please do enlighten me if I have missed a good alternative where time is better spent. I care for this, and will pour some love at it if noone else steps up in a day or two. - 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#592462: vlc: no video output
Le Tue 10 Aug 10 à 13:41 +0400, Bruno Carnazzi a écrit : Whatever filetype I try to open with vlc, I have no video output whereas it works with totem-gstreamear or mplayer. The real problem here is: xcb_xv generic error: no available XVideo adaptor VLC should try other video output module automatically. Not sure why it doesn't here. So please try vlc -V x11 or vlc -V glx (or vlc -V sdl installing vlc-plugin-sdl first) Also the output of xvinfo might be interresting Lastly, it would be worth trying on the laptop screen without any external monitor. -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 06:29:11PM +0200, Reinhard Tartler wrote: (CC'ing you, as I know that you are currently travelling) On Mon, Aug 16, 2010 at 09:42:04 (CEST), Andreas Tille wrote: There is no need to install a lot of applications on one machine. The blends-dev tools are building a tasksel control file which really would install everything in the task. This was used by Debian Edu and the functionality is keept - but there is no need to really use tasksel (even if the name tasks is inspired by tasksel). In Debian Med and Debian Jr. the usage of metapackages is prefered and there you have on one hand the alternatives option for instance Depends: mplayer | xine-ui | ffmpeg is fullfilled if only one of them is installed as well as if you can also use Suggests: not so important package which IMHO are two important advantages over the tasksel approach. At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Let's imagine the following depends in the 'multimedia-consumer' metapackage: Depends: mplayer | gxine | totem | kaffeine | dragonplayer | vlc I guess that if we the user first selects to install an KDE system in tasksel in d-i, and in that task kaffeine (or dragonplayer, not sure what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Beware that if *both* KDE *and* multimedia-consumer is selected during same installation routine (e.g. at initial install) then there is no guarantee which media-player, or how many of them, gets installed. Assuming that an 'LXDE' task does not install any media player and is selected first in the installer, does the 'multimedia-consumer' metapackage only install mplayer and nothing else? Beware that if first installing KDE + multimedia-consumer, and then at a later installation batch installs LXDE, then there is no ensurance (from multimedia-consumer) that any multimedia tools optimal for LXDE gets installed. Even uninstalling and later reinstalling multimedia-consumer does not ensure this. It is (during installation, at least) simply a metapackage! - 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 Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote: README.txt and LICENSE.txt are part of the Pd library format. They are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. I guess that both the license and the README.txt actually belongs to /usr/share/doc/$package, that's what debian policy tells us to do. IIRC, documentation browsers like dhelp and the default webserver's configurations publish /usr/share/doc so that users can browse package documentation. So moving these files and symlink them to where the package expect them seems to me the right thing to do. This is wrong, actually: Code must not depend on /usr/share/doc existing on the machine, so when a file is needed both by runtime and below /usr/share/doc then the actual file should be placed elsewhere and a symlink be placed below /usr/share/doc. Not sure if this is explicitly clarified in Debian Policy or only a result of close-reading FHS (File Hierarchy Standard) or some such. Perhaps look for sections regarding example scripts. In this context, I think the above suggestion makes the most sense. So here's my plan: - make the LICENSE.txt file into a symlink, if GPL, BSD or other common license - make usr/share/doc/pd-motex/README.txt a symlink to the one in the library I'd need to remove LICENSE.txt then make the symllnk. What's the best way to remove the file? I could patch the Makefile to remove the line in 'make install' that installs LICENSE.txt the add a link in debian/ links. Is there some easy/proper way in debhelper to just remove an installed file? .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/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 01:42:19PM -0400, Felipe Sateler wrote: So, what are interesting multimedia tasks? I'm thinking: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) - 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: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) I cannot make qualified comments on these, but I somehow feel that only eduacted users care about their widget library and/or desktop environment. For everyone else, the distinction between GTK and QT and even light and tiny is hardly obvious. But let's talk about the main point I want to cover: * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) While I could perfectly live with the first two, the latter is probably not the best choice: users could tend to read Multimedia? Cool, give me all. and end up with tons of software that's completely inappropriate for them. They'll be facing a question about jackd realtime priorities and probably more pro stuff. OTOH, producers might not want each and every single GTK+QT+whatever movie player, desktop tool and the lot when installing a video editing machine or digital audio workstation. Long story short: don't make a catch-all choice across consumer and producer variants. Just my €0.02 -- 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
Re: separate discussion and development lists
On Tue, Aug 17, 2010 at 06:49:58PM +0200, Adrian Knoth wrote: Not sure if we're talking the same: currently, 17 (16 if you count the fixed gigedit package in experimental) contain debian-multime...@lists.debian.org as the maintainer field. If I correctly understand the proposal, then this very address should be used for discussions with users. Hence, to avoid users being spammed by bug reports from the BTS, we need to change the maintainer fields in all those packages to pkg-mmm. Ahh, yes. I perfectly agree here: debian-multime...@lists.debian.org should NOT be used as maintainer field but rather pkg-mmm should. However, I'm not perfectly sure whether we should really push for a move into testing if this is the only problem of the package. Sorry for the confusion I might have caused Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Maintaining tasks files
On Tue, Aug 17, 2010 at 08:33:45PM +0200, Jonas Smedegaard wrote: At what time are these metapackages used/installed? After tasksel in the installer? Instead of tasksel? By tasksel. Correct me if I am wrong, Andreas, but I believe it works exactly like a standard old-fashioned metapackage, and that the difference is in how it is maintained (i.e. developed) and what *additional* uses it has maintaining package relations like this. Not completely right. Blends-dev creates a blend-tasks package which contains a tasksel control file which works with tasksel. I personally did not used this tasksel option because the only use *I* see would be in replacing the default tasks in d-i (or adding them to default tasks). Because this was not accepted by tasksel maintainer I *personally* go with the single metapackages because they allow more fine grained selection (as it was explicitely requested here with alternatives). what the current default media player is) is installed, the 'multimedia-consumer' metapackage will not install any other media player, correct? Beware that if *both* KDE *and* multimedia-consumer is selected during same installation routine (e.g. at initial install) then there is no guarantee which media-player, or how many of them, gets installed. That's correct - but we do not have a reasonable way to control this (except with the debconf method I suggested previosely in the thread). Beware that if first installing KDE + multimedia-consumer, and then at a later installation batch installs LXDE, then there is no ensurance (from multimedia-consumer) that any multimedia tools optimal for LXDE gets installed. Even uninstalling and later reinstalling multimedia-consumer does not ensure this. It is (during installation, at least) simply a metapackage! That's correct. Kind regards Andreas. -- http://fam-tille.de ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: remaining packages on the other list
On Tue, Aug 17, 2010 at 08:21:09PM +0200, Jonas Smedegaard wrote: Also, I agree with Felipe that we should look at the relevancy of these packages first, so as to not accidentally keep alive abandoned software through training sessions. ACK. For all of them, we should really get in touch with last persons actually working on the packages! ACK. milkytracker: Upstream page is 403-Forbidden. I think we can drop a dead-upstream project. Popcon ~= 250 Perhaps simply needs update to the Homepage stanza? Is it perhaps the software now located at http://milkytracker.org/ ? It is. And the latest release dates back to 01/01/10, fixing at least one important bug in the JACK output module. The package needs a sponsor: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567319 Given that this is our package (at least it has the debian-multimedia team address in the maintainer field), we should get in touch with the author. I'll forward this mail to him. vkeybd: A virtual keyboard. No new upstream release. Popcon ~= 350 I find this kind of tool relevant, and know of no alternative for this particular package. vmpk seems to be the better replacement. 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
Re: ITP: libcrystalhd2 -- Library for Broadcom Crystal HD video decoder cards
On Tue, Aug 17, 2010 at 03:40:37PM -0400, Andres Mejia wrote: On Monday 16 August 2010 06:32:59 Reinhard Tartler wrote: 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. Well, I don't have the necessary hardware to test myself either. Shall I go ahead and place this under collab-maint and ask debien-mentors for a sponser? Huh?!? If you succeed at that, you've just proven exactly why I dislike the sponsor system: People not really responsible about some packages let others also not really responsible put them into debian. The sponsor system wasn't designed to loosen responsibility but in effect it (sometimes) does that. No - please do not try to get a package into Debian which you do not care about yourself, make sure yourself works properly, and intend yourself to maintain in the future to keep working properly. Sorry if I sound rough. I really really appreciate efforts - also contributions other than properly packaged and maintained packages. I just really want it perfectly clear what package maintainance is. 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 Tue, Aug 17, 2010 at 02:40:09PM -0400, Hans-Christoph Steiner wrote: On Aug 17, 2010, at 11:39 AM, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 05:16:09PM +0200, Reinhard Tartler wrote: On Tue, Aug 17, 2010 at 15:35:10 (CEST), Hans-Christoph Steiner wrote: README.txt and LICENSE.txt are part of the Pd library format. They are part of the library, and the Help Browser (aka the library browser) looks for them to display them. The library format is basically a directory with files in it, and a subdir called 'examples'. That install target actually serves to enforce that all the standard files are there. In this library, I could replace the file with a symlink to ../../../ common-licenses/GPL-2, but other libraries might have different licenses so this wouldn't always be the case. I guess that both the license and the README.txt actually belongs to /usr/share/doc/$package, that's what debian policy tells us to do. IIRC, documentation browsers like dhelp and the default webserver's configurations publish /usr/share/doc so that users can browse package documentation. So moving these files and symlink them to where the package expect them seems to me the right thing to do. This is wrong, actually: Code must not depend on /usr/share/doc existing on the machine, so when a file is needed both by runtime and below /usr/share/doc then the actual file should be placed elsewhere and a symlink be placed below /usr/share/doc. Not sure if this is explicitly clarified in Debian Policy or only a result of close-reading FHS (File Hierarchy Standard) or some such. Perhaps look for sections regarding example scripts. In this context, I think the above suggestion makes the most sense. So here's my plan: - make the LICENSE.txt file into a symlink, if GPL, BSD or other common license - make usr/share/doc/pd-motex/README.txt a symlink to the one in the library I'd need to remove LICENSE.txt then make the symllnk. What's the best way to remove the file? I could patch the Makefile to remove the line in 'make install' that installs LICENSE.txt the add a link in debian/links. Is there some easy/proper way in debhelper to just remove an installed file? Your questions makes me suspect that you did not notice my earier response in this thread (even earlier than above quoted one). Date: Tue, 17 Aug 2010 11:54:32 +0200 Message-ID: 20100817095432.gg7...@jones.dk There I describe how I do similarly with Sugar packages. To answer more directly to your questions: No, I believe there is no debhelper routine specifically for this. Possibly you can make dh_link force overwrite existing object, but I find my proposed approach of replacing only if identical safer. 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: ITP: libcrystalhd2 -- Library for Broadcom Crystal HD video decoder cards
On Tuesday 17 August 2010 17:09:25 Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 03:40:37PM -0400, Andres Mejia wrote: On Monday 16 August 2010 06:32:59 Reinhard Tartler wrote: 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. Well, I don't have the necessary hardware to test myself either. Shall I go ahead and place this under collab-maint and ask debien-mentors for a sponser? Huh?!? If you succeed at that, you've just proven exactly why I dislike the sponsor system: People not really responsible about some packages let others also not really responsible put them into debian. The sponsor system wasn't designed to loosen responsibility but in effect it (sometimes) does that. No - please do not try to get a package into Debian which you do not care about yourself, make sure yourself works properly, and intend yourself to maintain in the future to keep working properly. Sorry if I sound rough. I really really appreciate efforts - also contributions other than properly packaged and maintained packages. I just really want it perfectly clear what package maintainance is. Kind regards, - Jonas I never said I didn't care about this package. I'm packaging this because it's a dependency for xbmc, and one of xbmc's upstream devs is also upstream dev for crystalhd. It's really only him that I know personally who can test this package properly, and I don't have reason not to believe crystalhd is thouroughly tested. I'm essentially packaging crystalhd for him. Not all devs know how to package software for Debian, and even fewer know how to do it right. And about my last email, it's just a suggestion anyway. I'm not sure what's best either, whether to team maintain it, even though it's possible nobody in the team has the necessary hardware to test this package. Like I said, I only have the word of one of my fellow devs for xbmc to go with (whether crystalhd is properly tested or not). -- 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
Bug#593129: Removed package(s) from unstable
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: hydrogen |0.9.3-7 | kfreebsd-amd64, kfreebsd-i386 --- Reason --- ROM; PortMIDI not ported on kfreebsd-* yet -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive (ftp-master.debian.org) and will not propagate to any mirrors (ftp.debian.org included) until the next cron.daily run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 593...@bugs.debian.org. The full log for this bug can be viewed at http://bugs.debian.org/593129 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Torsten Werner (the ftpmaster behind the curtain) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 09:09:12PM +0200, Adrian Knoth wrote: On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote: * audio production: sound synthesis, audio editing, sequencing. * multimedia playing: vlc ;) * video production: ... I don't do this. * home multimedia center: xmbc/mediatomb style software. Or should we have a finer grained split? I imagine something like this: * multimedia-gtk (enhancing e.g. gnome) * multimedia-qt (enhances e.g. kde) * multimedia-light (enhances e.g. lxde and xfce) * multimedia-tiny (enhances e.g. libphone-ui-shr) I cannot make qualified comments on these, but I somehow feel that only eduacted users care about their widget library and/or desktop environment. For everyone else, the distinction between GTK and QT and even light and tiny is hardly obvious. But let's talk about the main point I want to cover: * multimedia-pro-audio * multimedia-pro-video * multimedia (recommending all of above) While I could perfectly live with the first two, the latter is probably not the best choice: users could tend to read Multimedia? Cool, give me all. and end up with tons of software that's completely inappropriate for them. They'll be facing a question about jackd realtime priorities and probably more pro stuff. OTOH, producers might not want each and every single GTK+QT+whatever movie player, desktop tool and the lot when installing a video editing machine or digital audio workstation. Long story short: don't make a catch-all choice across consumer and producer variants. Good point. Let me try again: * multimedia (depends on multimedia-gtk | multimedia-playback) * multimedia-gnome (provides multimedia-playback; depends on Qt/Phonon-based and KDE apps) * multimedia-gtk (provides multimedia-playback; depends on GTK/GStreamer and GNOME apps) * multimedia-light (provides multimedia-playback; depends on apps _not_ linked against desktop-homogenizing libraries) * multimedia-tiny (provides multimedia-playback; depends on apps targeted embedded devices) * multimedia-pro-studio (depends on classic GUI style production tools like Ardour, JACK and Hydrogen) * multimedia-pro-live (depends on production tools designed for live mixing of audio and video) * multimedia-pro-devel (depends on scripting and programming tools like PureData and CSound) With depends on I really mean depends, recommends or suggests, weighted how we consider a nice user experience. We can't (with current structures) serve all flavors of use equally well. but for each of the flavors we do serve well, we can suggest packages related to that flavor but deemed by us as overlapping and superfluous (which obviously means some other would favor those - else it had no point in being shipped with Debian at all!) Also, I do dream about being able in the future to serve more fine-grained needs, and we need to start somewhere to realize how clumsy our current mechanisms really are for serving things like this: Imagine in the future being able through debconf or similar to explress I want to edit video, mostly live on relatively low-end hardware using strictly GUI interfaces. - 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: separate discussion and development lists
On Tue, Aug 17, 2010 at 10:36:09PM +0200, Andreas Tille wrote: On Tue, Aug 17, 2010 at 06:49:58PM +0200, Adrian Knoth wrote: Not sure if we're talking the same: currently, 17 (16 if you count the fixed gigedit package in experimental) contain debian-multime...@lists.debian.org as the maintainer field. If I correctly understand the proposal, then this very address should be used for discussions with users. Hence, to avoid users being spammed by bug reports from the BTS, we need to change the maintainer fields in all those packages to pkg-mmm. Ahh, yes. I perfectly agree here: debian-multime...@lists.debian.org should NOT be used as maintainer field but rather pkg-mmm should. However, I'm not perfectly sure whether we should really push for a move into testing if this is the only problem of the package. I was skeptical to this earlier on. I still do not think that I will be subscribing to a users' list myself, but if others will then I won't be in their way :-) I agree that it makes good sense to reuse the existing list at l.d.o. And I suggest to simply start using it: Those packages currently pointing there in maintainer field are not very active packages, so there is also little risk of them stirring much noise. If some of those packages really should be dropped from Debian completely then let's try do that before the Squeeze release to avoid unnecessarily needing to maintain dead weight for a couple of years. But for those packages we keep, let us not burden release-managers with adjusting maintainer field, but instead aim at updating that at the first point release (or, if we are quick, or the release process is slow, then drop an email to release managers emphasizing that it is low priority and we can wait till later if need be). Sorry for the confusion I might have caused No problem (I dare say on behalf of the team): As always you are quite gentle :-) 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: Defining interesting multimedia tasks
On 17/08/10 17:54, Jonas Smedegaard wrote:
On Tue, Aug 17, 2010 at 09:09:12PM +0200, Adrian Knoth wrote:
On Tue, Aug 17, 2010 at 08:44:01PM +0200, Jonas Smedegaard wrote:
* audio production: sound synthesis, audio editing, sequencing.
* multimedia playing: vlc ;)
* video production: ... I don't do this.
* home multimedia center: xmbc/mediatomb style software.
Or should we have a finer grained split?
I imagine something like this:
* multimedia-gtk (enhancing e.g. gnome)
* multimedia-qt (enhances e.g. kde)
* multimedia-light (enhances e.g. lxde and xfce)
* multimedia-tiny (enhances e.g. libphone-ui-shr)
I cannot make qualified comments on these, but I somehow feel that
only eduacted users care about their widget library and/or desktop
environment. For everyone else, the distinction between GTK and QT and
even light and tiny is hardly obvious.
But let's talk about the main point I want to cover:
* multimedia-pro-audio
* multimedia-pro-video
* multimedia (recommending all of above)
While I could perfectly live with the first two, the latter is
probably not the best choice: users could tend to read Multimedia?
Cool, give me all. and end up with tons of software that's completely
inappropriate for them. They'll be facing a question about jackd
realtime priorities and probably more pro stuff.
OTOH, producers might not want each and every single GTK+QT+whatever
movie player, desktop tool and the lot when installing a video editing
machine or digital audio workstation.
Long story short: don't make a catch-all choice across consumer and
producer variants.
Good point.
Let me try again:
* multimedia (depends on multimedia-gtk | multimedia-playback)
* multimedia-gnome (provides multimedia-playback; depends on
Qt/Phonon-based and KDE apps)
* multimedia-gtk (provides multimedia-playback; depends on
GTK/GStreamer and GNOME apps)
* multimedia-light (provides multimedia-playback; depends on
apps _not_ linked against desktop-homogenizing libraries)
* multimedia-tiny (provides multimedia-playback; depends on
apps targeted embedded devices)
I believe that each DE will have installed it's own media player. Is
there really a need for multimedia-{gnome,kde,gtk} tasks?
* multimedia-pro-studio (depends on classic GUI style
production tools like Ardour, JACK and Hydrogen)
* multimedia-pro-live (depends on production tools designed
for live mixing of audio and video)
* multimedia-pro-devel (depends on scripting and programming
tools like PureData and CSound)
While I know that the tasks are not meant to be disjoint sets, I think
that this split has too much overlap. In particular, both csound and
puredata can be (and are frequently) used for live coding, and I suspect
all sound programming languages can be too. So multimedia-pro-devel
would be contained within multimedia-pro-live.
Or maybe it is something else you are splitting on and I'm just confused
by the names?
--
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] VLC media player packaging branch, sid, updated. debian/1.1.2-1-5-ga0a985e
Hello, +vlc (1.1.2-2~1.gbp86f815) UNRELEASED; urgency=medium Almost ready except for + * Add Xb-Npp header to mozilla-plugin-vlc package. (Not doing anything +at the moment, see #484010) Which does nothing except generating some build and lintian harmless warning and reducing the Ubuntu diff. So it's really a political decision. Not sure it's the good time to add it when this upload will need to be agreed by the release team. Or, we could reorganise the changelog to put the security fix more prominently, so that people don't read further. Opinions ? -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] VLC media player packaging branch, sid, updated. debian/1.1.2-1-5-ga0a985e
Am Mittwoch, den 18.08.2010, 00:29 +0200 schrieb Christophe Mutricy: Hello, +vlc (1.1.2-2~1.gbp86f815) UNRELEASED; urgency=medium Almost ready except for + * Add Xb-Npp header to mozilla-plugin-vlc package. (Not doing anything +at the moment, see #484010) Which does nothing except generating some build and lintian harmless warning and reducing the Ubuntu diff. So it's really a political decision. Not sure it's the good time to add it when this upload will need to be agreed by the release team. As discussed on IRC: Let's move it this change to experimental. Or, we could reorganise the changelog to put the security fix more prominently, so that people don't read further. Opinions ? -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#592456: mozilla-plugin-vlc: Please add npp-* control file entries for iceweasel to find the plugin when needed
block 592456 by 484010 severity 592456 normal thanks Le Tue 10 Aug 10 à 11:18 +0200, Petter Reinholdtsen a écrit : Package: mozilla-plugin-vlc More information about the feature can be found in URL: https://wiki.ubuntu.com/MozillaTeam/Plugins The patch to do this can be found in the Ubuntu package. This is the relevant part: This is useless until Iceweasel can use such information. See #592464 for more discussion -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#592456: mozilla-plugin-vlc: Please add npp-* control file entries for iceweasel to find the plugin when needed
Processing commands for cont...@bugs.debian.org: block 592456 by 484010 Bug #592456 [mozilla-plugin-vlc] mozilla-plugin-vlc: Please add npp-* control file entries for iceweasel to find the plugin when needed Was not blocked by any bugs. Added blocking bug(s) of 592456: 484010 severity 592456 normal Bug #592456 [mozilla-plugin-vlc] mozilla-plugin-vlc: Please add npp-* control file entries for iceweasel to find the plugin when needed Severity set to 'normal' from 'important' thanks Stopping processing here. Please contact me if you need assistance. -- 592456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592456 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/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] LibASS packaging branch, master, updated. debian/0.9.8-1-20-g8cd12b2
Le Tue 17 Aug 10 à 22:51 +, xtophe-gu...@users.alioth.debian.org a écrit : Merge commit 'upstream/0.9.11' Conflicts: [...] Argh. I messed up again. Forgot to check that my upstream branch was up-to-date. I really need to add a hook to git-import-orig. I sort the mess tomorow but please don't pull from alioth in the mean time -- Xtophe ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Defining interesting multimedia tasks
On Tue, Aug 17, 2010 at 06:17:18PM -0400, Felipe Sateler wrote:
On 17/08/10 17:54, Jonas Smedegaard wrote:
* multimedia (depends on multimedia-gtk | multimedia-playback)
* multimedia-gnome (provides multimedia-playback; depends on
Qt/Phonon-based and KDE apps)
* multimedia-gtk (provides multimedia-playback; depends on
GTK/GStreamer and GNOME apps)
* multimedia-light (provides multimedia-playback; depends on
apps _not_ linked against desktop-homogenizing libraries)
* multimedia-tiny (provides multimedia-playback; depends on
apps targeted embedded devices)
I believe that each DE will have installed it's own media player. Is
there really a need for multimedia-{gnome,kde,gtk} tasks?
ok.
I was imagining that there was more to it than a media player, but
thinking more about it I cannot come up with a sensible split: Those
(like me) favoring MPD will cherry-pick based on that. No point in
trying to group media players - they are either catch-all integrated
with a desktop or aiming at something specific which you then have a
specific interest in.
* multimedia-pro-studio (depends on classic GUI style
production tools like Ardour, JACK and Hydrogen)
* multimedia-pro-live (depends on production tools designed
for live mixing of audio and video)
* multimedia-pro-devel (depends on scripting and programming
tools like PureData and CSound)
While I know that the tasks are not meant to be disjoint sets, I think
that this split has too much overlap. In particular, both csound and
puredata can be (and are frequently) used for live coding, and I
suspect all sound programming languages can be too. So
multimedia-pro-devel would be contained within multimedia-pro-live.
Or maybe it is something else you are splitting on and I'm just
confused by the names?
Do any of us developers actually use e.g. VJ'ing tools?
I have the impression that those performing favor different tools than
those e.g. composing electronica. And that both camps typically use not
a single tool by a range of them together. I might be totally wrong.
I am well aware that each user has a personal favorite setup. We cannot
serve all. Skolelinux also do not serve all needs schools _can_ have,
but offer an easy way to install a sensible system (which happen to be
KDE-based, which I personally dislike).
- 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: [SCM] jack-capture packaging branch, master, updated. upstream/0.9.54-20-gc1d5c43
On Tue, Aug 17, 2010 at 06:53:10PM -0400, Felipe Sateler wrote: On 17/08/10 16:52, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 07:10:34PM +, adiknoth-gu...@users.alioth.debian.org wrote: We want to build all packages against jackd1, so we need to depend on libjack-dev. Hopefully, the buildds will always pick up the first alternative. Yes, I believe they will. Has the list configuration changed? This is the second non-generated mail I see arrived at -commits. Probably just my habit of pressing capital L in mutt to reply to list, not r to reply to sender (which ends up wrong when reply-to not set). - 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: Defining interesting multimedia tasks
Am Dienstag, den 17.08.2010, 13:42 -0400 schrieb Felipe Sateler: * home multimedia center: xmbc/mediatomb style software. I'd suggest to distinguish between client and server tasks for software that is typically used in homes/families. There's typically one or more client machines that have to do the media playing and, if there's any family server around, that machine has to do the media serving tasks. 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: Adopting jack-tools
On Sat, Aug 14, 2010 at 03:53:19PM +0200, Arnout Engelen wrote: I noticed jack-tools is orphaned, and could really use an update. For example, jack.play has been transport-aware for more than 3 years, and that didn't make it into Debian yet. Perhaps this package could be adopted by someone in the debian-multimedia team? I figured I should get my hands dirty myself :). I repackaged jack-tools and uploaded it to the 'collab-maint' darcs repo and to mentors.debian.net: Darcs: - http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=collab-maint/jack-tools;a=summary Mentors: - URL: http://mentors.debian.net/debian/pool/main/j/jack-tools - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jack-tools/jack-tools_20100210-1.dsc It'd be great if someone could take a look at this and provide some feedback! Kind regards, Arnout ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
