date:20100902

On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:
 Looks pretty good to me, but I'm just learning myself :)

Thanks for having a look.
One thing I like to mention: The upstream sources come with a Makefile
based on a apparently old Makefile template for libdirs. It was pretty
broken and created superfluous directories in debian/. I copied over the
current template, adapted it and applied it as a quilt patch. Is that
the proper way to do it?

   I am  
 wondering about the strip stuff:

 override_dh_strip:
   strip --remove-section=.comment --remove-section=.note --strip- 
 unneeded \
   debian/pd-wiimote/usr/lib/pd/extra/wiimote/wiimote.pd_linux
 
 My guess is that this is needed in order to properly strip  
 the .pd_linux so binaries?
 

Yeah, dh_strip apparently does not consider .pd_linux files as shared
objects and also there is no way to force it by passing it file names as
arguments. 

I used the strip command from a mail by Felipe Sateler [1]

[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012336.html

Roman


___
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-keyboard packaging branch, master, updated. debian/2.5-1-16-g6a0d7c2

2010-09-02 Thread Alessio Treglia

On Wed, Sep 1, 2010 at 4:34 PM, Jonas Smedegaard d...@jones.dk wrote:
 What in the above does not make sense?


Mmmh.. actually nothing :)

Never mind, I'll re-introduce the copyright_hints file 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: first package: pd-wiimote

On Thu, 2010-09-02 at 09:38 +0200, Reinhard Tartler wrote:
 On Thu, Sep 02, 2010 at 01:16:03 (CEST), Roman Haefeli wrote:
 
  Hi all
 
  I checked in my first package. I tried to follow - where possible - very
  closely to pd-motex, which has been already uploaded.
  I would be glad if someone could have a look at it.
 
  FYI: It is using what I believe is called short-form dh.
 
 indeed, it is.
 
 I've taken a quick look at the package,
  it's a really small package and
 rather easy to review.
 
 Packagingwise, I think it is fine, but I'm umcomfortable with the two
 patches. First, please use the patch metadata as described in
 http://dep.debian.net/deps/dep3/.
 
 But as for the actual patches, I'm rather uncomfortable with
 them. The add-license patch adds the complete text of the GPL. I'm not
 sure how the ftpteam thinks about it, but to me it feels very
 strange. Is upstream aware of the problem, can't they just reissue the
 tarball with the complete license text? Moreover, quoting the part How
 to Apply These Term to Your New Programs is usually also helpful.
 
 I'd be more comfortable if the GPL text was just included in debian/,
 read, as non-patch, but still, I really think this file should be part
 of the orig.tar.gz.

The reason why I added the LICENSE file in the first place is because
the Makefile is hardcoded to install it. Probably I shouldn't have done
it as a patch. But then again in the thread about pd-motex people agreed
that it would be better to create a symlink to the respective license
in /usr/share/common-licenses/.
So actually, I could remove install LICENSE line in the Makefile which
makes the add-license.patch obsolete  and let debian/rules do the
symlink and the result will be the same. What do you think?

  So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.

Instead of using a quilt patch should I simply replace the Makefile with
the new one and check that into the master branch?

Roman



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: first package: pd-wiimote


On Thu, Sep 02, 2010 at 09:36:10AM +0200, Roman Haefeli wrote:

On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:

Looks pretty good to me, but I'm just learning myself :)


Thanks for having a look.
One thing I like to mention: The upstream sources come with a Makefile
based on a apparently old Makefile template for libdirs. It was pretty
broken and created superfluous directories in debian/. I copied over the
current template, adapted it and applied it as a quilt patch. Is that
the proper way to do it?


Sounds sane to me.

Please consider adding DEP3 headers to the patch if you haven't already.  
More info here: http://dep.debian.net/deps/dep3/


And be nice and pass on the patch to upstream.


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: first package: pd-wiimote


On Thu, Sep 02, 2010 at 09:38:56AM +0200, Reinhard Tartler wrote:
Packagingwise, I think it is fine, but I'm umcomfortable with the two 
patches. First, please use the patch metadata as described in 
http://dep.debian.net/deps/dep3/.


Oh, only saw this _after_ sending off same suggestion myself.  Sorry for 
the noice :-)




But as for the actual patches, I'm rather uncomfortable with
them. The add-license patch adds the complete text of the GPL. I'm not
sure how the ftpteam thinks about it, but to me it feels very
strange. Is upstream aware of the problem, can't they just reissue the
tarball with the complete license text? Moreover, quoting the part How
to Apply These Term to Your New Programs is usually also helpful.

I'd be more comfortable if the GPL text was just included in debian/,
read, as non-patch, but still, I really think this file should be part
of the orig.tar.gz. So another approach would be to repackage the
tarball to just include the COPYING file. While we are at it, we could
also use the new Makefile and get rid of the other patch.


I really don't get the logic of _adding_ a license at all.

I know that GPL boilerplate mentions that you are supposed to receive a 
COPYING file together with source, but I do not see it being _mandatory_ 
so if upstream fails to do it I suppose we are allowed to redistribute 
verbatim - i.e. also lacking same file.


If it is not for licensing reasons but due to being meeded by the code 
at runtime, then I suggest copying/symlinking the file below 
/usr/share/common-licenses instead.



 - 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: first package: pd-wiimote

[ no need to CC me explicitly, just hit your 'reply to list' instead
  'reply to all' button ]

On Thu, Sep 02, 2010 at 10:06:50 (CEST), Roman Haefeli wrote:

 The reason why I added the LICENSE file in the first place is because
 the Makefile is hardcoded to install it. Probably I shouldn't have done
 it as a patch. But then again in the thread about pd-motex people agreed
 that it would be better to create a symlink to the respective license
 in /usr/share/common-licenses/.

oh i see.

 So actually, I could remove install LICENSE line in the Makefile which
 makes the add-license.patch obsolete  and let debian/rules do the
 symlink and the result will be the same. What do you think?

That would probably be better.

In any case, we really need to make upstream aware of the issue and hope
that they release a new tarball with these issues fixed soon. It seems
that we even have IOhannes in our team :-)

IOhannes, could you do a quick wiimote-0.3.2.tar.gz tarball with the new
makefile and the COPYING file included?

  So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.

 Instead of using a quilt patch should I simply replace the Makefile with
 the new one and check that into the master branch?

no, that would be pretty confusing. I'd rather do these changes in the
'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
created or something.

-- 
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: first package: pd-wiimote

On Thu, 2010-09-02 at 10:48 +0200, Jonas Smedegaard wrote:
 On Thu, Sep 02, 2010 at 09:38:56AM +0200, Reinhard Tartler wrote:
 Packagingwise, I think it is fine, but I'm umcomfortable with the two 
 patches. First, please use the patch metadata as described in 
 http://dep.debian.net/deps/dep3/.
 
 Oh, only saw this _after_ sending off same suggestion myself.  Sorry for 
 the noice :-)
 
 
 But as for the actual patches, I'm rather uncomfortable with
 them. The add-license patch adds the complete text of the GPL. I'm not
 sure how the ftpteam thinks about it, but to me it feels very
 strange. Is upstream aware of the problem, can't they just reissue the
 tarball with the complete license text? Moreover, quoting the part How
 to Apply These Term to Your New Programs is usually also helpful.
 
 I'd be more comfortable if the GPL text was just included in debian/,
 read, as non-patch, but still, I really think this file should be part
 of the orig.tar.gz. So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.
 
 I really don't get the logic of _adding_ a license at all.
 
 I know that GPL boilerplate mentions that you are supposed to receive a 
 COPYING file together with source, but I do not see it being _mandatory_ 
 so if upstream fails to do it I suppose we are allowed to redistribute 
 verbatim - i.e. also lacking same file.
 
 If it is not for licensing reasons but due to being meeded by the code 
 at runtime, then I suggest copying/symlinking the file below 
 /usr/share/common-licenses instead.

It is actually not needed for running the program, but the libdir format
for Pd libraries proposed by Hans-Christoph Steiner defines a
LICENSE.txt and README.txt to be included in every Pd library. 

Currently, the quilt patch adds the license which is later replaced by a
symlink (see debian/links). I think I remove the patch and simply leave
the symlink.

Roman


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: Csound on Ubuntu

2010-09-02 Thread Alessio Treglia

On Sat, Aug 28, 2010 at 2:45 AM, Felipe Sateler fsate...@debian.org wrote:
 Alessio, please revert that patch. It is the only (meaningful)
 divergence from debian's csound.

Done and re-synced.
Thanks!

-- 
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

Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52

2010-09-02 Thread Tom Parker

Package: libavformat52
Version: 4:0.6-2
Severity: important

With mencoder 2:1.0~rc3++final.dfsg1-1 (current testing/unstable) I get

mencoder: relocation error: mencoder: symbol codec_wav_tags, version 
LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference

Installing 2:1.0~rc4~try1.dsfg1-1 (current experimental) fixes this

-- System Information:
Debian Release: squeeze/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libavformat52 depends on:
ii  libavcodec52   4:0.6-2   ffmpeg codec library
ii  libavutil504:0.6-2   ffmpeg utility library
ii  libbz2-1.0 1.0.5-4   high-quality block-sorting file co
ii  libc6  2.11.1-3  Embedded GNU C Library: Shared lib
ii  libgnutls262.8.5-2   the GNU TLS library - runtime libr
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

libavformat52 recommends no packages.

libavformat52 suggests no packages.

-- no debconf information



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52

severity important 536885
severity important 588240
forcemerge 588240 592710 592704 591349 579994 595241 536885
stop

On Thu, Sep 02, 2010 at 13:15:47 (CEST), Tom Parker wrote:

 Package: libavformat52
 Version: 4:0.6-2
 Severity: important

 With mencoder 2:1.0~rc3++final.dfsg1-1 (current testing/unstable) I get

 mencoder: relocation error: mencoder: symbol codec_wav_tags, version 
 LIBAVFORMAT_52 not defined in file libavformat.so.52 with link time reference

 Installing 2:1.0~rc4~try1.dsfg1-1 (current experimental) fixes this

Yes, the problem is that the symbol codec_wav_tags was an internal
symbol and not supposed to be used outside of libavformat.
Unfortunately, mplayer used it nevertheless.

This issue has been reported now a number of times. Perhaps we should
just add a Breaks relationship on libavcodec like this:

Package: libavformat52
Breaks: mplayer ( 1.0~rc4)

This should force the mplayer package to be upgraded when installing
ffmpeg 0.6.
 
-- 
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

Processed (with 2 errors): severity of 536885 is important, unarchiving 588240, severity of 588240 is important ...

Processing commands for cont...@bugs.debian.org:

 severity 536885 important
Failed to set severity of Bug 536885 to important: Not altering archived bugs; 
see unarchive.

 unarchive 588240
Bug #588240 {Done: Fabian Greffrath fab...@greffrath.com} [mplayer] Crashes 
immediately
Unarchived Bug 588240
 severity 588240 important
Bug #588240 {Done: Fabian Greffrath fab...@greffrath.com} [mplayer] Crashes 
immediately
Severity set to 'important' from 'grave'

 unarchive 591349
Bug #591349 {Done: Reinhard Tartler siret...@tauware.de} [mplayer] mplayer: 
segfault after latest upgrade
Unarchived Bug 591349
 unarchive 579994
Bug #579994 {Done: Reinhard Tartler siret...@tauware.de} [mplayer] mplayer: 
libavformat.so related problem
Unarchived Bug 579994
 unarchive 536885
Bug #536885 {Done: Fabian Greffrath greffr...@leat.rub.de} [mplayer] symbol 
lookup error: mplayer: undefined symbol: codec_wav_tags
Unarchived Bug 536885
 forcemerge 588240 592710 592704 591349 579994 595241 536885
Bug#588240: Crashes immediately
Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags
Bug#579994: mplayer: libavformat.so related problem
Bug#591349: mplayer: segfault after latest upgrade
Bug#592704: mplayer: relocation error when launching with many movies
Bug#592710: mplayer crashes at startup
Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined 
in file libavformat.so.52
Mismatch - only Bugs in the same package can be forcibly merged:
Bug 595241 is not in the same package as 588240
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
595241: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595241
579994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579994
591349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591349
536885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536885
588240: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588240
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: Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52

2010-09-02 Thread Fabian Greffrath


Am 02.09.2010 14:13, schrieb Reinhard Tartler:

This should force the mplayer package to be upgraded when installing
ffmpeg 0.6.


I am all for it. The fact that mplayer uses ffmpeg internals forces us 
to tie them together more closely.


[Reminds me of the internal vs. external ffmpeg packages dependencies. 
Is it possible to make only the mplayer package use the internal 
ffmpeg dependencies? I guess not...]


 - Fabian

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52

On Thu, Sep 02, 2010 at 15:23:20 (CEST), Fabian Greffrath wrote:

 Am 02.09.2010 14:13, schrieb Reinhard Tartler:
 This should force the mplayer package to be upgraded when installing
 ffmpeg 0.6.

 I am all for it. The fact that mplayer uses ffmpeg internals forces us
 to tie them together more closely.

the situation improves, but now, we clearly have this problem. I'm
therefore going to add this.

 [Reminds me of the internal vs. external ffmpeg packages
 dependencies. Is it possible to make only the mplayer package use the
 internal ffmpeg dependencies? I guess not...]

It indeed is possible by including an shlibs.local file in the mplayer
package.

-- 
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

Processed (with 1 errors): reassign 588240 to libavformat52, reassign 592710 to libavformat52, reassign 592704 to libavformat52 ...

Processing commands for cont...@bugs.debian.org:

 reassign 588240 libavformat52
Bug #588240 {Done: Fabian Greffrath fab...@greffrath.com} [mplayer] Crashes 
immediately
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/2:1.0~rc3+svn20100502-3.
 reassign 592710 libavformat52
Bug #592710 {Done: Fabian Greffrath fab...@greffrath.com} [mplayer] mplayer 
crashes at startup
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/2:1.0~rc3++final.dfsg1-1.
 reassign 592704 libavformat52
Bug #592704 {Done: Fabian Greffrath fab...@greffrath.com} [mplayer] mplayer: 
relocation error when launching with many movies
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/2:1.0~rc3++final.dfsg1-1.
 reassign 591349 libavformat52
Bug #591349 {Done: Reinhard Tartler siret...@tauware.de} [mplayer] mplayer: 
segfault after latest upgrade
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/2:1.0~rc3++final.dfsg1-1.
 reassign 579994 libavformat52
Bug #579994 {Done: Reinhard Tartler siret...@tauware.de} [mplayer] mplayer: 
libavformat.so related problem
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/2:1.0~rc3+svn20100502-1.
 reassign 595241 libavformat52
Bug #595241 [libavformat52] mencoder: symbol codec_wav_tags, version 
LIBAVFORMAT_52 not defined in file libavformat.so.52
Ignoring request to reassign bug #595241 to the same package
 reassign 536885 libavformat52
Bug #536885 {Done: Fabian Greffrath greffr...@leat.rub.de} [mplayer] symbol 
lookup error: mplayer: undefined symbol: codec_wav_tags
Bug reassigned from package 'mplayer' to 'libavformat52'.
Bug No longer marked as found in versions mplayer/1.0~rc3+svn20090405-1.
 merge 588240 592710 592704 591349 579994 595241 536885
Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags
Bug#579994: mplayer: libavformat.so related problem
Mismatch - only Bugs in same state can be merged:
Values for `severity' don't match:
 #536885 has `grave';
 #579994 has `important'

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
579994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579994
595241: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595241
592710: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592710
591349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591349
536885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536885
592704: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592704
588240: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588240
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

Processed (with 1 errors): severity of 588240 is important, severity of 592710 is important, severity of 592704 is important ...

Processing commands for cont...@bugs.debian.org:

 severity 588240 important
Bug #588240 {Done: Fabian Greffrath fab...@greffrath.com} [libavformat52] 
Crashes immediately
Ignoring request to change severity of Bug 588240 to the same value.
 severity 592710 important
Bug #592710 {Done: Fabian Greffrath fab...@greffrath.com} [libavformat52] 
mplayer crashes at startup
Severity set to 'important' from 'grave'

 severity 592704 important
Bug #592704 {Done: Fabian Greffrath fab...@greffrath.com} [libavformat52] 
mplayer: relocation error when launching with many movies
Ignoring request to change severity of Bug 592704 to the same value.
 severity 591349 important
Bug #591349 {Done: Reinhard Tartler siret...@tauware.de} [libavformat52] 
mplayer: segfault after latest upgrade
Ignoring request to change severity of Bug 591349 to the same value.
 severity 579994 important
Bug #579994 {Done: Reinhard Tartler siret...@tauware.de} [libavformat52] 
mplayer: libavformat.so related problem
Ignoring request to change severity of Bug 579994 to the same value.
 severity 595241 important
Bug #595241 [libavformat52] mencoder: symbol codec_wav_tags, version 
LIBAVFORMAT_52 not defined in file libavformat.so.52
Ignoring request to change severity of Bug 595241 to the same value.
 severity 536885 important
Bug #536885 {Done: Fabian Greffrath greffr...@leat.rub.de} [libavformat52] 
symbol lookup error: mplayer: undefined symbol: codec_wav_tags
Severity set to 'important' from 'grave'

 merge 588240 592710 592704 591349 579994 595241 536885
Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags
Bug#579994: mplayer: libavformat.so related problem
Bug#588240: Crashes immediately
Bug#591349: mplayer: segfault after latest upgrade
Bug#592704: mplayer: relocation error when launching with many movies
Bug#592710: mplayer crashes at startup
Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined 
in file libavformat.so.52
Mismatch - only Bugs in same state can be merged:
Values for `done mark' don't match:
 #536885 has `done';
 #595241 has `open'

 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
595241: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595241
592710: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592710
579994: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579994
591349: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591349
536885: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536885
592704: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592704
588240: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588240
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

Bug#595252: vlc: Says Please update alsa-lib

2010-09-02 Thread Nigel Horne

Package: vlc
Version: 1.1.3-1
Severity: normal

No audio comes out of an audio CD.  I get the mesage

Potential ALSA version problem:
VLC failed to initialize your sound output device (if any).
Please update alsa-lib to version 1.0.23-2-g8d80d5f or higher to try to 
fix this issue.

But when I try aptitude install alsa-lib, I get 

Couldn't find any package whose name or description matched alsa-lib


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vlc depends on:
ii  libaa1  1.4p5-38 ascii art library
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libfreetype62.4.2-2  FreeType 2 font engine, shared lib
ii  libfribidi0 0.19.2-1 Free Implementation of the Unicode
ii  libgcc1 1:4.4.4-11   GCC support library
ii  libgl1-mesa-glx [libgl1 7.7.1-4  A free implementation of the OpenG
ii  libqtcore4  4:4.6.3-1Qt 4 core module
ii  libqtgui4   4:4.6.3-1Qt 4 GUI module
ii  libsdl-image1.2 1.2.10-2+b1  image loading library for Simple D
ii  libsdl1.2debian 1.2.14-6 Simple DirectMedia Layer
ii  libstdc++6  4.4.4-11 The GNU Standard C++ Library v3
ii  libtar  1.2.11-6 C library for manipulating tar arc
ii  libvlccore4 1.1.3-1  base library for VLC and its modul
ii  libx11-62:1.3.3-3X11 client-side library
ii  libx11-xcb1 2:1.3.3-3Xlib/XCB interface library
ii  libxcb-keysyms1 0.3.6-1  utility libraries for X C Binding 
ii  libxcb-randr0   1.6-1X C Binding, randr extension
ii  libxcb-shm0 1.6-1X C Binding, shm extension
ii  libxcb-xv0  1.6-1X C Binding, xv extension
ii  libxcb1 1.6-1X C Binding
ii  libxext62:1.1.2-1X11 miscellaneous extension librar
ii  ttf-freefont20090104-7   Freefont Serif, Sans and Mono True
ii  vlc-nox 1.1.3-1  multimedia player and streamer (wi
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages vlc recommends:
pn  vlc-plugin-notify none (no description available)
ii  vlc-plugin-pulse  1.1.3-1PulseAudio plugin for VLC

Versions of packages vlc suggests:
ii  mozilla-plugin-vlc1.1.3-1multimedia plugin for web browsers
ii  videolan-doc  20070626-1 documentation for the VideoLAN str

Versions of packages vlc-nox depends on:
ii  liba52-0.7.40.7.4-14 library for decoding ATSC A/52 str
ii  libasound2  1.0.23-1 shared library for ALSA applicatio
ii  libass4 0.9.9-1  library for SSA/ASS subtitles rend
ii  libavahi-client30.6.27-2 Avahi client library
ii  libavahi-common30.6.27-2 Avahi common library
ii  libavc1394-00.5.3-1+b2   control IEEE 1394 audio/video devi
ii  libavcodec524:0.5.2-3ffmpeg codec library
ii  libavformat52   4:0.5.2-3ffmpeg file format library
ii  libavutil49 4:0.5.2-3ffmpeg utility library
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libcaca00.99.beta17-1colour ASCII art library
ii  libcddb21.3.2-2  library to access CDDB data - runt
ii  libcdio10   0.81-4   library to read and control CD-ROM
ii  libdbus-1-3 1.2.24-3 simple interprocess messaging syst
ii  libdc1394-222.1.2-3  high level programming interface f
ii  libdca0 0.0.5-3  decoding library for DTS Coherent 
ii  libdirac-encoder0   1.0.2-3  open and royalty free high quality
ii  libdvbpsi6  0.1.7-1  library for MPEG TS and DVB PSI ta
ii  libdvdnav4  4.1.3-7  DVD navigation library
ii  libdvdread4 4.1.3-10 library for reading DVDs
ii  libebml00.7.7-3.1access library for the EBML format
ii  libfaad22.7-4freeware Advanced Audio Decoder - 
ii  libflac81.2.1-3  Free Lossless Audio Codec - runtim
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.4.2-2  FreeType 2 font engine, shared lib
ii  libfribidi0 0.19.2-1 Free Implementation of the Unicode
ii  libgcc1 1:4.4.4-11

Bug#592457: severity of 592457 is serious

2010-09-02 Thread Philipp Kern

On Wed, Sep 01, 2010 at 04:35:38PM +0200, Christian Marillat wrote:
 unmerge 592457
 sererity 592457 serious
 reassign 592457 ffmpeg
 thanks
 
 Tartler please stop that.
 
 christian

Urgh.  It's the maintainers prerogative to set a severity.  If you
disagree you need to appeal to the Release Team for RC severities or the
tech-ctte.  Playing severity and assignment ping-pong is nothing I'd
expect from a DD.

Kind regards,
Philipp Kern


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: Bug#595241: mencoder: symbol codec_wav_tags, version LIBAVFORMAT_52 not defined in file libavformat.so.52

2010-09-02 Thread Fabian Greffrath


Am 02.09.2010 15:34, schrieb Reinhard Tartler:

the situation improves, but now, we clearly have this problem. I'm
therefore going to add this.


Please proceed.


It indeed is possible by including an shlibs.local file in the mplayer
package.


True, but this would have to get regularly adjusted to keep in sync 
with ffmpeg uploads.


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#592457: severity of 592457 is serious

2010-09-02 Thread Christian Marillat

Philipp Kern pk...@debian.org writes:

 On Wed, Sep 01, 2010 at 04:35:38PM +0200, Christian Marillat wrote:
 unmerge 592457
 sererity 592457 serious
 reassign 592457 ffmpeg
 thanks
 
 Tartler please stop that.
 
 christian

 Urgh.  It's the maintainers prerogative to set a severity.  If you
 disagree you need to appeal to the Release Team for RC severities or the
 tech-ctte.  Playing severity and assignment ping-pong is nothing I'd
 expect from a DD.

I don't play with the BTS. Tartler simply changed the bug severity
without any explanation.

For now and without more info these codecs are forbidden in Debian and
the bug severity remain serious and assigned to ffmpeg.

For the record :

,
| All in all, very promising stuff is going on!
| 
| 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/011348.html
`

,
| please don't reply to this bugreport directly
| 
| 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/011678.html
`

,
| Nothing new ?
| 
| 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012388.html
`

Christian



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#592457: severity of 592457 is serious

2010-09-02 Thread Philipp Kern

reassign 592457 ftp.debian.org
thanks

Christian,

On Thu, Sep 02, 2010 at 04:08:53PM +0200, Christian Marillat wrote:
  On Wed, Sep 01, 2010 at 04:35:38PM +0200, Christian Marillat wrote:
  unmerge 592457
  sererity 592457 serious
  reassign 592457 ffmpeg
  thanks
  
  Tartler please stop that.
  
  christian
  Urgh.  It's the maintainers prerogative to set a severity.  If you
  disagree you need to appeal to the Release Team for RC severities or the
  tech-ctte.  Playing severity and assignment ping-pong is nothing I'd
  expect from a DD.
 I don't play with the BTS. Tartler simply changed the bug severity
 without any explanation.

so did you, for what it's worth.  

 For now and without more info these codecs are forbidden in Debian and
 the bug severity remain serious and assigned to ffmpeg.

You might consider yourself the codec police of Debian, but then I think the
owner of the pseudo package Reinhard assigned it to is considered as such.  So
you're not special, sorry.  (Neither am I.)

Reassigning to ftp.debian.org again, due to the fact that they are the ones
who decide what's acceptable to redistribute in Debian and what's not.  You
are of course free to voice your opinions, but please respect the maintainer
and FTP masters on this matter.  Thanks.

 For the record :
[... links snipped ...]

So?  Reinhard told people to wait.  One major reason of this are vacations
of involved people.  Still, ftp.debian.org seems to be the right place for
this to get resolved.  (And we all want to see this resolved as soon as
possible, of course.)

Kind regards,
Philipp Kern


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

Processed: Re: Bug#592457: severity of 592457 is serious

Processing commands for cont...@bugs.debian.org:

 reassign 592457 ftp.debian.org
Bug #592457 [ffmpeg] ffmpeg: forbidden encoders have been enabled
Bug reassigned from package 'ffmpeg' to 'ftp.debian.org'.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
592457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592457
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: first package: pd-wiimote

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/10 05:10, Reinhard Tartler wrote:

  So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.

 Instead of using a quilt patch should I simply replace the Makefile with
 the new one and check that into the master branch?
 
 no, that would be pretty confusing. I'd rather do these changes in the
 'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
 created or something.
 

The correct approach is to have upstream fix this, not us. In the
current workflow, touching the upstream branch for stuff other than
merging upstream versions is wrong IMO.

- -- 
Saludos,
Felipe Sateler
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMf777AAoJEKO6uuJAjdbPXJQP/2vUkNyC4obUfoYXwv/I+8ef
Y1OorpSUOD3Gr+R9lJf7VpZEXkdtfb9MQQjXIKR3Vzq5UYJZKjjwv3KoOAtjL8pc
yTozvHg3Slo+rEYnxfgEvw5JIC/L0MD3CPnvJUkjoEVH95thLRIxoVB5khDWTF2V
KP4zxvCQfv8wMLgx82RVpr6daypIKc5NKutVk9vARxTxw8r6wcJpDH1ZMfmYAgku
TXP2webN+Zo5kxACT+DUxe8Oo281obsXcclpq7DDP+HdGDEw2L445z9lz8AUSm/d
ICZvlxBrWh9/AbFZwJ0/nJCYdyf+KECBWgoRIgWpi0djNxkAq1joS7GdUJT0Hj5T
w+FHlNoJEPpAJh0XXPgW72HDWhHTtZj0CFa+azGLp9FgKKnLvDI+LQ8OMXD+l1ym
OYdw0K5OhtqkR9PABFr3WhxvIYNZfxdAhvIG0B8Sl8p8DBASxeT2v+MPyNBU2K32
xROqvq7/RwRSZJ2IjE3jTDbGJui6Nxus+NyBtOE2Q3Z+z/CH8sZe+JkgkT4ac2uu
5e1E0iRlybS/7VS/xtxtkdQojAOOvPe/PUCdQQlYw45haWhT61zsDK/xu0AhxtUg
aaC6ojP/3m/lxpSNMNdecLv4D1iPNUrdS/GoLCn2ODrFa+VGDWuJABvDGZZLkEkh
P1J97cz8QjGSmaXeYbQ3
=3lEp
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: first package: pd-wiimote

On Thu, Sep 02, 2010 at 17:13:03 (CEST), Felipe Sateler wrote:

 On 02/09/10 05:10, Reinhard Tartler wrote:

  So another approach would be to repackage the
 tarball to just include the COPYING file. While we are at it, we could
 also use the new Makefile and get rid of the other patch.

 Instead of using a quilt patch should I simply replace the Makefile with
 the new one and check that into the master branch?

 no, that would be pretty confusing. I'd rather do these changes in the
 'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
 created or something.


 The correct approach is to have upstream fix this, not us.

Indeed.

 In the current workflow, touching the upstream branch for stuff other
 than merging upstream versions is wrong IMO.

yeah, maybe creating a designated upstream.dfsg branch would be cleaner.
-- 
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: first package: pd-wiimote

On Thu, 2010-09-02 at 11:13 -0400, Felipe Sateler wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 02/09/10 05:10, Reinhard Tartler wrote:
 
   So another approach would be to repackage the
  tarball to just include the COPYING file. While we are at it, we could
  also use the new Makefile and get rid of the other patch.
 
  Instead of using a quilt patch should I simply replace the Makefile with
  the new one and check that into the master branch?
  
  no, that would be pretty confusing. I'd rather do these changes in the
  'upstream' branch branch, and have a wiimote-0.3.1.dfsg1.orig.tar.gz
  created or something.
  
 
 The correct approach is to have upstream fix this, not us. In the
 current workflow, touching the upstream branch for stuff other than
 merging upstream versions is wrong IMO.
 

Ok. It's in progress. I'll report back, when done.

Thanks for your help
Roman


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Changing the commit mails subject?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I find the subject lines very uninformative. I would like to change it
to this format:

$repository/$branch: $commitmsg

where $commitmsg is the first line of the commit message.


What do you think?

- -- 
Saludos,
Felipe Sateler
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMf8SoAAoJEKO6uuJAjdbPHoUP/03rH7NNOJft5i+eIYHn7ECr
kpDnMJXKdj27Erkrhvfz8E28Pg/iBruADIqExf9PDIaCY1UBjVUJSkb3a+bDyhnC
C+Ewe+W0celux/PN4Kx996DsrzK9dk7J0l/AxJh6uQkwaYf7SqyrIztkk4ACVvV8
896QOcB1iMlbUdxrPxzUkemf9gnMMa4ANLTQTrGdzZEhbZV8IDxRQBxzfwduAfNx
JFe0dmgKc3sgq3EiO1lHTWSRX/HCOdkhUauQIZYI03XAZ15jq4HOdb/3W0bvkBVk
lQ7j9P/Y4om49Tk+byyJIIsaa3RWhQ31fybMJ9niDDjjW3v1YL/HyLa0VzwIKJl9
1ES53Asf8IOyKzaLVnHxtQJvtfQyE6e4b/ESf8vZWVtPSIBTzeBAsgk5SwN7UBXh
QGqCOatuSR6AevBeIL6C+mZgoujIOzy6wVOw93LuCGFakyIzR4d3cfFnOuLEiunS
B28cb73KHEsOJV7n8zFFG+kXJ3FUf9kVK3NQNoPIKkAGxi/jFFdnLXa1WYdKg0nE
pAjLqdo9jlZJJbK03waCx5k9mq5KWgjWM4jxPG3w6SYnl/11FgFzCgKSKmqCe72b
xtSVv3bwUwceK3pj9W6xOGMxmBc6VtXYoQRt/y3wpcpLkcOLXY6z9SNTDd/jbaby
FcpnMQBziCFFz75OuV5l
=2wxu
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: first package: pd-wiimote


On Thu, Sep 02, 2010 at 05:21:54PM +0200, Reinhard Tartler wrote:

On Thu, Sep 02, 2010 at 17:13:03 (CEST), Felipe Sateler wrote:


On 02/09/10 05:10, Reinhard Tartler wrote:

So another approach would be to repackage the tarball to just 
include the COPYING file. While we are at it, we could also use 
the new Makefile and get rid of the other patch.


Instead of using a quilt patch should I simply replace the Makefile 
with the new one and check that into the master branch?


no, that would be pretty confusing. I'd rather do these changes in 
the 'upstream' branch branch, and have a 
wiimote-0.3.1.dfsg1.orig.tar.gz created or something.




The correct approach is to have upstream fix this, not us.


Indeed.

In the current workflow, touching the upstream branch for stuff other 
than merging upstream versions is wrong IMO.


yeah, maybe creating a designated upstream.dfsg branch would be 
cleaner.


Makes no difference in the end: What is wrong (assuming Felipe agrees 
with me here) is to *redistribute* non-pristine tarball for reasons 
other than DFSG violations.



 - 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: Changing the commit mails subject?

On Thu, Sep 02, 2010 at 17:37:12 (CEST), Felipe Sateler wrote:

 I find the subject lines very uninformative. I would like to change it
 to this format:

 $repository/$branch: $commitmsg

 where $commitmsg is the first line of the commit message.

I like the idea!

-- 
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: Changing the commit mails subject?

On 02/09/10 11:52, Reinhard Tartler wrote:
 On Thu, Sep 02, 2010 at 17:37:12 (CEST), Felipe Sateler wrote:
 
 I find the subject lines very uninformative. I would like to change it
 to this format:

 $repository/$branch: $commitmsg

 where $commitmsg is the first line of the commit message.
 
 I like the idea!
 

I've done it. Only commits get a different subject line, tag additions
and branch creations get the old one.

-- 
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: first package: pd-wiimote

2010-09-02 Thread Hans-Christoph Steiner



On Sep 2, 2010, at 4:06 AM, Roman Haefeli wrote:


On Thu, 2010-09-02 at 09:38 +0200, Reinhard Tartler wrote:

On Thu, Sep 02, 2010 at 01:16:03 (CEST), Roman Haefeli wrote:


Hi all

I checked in my first package. I tried to follow - where possible  
- very

closely to pd-motex, which has been already uploaded.
I would be glad if someone could have a look at it.

FYI: It is using what I believe is called short-form dh.


indeed, it is.

I've taken a quick look at the package,
it's a really small package and
rather easy to review.

Packagingwise, I think it is fine, but I'm umcomfortable with the two
patches. First, please use the patch metadata as described in
http://dep.debian.net/deps/dep3/.

But as for the actual patches, I'm rather uncomfortable with
them. The add-license patch adds the complete text of the GPL. I'm  
not

sure how the ftpteam thinks about it, but to me it feels very
strange. Is upstream aware of the problem, can't they just reissue  
the
tarball with the complete license text? Moreover, quoting the part  
How

to Apply These Term to Your New Programs is usually also helpful.

I'd be more comfortable if the GPL text was just included in debian/,
read, as non-patch, but still, I really think this file should be  
part

of the orig.tar.gz.


The reason why I added the LICENSE file in the first place is because
the Makefile is hardcoded to install it. Probably I shouldn't have  
done
it as a patch. But then again in the thread about pd-motex people  
agreed

that it would be better to create a symlink to the respective license
in /usr/share/common-licenses/.
So actually, I could remove install LICENSE line in the Makefile  
which

makes the add-license.patch obsolete  and let debian/rules do the
symlink and the result will be the same. What do you think?


So another approach would be to repackage the
tarball to just include the COPYING file. While we are at it, we  
could

also use the new Makefile and get rid of the other patch.


Instead of using a quilt patch should I simply replace the Makefile  
with

the new one and check that into the master branch?

Roman



Roman,

Since you now have upstream commit access, I would fix the Makefile  
and LICENSE.txt problems in the pure-data SVN, then once that's  
working, we can release a tarball on the pure-data sourceforge page.   
Then the debian packaging becomes much simpler, like the other Pd  
packages based on this Makefile template (pd-motex, pd-pmpd, etc).


.hc




As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: first package: pd-wiimote

2010-09-02 Thread Hans-Christoph Steiner

On Sep 2, 2010, at 3:36 AM, Roman Haefeli wrote:

On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:

Looks pretty good to me, but I'm just learning myself :)

Thanks for having a look.
One thing I like to mention: The upstream sources come with a Makefile
based on a apparently old Makefile template for libdirs. It was pretty
broken and created superfluous directories in debian/. I copied over
the

current template, adapted it and applied it as a quilt patch. Is that
the proper way to do it?

I am
wondering about the strip stuff:

override_dh_strip:
strip --remove-section=.comment --remove-section=.note --strip-
unneeded \
debian/pd-wiimote/usr/lib/pd/extra/wiimote/wiimote.pd_linux

My guess is that this is needed in order to properly strip
the .pd_linux so binaries?

Yeah, dh_strip apparently does not consider .pd_linux files as shared
objects and also there is no way to force it by passing it file
names as

arguments.

I used the strip command from a mail by Felipe Sateler [1]

[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012336.html

Roman

I was under the impression that dh would set the strip options in the $
(INSTALL_PROGRAM) for the Makefile, so that an explicit strip wasn't
necessary. Is that true? If so, I'll change up the pd packages to
use INSTALL_PROGRAM and INSTALL_DATA properly. I don't know why I
didn't do this to begin with.

.hc

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish.-William Carlos Williams

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

2010-09-02 Thread Adam D. Barratt

On Wed, 2010-09-01 at 09:40 -0400, Felipe Sateler wrote: 
 On 01/09/10 04:10, Reinhard Tartler wrote:
  this package has been tried four times and every time we see a different
  build error:
  
  #1 (on lebrun):segfault in gcc
  #2 (on schroeder): segfault in python (i.e. scons, the build system)
  #3 (on lebrun):segfault in gcc, but in a different compilation unit as 
  #1
  #4 (on schroeder): sigill in gcc
[...]
 Please, I'd like to know what to do about this. I have a RC bug on
 csound (#591802) about this build failure and by this point I think this
 is not a bug in csound. Note that I have built the package successfully
 on smetana, and Adrian Knoth also did on a machine of his own. Should I
 upload the package and close the bug?

In the short term, uploading the package built on smetana in order to
allow the package to migrate (possibly with a gentle nudge from britney)
is ok.

Longer term, we still need to work out why the package builds happily on
both porter boxes (having managed to build it successfully myself on
sperger last night) but not on the buildds, so that we can rebuild it in
the future for security builds and stable updates.

Regards,

Adam

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

On 02/09/10 14:06, Adam D. Barratt wrote:
 On Wed, 2010-09-01 at 09:40 -0400, Felipe Sateler wrote: 
 On 01/09/10 04:10, Reinhard Tartler wrote:
 this package has been tried four times and every time we see a different
 build error:

 #1 (on lebrun):segfault in gcc
 #2 (on schroeder): segfault in python (i.e. scons, the build system)
 #3 (on lebrun):segfault in gcc, but in a different compilation unit as 
 #1
 #4 (on schroeder): sigill in gcc
 [...]
 Please, I'd like to know what to do about this. I have a RC bug on
 csound (#591802) about this build failure and by this point I think this
 is not a bug in csound. Note that I have built the package successfully
 on smetana, and Adrian Knoth also did on a machine of his own. Should I
 upload the package and close the bug?
 
 In the short term, uploading the package built on smetana in order to
 allow the package to migrate (possibly with a gentle nudge from britney)
 is ok.

OK, I'm uploading now.

 
 Longer term, we still need to work out why the package builds happily on
 both porter boxes (having managed to build it successfully myself on
 sperger last night) but not on the buildds, so that we can rebuild it in
 the future for security builds and stable updates.

I think I will need help from sparc-savvy people (or should I say, I can
provide help to sparc-savvy people if necessary? I doubt I have much to
say on the issue).


-- 
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

Processing of csound_5.12.1~dfsg-5_sparc.changes

2010-09-02 Thread Archive Administrator

csound_5.12.1~dfsg-5_sparc.changes uploaded successfully to localhost
along with the files:
  csound_5.12.1~dfsg-5_sparc.deb
  csound-gui_5.12.1~dfsg-5_sparc.deb
  csound-utils_5.12.1~dfsg-5_sparc.deb
  libcsound64-5.2_5.12.1~dfsg-5_sparc.deb
  libcsnd-java_5.12.1~dfsg-5_sparc.deb
  pd-csound_5.12.1~dfsg-5_sparc.deb
  python-csound_5.12.1~dfsg-5_sparc.deb
  libcsnd5.2_5.12.1~dfsg-5_sparc.deb
  liblua5.1-luacsnd5.2_5.12.1~dfsg-5_sparc.deb
  tclcsound_5.12.1~dfsg-5_sparc.deb
  libcsoundac5.2_5.12.1~dfsg-5_sparc.deb
  python-csoundac_5.12.1~dfsg-5_sparc.deb
  csladspa_5.12.1~dfsg-5_sparc.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

csound_5.12.1~dfsg-5_sparc.changes ACCEPTED

2010-09-02 Thread Archive Administrator




Accepted:
csladspa_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/csladspa_5.12.1~dfsg-5_sparc.deb
csound-gui_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/csound-gui_5.12.1~dfsg-5_sparc.deb
csound-utils_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/csound-utils_5.12.1~dfsg-5_sparc.deb
csound_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/csound_5.12.1~dfsg-5_sparc.deb
libcsnd-java_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/libcsnd-java_5.12.1~dfsg-5_sparc.deb
libcsnd5.2_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/libcsnd5.2_5.12.1~dfsg-5_sparc.deb
libcsound64-5.2_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/libcsound64-5.2_5.12.1~dfsg-5_sparc.deb
libcsoundac5.2_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/libcsoundac5.2_5.12.1~dfsg-5_sparc.deb
liblua5.1-luacsnd5.2_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/liblua5.1-luacsnd5.2_5.12.1~dfsg-5_sparc.deb
pd-csound_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/pd-csound_5.12.1~dfsg-5_sparc.deb
python-csound_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/python-csound_5.12.1~dfsg-5_sparc.deb
python-csoundac_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/python-csoundac_5.12.1~dfsg-5_sparc.deb
tclcsound_5.12.1~dfsg-5_sparc.deb
  to main/c/csound/tclcsound_5.12.1~dfsg-5_sparc.deb


Override entries for your package:
csladspa_5.12.1~dfsg-5_sparc.deb - optional sound
csound-gui_5.12.1~dfsg-5_sparc.deb - optional sound
csound-utils_5.12.1~dfsg-5_sparc.deb - optional sound
csound_5.12.1~dfsg-5_sparc.deb - optional sound
libcsnd-java_5.12.1~dfsg-5_sparc.deb - optional java
libcsnd5.2_5.12.1~dfsg-5_sparc.deb - optional sound
libcsound64-5.2_5.12.1~dfsg-5_sparc.deb - optional libs
libcsoundac5.2_5.12.1~dfsg-5_sparc.deb - optional sound
liblua5.1-luacsnd5.2_5.12.1~dfsg-5_sparc.deb - optional sound
pd-csound_5.12.1~dfsg-5_sparc.deb - optional sound
python-csound_5.12.1~dfsg-5_sparc.deb - optional python
python-csoundac_5.12.1~dfsg-5_sparc.deb - optional python
tclcsound_5.12.1~dfsg-5_sparc.deb - optional sound



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

Re: Bug#589689: transition to libjack-jackd2-0 breaks many packages

2010-09-02 Thread Martin Zobel-Helas

Hi, 

On Thu Sep 02, 2010 at 19:06:42 +0100, Adam D. Barratt wrote:
   #4 (on schroeder): sigill in gcc

can you please try to compile it with -O0 on schroeder? 

-- 
 Martin Zobel-Helas zo...@debian.org  | Debian System Administrator
 Debian  GNU/Linux Developer   |   Debian Listmaster
 Public key http://zobel.ftbfs.de/5d64f870.asc   -   KeyID: 5D64 F870
 GPG Fingerprint:  5DB3 1301 375A A50F 07E7  302F 493E FB8E 5D64 F870


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: first package: pd-wiimote

On Thu, Sep 02, 2010 at 12:58:57PM -0400, Hans-Christoph Steiner wrote:

On Sep 2, 2010, at 3:36 AM, Roman Haefeli wrote:

On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:

Looks pretty good to me, but I'm just learning myself :)

current template, adapted it and applied it as a quilt patch. Is that
the proper way to do it?

I am
wondering about the strip stuff:

override_dh_strip:
strip --remove-section=.comment --remove-section=.note --strip-
unneeded \
debian/pd-wiimote/usr/lib/pd/extra/wiimote/wiimote.pd_linux

My guess is that this is needed in order to properly strip
the .pd_linux so binaries?

Yeah, dh_strip apparently does not consider .pd_linux files as shared
objects and also there is no way to force it by passing it file
names as

arguments.

I used the strip command from a mail by Felipe Sateler [1]

[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012336.html

Roman

I was under the impression that dh would set the strip options in the
$(INSTALL_PROGRAM) for the Makefile, so that an explicit strip wasn't
necessary. Is that true? If so, I'll change up the pd packages to
use INSTALL_PROGRAM and INSTALL_DATA properly. I don't know why I
didn't do this to begin with.

No, debhelper does not interfere with $(INSTALL_PROGRAM). For Debian
packaging binaries should not be stripped during build - then dh_strip
should deal with stripping afterwards.

Problem is, the unusual filenames goes below the radar of dh_strip, and
(according to Felipe) dh_strip cannot be spoonfed additional files to
strip.

- 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: first package: pd-wiimote

2010-09-02 Thread Hans-Christoph Steiner

On Sep 2, 2010, at 5:20 PM, Jonas Smedegaard wrote:

On Thu, Sep 02, 2010 at 12:58:57PM -0400, Hans-Christoph Steiner
wrote:

On Sep 2, 2010, at 3:36 AM, Roman Haefeli wrote:

On Thu, 2010-09-02 at 01:07 -0400, Hans-Christoph Steiner wrote:

Looks pretty good to me, but I'm just learning myself :)

Thanks for having a look.
One thing I like to mention: The upstream sources come with a
Makefile
based on a apparently old Makefile template for libdirs. It was
pretty
broken and created superfluous directories in debian/. I copied
over the
current template, adapted it and applied it as a quilt patch. Is
that

the proper way to do it?

I am
wondering about the strip stuff:

override_dh_strip:
strip --remove-section=.comment --remove-section=.note --strip-
unneeded \
debian/pd-wiimote/usr/lib/pd/extra/wiimote/wiimote.pd_linux

My guess is that this is needed in order to properly strip
the .pd_linux so binaries?

Yeah, dh_strip apparently does not consider .pd_linux files as
shared
objects and also there is no way to force it by passing it file
names as

arguments.

I used the strip command from a mail by Felipe Sateler [1]

[1]
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-August/012336.html

Roman

I was under the impression that dh would set the strip options in
the $(INSTALL_PROGRAM) for the Makefile, so that an explicit strip
wasn't necessary. Is that true? If so, I'll change up the pd
packages to use INSTALL_PROGRAM and INSTALL_DATA properly. I don't
know why I didn't do this to begin with.

No, debhelper does not interfere with $(INSTALL_PROGRAM). For
Debian packaging binaries should not be stripped during build - then
dh_strip should deal with stripping afterwards.

Problem is, the unusual filenames goes below the radar of dh_strip,
and (according to Felipe) dh_strip cannot be spoonfed additional
files to strip.

Ok, so unless anyone objects, I'm going to add this to all my pd
packages so they get stripped. That includes pd-motex. I guess that
means the package version gets incremented, since its currently in NEW?

.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: first package: pd-wiimote