Bug#643333: jack.plumbing fails badly in the face of its JACK 2 server vanishing

2011-09-27 Thread Jamie Heilman
Package: jack-tools
Version: 20101210-1

jack.plumbing behaves inconsistently depending the JACK client library
version it is running against, which unfortunately translates into
useless and annoying behavior when running against the JACK 2 libs.
Specifically, jack.plumbing (running *without* the -d flag) with the
JACK 1 client library will, upon death of the server, print out:

  cannot read server event (Success)
  cannot continue execution of the processing graph (Bad file descriptor)
  jack_client_thread zombified - exiting from JACK

and the process will die.  This is useful behavior, as it allows the
user to script a simple restart facilities (eg. using jack_wait).  If,
however, jack.plumbing is running with the JACK 2 client library it
will, upon death of the server, print out:

  JackSocketClientChannel read fail

and continue to run but cease to ever do any graph manipulations ever
again, until it's killed and restarted.  This is not useful behavior,
and is a pretty crappy mode of failure.  It'd be better if it died
when the JACK 2 server did, or failing that if it reconnected (or
whatever the appropriate nomenclature is in this case) if and when the
JACK 2 server came back (though I suspect that's just making the code
unnecessarily complex, and that bailing out is ultimately better).

You could, I suppose, argue this is a JACK 2 problem, and I don't know
enough about the planned ecology of JACK to really debate it, but
what's clear is that Debian allows jack-tools to be installed with
either jackd1 or jackd2 packages and that jack.plumbings's behavior
when jackd2 is installed is lame.


-- 
Jamie Heilman http://audible.transient.net/~jamie/



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


Ardour 3

2011-09-27 Thread Jaromír Mikeš
Hi all,

I am just curious if exists in team plan to introduce Ardour 3 alpas
in experimental?

mira

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


Bug#643377: flac: FTBFS: main.c:118:3: error: format not a string literal and no format arguments [-Werror=format-security]

2011-09-27 Thread Didier Raboud
Source: flac
Version: 1.2.1-5
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20110923 qa-ftbfs hardening-format-security hardening
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:
 gcc -DHAVE_CONFIG_H -I. -I../../..   -DFLaC__INLINE=__inline__ -DNDEBUG 
 -I../../.. -I./include -I../../../include   -O3 -funroll-loops 
 -finline-functions -Wall -W -Winline -g -O2 -fstack-protector 
 --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
 -Werror=format-security -c main.c
 main.c: In function 'main':
 main.c:118:3: error: format not a string literal and no format arguments 
 [-Werror=format-security]
 main.c:123:3: error: format not a string literal and no format arguments 
 [-Werror=format-security]
 main.c:132:4: error: format not a string literal and no format arguments 
 [-Werror=format-security]
 cc1: some warnings being treated as errors
 
 make[5]: *** [main.o] Error 1

The full build log is available from:
   http://people.debian.org/~lucas/logs/2011/09/23/flac_1.2.1-5_lsid64.buildlog

This happened because since dpkg 1.16.0 [0], hardening flags are enabled 
under various conditions.

[0] http://lists.debian.org/debian-devel-announce/2011/09/msg1.html

A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
of the Grid'5000 platform, using a clean chroot.  Internet was not
accessible from the build systems.



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


Bug#643406: hydrogen: FTBFS: libs/hydrogen/src/object.cpp:242:30: error: format not a string literal and no format arguments [-Werror=format-security]

2011-09-27 Thread Didier Raboud
Source: hydrogen
Version: 0.9.5-3
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20110923 qa-ftbfs hardening-format-security hardening
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:
 g++ -o libs/hydrogen/src/object.o -c -O3 -fomit-frame-pointer -funroll-loops 
 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 
 -Wformat -Wformat-security -Werror=format-security -Wall -DOSS_SUPPORT 
 -DALSA_SUPPORT -DJACK_SUPPORT -DLRDF_SUPPORT -DPORTAUDIO_SUPPORT 
 -DPORTMIDI_SUPPORT -DLADSPA_SUPPORT -DLIBARCHIVE_SUPPORT -DQT_CORE_LIB 
 -DQT_GUI_LIB -DQT_XML_LIB -DQT_SHARED -I. -Igui/src 
 -I3rdparty/install/include -Ilibs/hydrogen/include -I/usr/include/qt4 
 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml 
 libs/hydrogen/src/object.cpp
 libs/hydrogen/src/object.cpp: In function 'void* loggerThread_func(void*)':
 libs/hydrogen/src/object.cpp:242:30: error: format not a string literal and 
 no format arguments [-Werror=format-security]
 libs/hydrogen/src/object.cpp:244:42: error: format not a string literal and 
 no format arguments [-Werror=format-security]
 cc1plus: some warnings being treated as errors
 
 scons: *** [libs/hydrogen/src/object.o] Error 1
 scons: building terminated because of errors.
 make: *** [debian/stamp-scons-build] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2011/09/23/hydrogen_0.9.5-3_lsid64.buildlog

This happened because since dpkg 1.16.0 [0], hardening flags are enabled 
under various conditions.

[0] http://lists.debian.org/debian-devel-announce/2011/09/msg1.html

A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
of the Grid'5000 platform, using a clean chroot.  Internet was not
accessible from the build systems.



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


Bug#643454: pd-zexy: FTBFS: freadln.c:115:7: error: format not a string literal and no format arguments [-Werror=format-security]

2011-09-27 Thread Didier Raboud
Source: pd-zexy
Version: 2.2.3-2
Severity: serious
Tags: wheezy sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20110923 qa-ftbfs hardening-format-security hardening
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part:
 gcc -I.  -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD   -g -O2 -fstack-protector 
 --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
 -Werror=format-security -Wall -mms-bitfields -fPIC   -c -o freadln.o freadln.c
 freadln.c: In function 'freadln_open':
 freadln.c:115:7: error: format not a string literal and no format arguments 
 [-Werror=format-security]
 cc1: some warnings being treated as errors
 
 make[1]: *** [freadln.o] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2011/09/23/pd-zexy_2.2.3-2_lsid64.buildlog

This happened because since dpkg 1.16.0 [0], hardening flags are enabled 
under various conditions.

[0] http://lists.debian.org/debian-devel-announce/2011/09/msg1.html

A list of current common problems and possible solutions is available at 
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
of the Grid'5000 platform, using a clean chroot.  Internet was not
accessible from the build systems.



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


Re: Ardour 3

2011-09-27 Thread Reinhard Tartler
On Di, Sep 27, 2011 at 14:25:32 (CEST), Jaromír Mikeš wrote:

 Hi all,

 I am just curious if exists in team plan to introduce Ardour 3 alpas
 in experimental?

No, but I'd say If you feel like doing it, go for it!

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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

Re: [SCM] pd-zexy/master: Regenerated debian/control

2011-09-27 Thread Jonas Smedegaard
On 11-09-27 at 06:48pm, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:50 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:
 
  The following commit has been merged in the master branch:
  commit ef81a4d7dd804b2a628071a4693f99e9e50d82b9
  Author: IOhannes m zmölnig zmoel...@iem.at
  Date:   Tue Sep 27 16:42:58 2011 +0200
 
  Regenerated debian/control
 
  diff --git a/debian/control b/debian/control
  index 365b3cf..67affed 100644
  --- a/debian/control
  +++ b/debian/control
  @@ -4,11 +4,11 @@ Priority: optional
   Maintainer: Debian Multimedia Maintainers 
  pkg-multimedia-maintainers@lists.alioth.debian.org
   Uploaders: IOhannes m zmoelnig (gpg-key at iem) zmoel...@iem.at,
Jonas Smedegaard d...@jones.dk
  -Build-Depends: debhelper (= 7.0.1),
  +Build-Depends: debhelper,
dh-buildinfo,
 
 This hunk looks wrong. Are you really sure about this?

Looks fine to me: debhelper 7 is in oldstable, so no need for versioned 
dependency - despite the honorable Joey Hess instructing differently in 
debhelper documentation, and lintian (possible still) spewing warnings!


 - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] pd-zexy/master: Regenerated debian/control

2011-09-27 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-27 18:48, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:50 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:
 
 The following commit has been merged in the master branch:
 commit ef81a4d7dd804b2a628071a4693f99e9e50d82b9
 Author: IOhannes m zmölnig zmoel...@iem.at
 Date:   Tue Sep 27 16:42:58 2011 +0200

 Regenerated debian/control

 diff --git a/debian/control b/debian/control
 index 365b3cf..67affed 100644
 --- a/debian/control
 +++ b/debian/control
 @@ -4,11 +4,11 @@ Priority: optional
  Maintainer: Debian Multimedia Maintainers 
 pkg-multimedia-maintainers@lists.alioth.debian.org
  Uploaders: IOhannes m zmoelnig (gpg-key at iem) zmoel...@iem.at,
   Jonas Smedegaard d...@jones.dk
 -Build-Depends: debhelper (= 7.0.1),
 +Build-Depends: debhelper,
   dh-buildinfo,
 
 This hunk looks wrong. Are you really sure about this?
 

if it is indeed wrong, then it is a bug in cdbs, which generated this
dependency.
i trusted cdbs, but of course this can be questioned.

gmdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CADsACgkQkX2Xpv6ydvTMfgCgnZypA9GXEhfncgPhbqshGbxm
hLkAni0NXUyyQYBFavj/mQ4skBSLWCPL
=gAA1
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread Jonas Smedegaard
On 11-09-27 at 06:49pm, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:51 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:
 
  The following commit has been merged in the master branch:
  commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
  Author: IOhannes m zmölnig zmoel...@iem.at
  Date:   Tue Sep 27 17:13:52 2011 +0200
 
  preserve autom4te.cache
  
  which is in the upstream tarball though it never should have gone 
  there...

[snip]

 Why not deleting it in the clean target and remove it from the 
 packaging (i.e., 'master') branch?

IMO a noble ideal to preserve upstream sources as pristine as possible.


 - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-27 18:49, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:51 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:
 
 The following commit has been merged in the master branch:
 commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
 Author: IOhannes m zmölnig zmoel...@iem.at
 Date:   Tue Sep 27 17:13:52 2011 +0200

 preserve autom4te.cache
 
 which is in the upstream tarball though it never should have gone 
 there...

 
 Why not deleting it in the clean target and remove it from the packaging
 (i.e., 'master') branch?

it get's deleted by dh_clean

deleting is probably the best thing, the question is how to achieve that
here:
- - strip the autom4te.cache from the pristine-tar import?
- - patch the offending sources away?
- - ...

fmdarf
IOhannes

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CAQAACgkQkX2Xpv6ydvTXbACeOmtG5pNCWpY8nKY3+9DMulvp
A+cAmwVEYGgG8Z39/eOCEXgudfksWrw1
=MbPK
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] pd-zexy/master: Regenerated debian/control

2011-09-27 Thread Jonas Smedegaard
On 11-09-27 at 06:56pm, IOhannes m zmoelnig wrote:
 On 2011-09-27 18:48, Reinhard Tartler wrote:
  This hunk looks wrong. Are you really sure about this?
  
 
 if it is indeed wrong, then it is a bug in cdbs, which generated this 
 dependency.
 i trusted cdbs, but of course this can be questioned.

Do *not* blindly trust CDBS!  It is a _helper_ tool: ultimately you as 
package maintainer are responsible for what you apply to your packaging!


 - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] pd-zexy/master: Regenerated debian/control

2011-09-27 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-09-27 19:05, Jonas Smedegaard wrote:
 On 11-09-27 at 06:56pm, IOhannes m zmoelnig wrote:
 On 2011-09-27 18:48, Reinhard Tartler wrote:
 This hunk looks wrong. Are you really sure about this?


 if it is indeed wrong, then it is a bug in cdbs, which generated this 
 dependency.
 i trusted cdbs, but of course this can be questioned.
 
 Do *not* blindly trust CDBS!  It is a _helper_ tool: ultimately you as 
 package maintainer are responsible for what you apply to your packaging!
 

true enough...
nevertheless, when i inspected debian/control after regeneration and
noticed that the version of debhelper was stripped, i did trust cdbs
that it did the right thing (rembering all your fiery discussions about
backward compat).

nevertheless i have to admit that i did not verify whether my trust was
justified.

fgmadsr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CBDIACgkQkX2Xpv6ydvSvxwCg1ixQy3qvvddgM0CIdxruTGKR
LHYAoLHoX2nDcYwUBuX9hyhy1zGYp3c/
=pp4K
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Ardour 3

2011-09-27 Thread Jaromír Mikeš
2011/9/27 Reinhard Tartler siret...@tauware.de:
 On Di, Sep 27, 2011 at 14:25:32 (CEST), Jaromír Mikeš wrote:

 I am just curious if exists in team plan to introduce Ardour 3 alpas
 in experimental?

 No, but I'd say If you feel like doing it, go for it!

Hmm ... Ardour is very complex package and it uses cdbs ...
I don't dare to work on it just by myself ... somebody else interested too?

Alessio?

mira

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


Re: Ardour 3

2011-09-27 Thread info
Hi,

I agree with Robin, Paul Davis has been explicitly clear on this, I'm
curious as to why there is any packaging of Ardour3 required when it is
now distributed by Paul Davis himself as a universal Linux standalone
binary? Unfortunately various distribution packaging problems (not
necessarily Debian) over the years have played a part in these binary
bundles being created in the first place.

I personally asked about Ardour 3 alphas being included in AV Linux 5.0
and was told in no uncertain terms that A3 alphas or beta were to be
distributed.

Just thought I'd pass that along.

Regards -GLEN


 On Sep 27, 2011, at 7:42 PM, Jaromír Mikeš wrote:

 2011/9/27 Reinhard Tartler siret...@tauware.de:
 On Di, Sep 27, 2011 at 14:25:32 (CEST), Jaromír Mikeš wrote:

 I am just curious if exists in team plan to introduce Ardour 3 alpas
 in experimental?

 No, but I'd say If you feel like doing it, go for it!

 Hmm ... Ardour is very complex package and it uses cdbs ...
 I don't dare to work on it just by myself ... somebody else interested
 too?

 Alessio?

 mira


 Please check Paul Davis' Note on packaging ardour3. It has been a
 recurring subject on the linux-audio-dev and ardour-dev email lists.
 In short: No Linux distribution should be packaging Ardour3 alpha
 releases.

 Certainly it is not illegal do to so but you'll annoy the developers when
 packaging it at this point in time for various reasons.

 This may change with upcoming beta1 - but ask on IRC #ardour or the
 ardour-dev email list before starting that endeavour.

 best,
 robin


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




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


Re: Ardour 3

2011-09-27 Thread info
My apologies,

In my previous comment I meant to say Ardour3 alphas and betas were NOT to
be distributed. Just to clarify...

-GLEN


 On Sep 27, 2011, at 7:42 PM, Jaromír Mikeš wrote:

 2011/9/27 Reinhard Tartler siret...@tauware.de:
 On Di, Sep 27, 2011 at 14:25:32 (CEST), Jaromír Mikeš wrote:

 I am just curious if exists in team plan to introduce Ardour 3 alpas
 in experimental?

 No, but I'd say If you feel like doing it, go for it!

 Hmm ... Ardour is very complex package and it uses cdbs ...
 I don't dare to work on it just by myself ... somebody else interested
 too?

 Alessio?

 mira


 Please check Paul Davis' Note on packaging ardour3. It has been a
 recurring subject on the linux-audio-dev and ardour-dev email lists.
 In short: No Linux distribution should be packaging Ardour3 alpha
 releases.

 Certainly it is not illegal do to so but you'll annoy the developers when
 packaging it at this point in time for various reasons.

 This may change with upcoming beta1 - but ask on IRC #ardour or the
 ardour-dev email list before starting that endeavour.

 best,
 robin


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




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


Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread Reinhard Tartler
On Di, Sep 27, 2011 at 18:57:14 (CEST), Jonas Smedegaard wrote:

 On 11-09-27 at 06:49pm, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:51 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:
 
  The following commit has been merged in the master branch:
  commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
  Author: IOhannes m zmölnig zmoel...@iem.at
  Date:   Tue Sep 27 17:13:52 2011 +0200
 
  preserve autom4te.cache
  
  which is in the upstream tarball though it never should have gone 
  there...

 [snip]

 Why not deleting it in the clean target and remove it from the 
 packaging (i.e., 'master') branch?

 IMO a noble ideal to preserve upstream sources as pristine as possible.

we do that in the upstream branch, and use pristine-tar.

Deleting it from the branch worked best for me in the past and avoids
annoying warnings from git.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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

Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread Reinhard Tartler
On Di, Sep 27, 2011 at 18:59:44 (CEST), IOhannes m zmoelnig wrote:

 On 2011-09-27 18:49, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 17:30:51 (CEST), 
 zmoelnig-gu...@users.alioth.debian.org wrote:

 The following commit has been merged in the master branch:
 commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
 Author: IOhannes m zmölnig zmoel...@iem.at
 Date:   Tue Sep 27 17:13:52 2011 +0200

 preserve autom4te.cache

 which is in the upstream tarball though it never should have gone 
 there...


 Why not deleting it in the clean target and remove it from the packaging
 (i.e., 'master') branch?

 it get's deleted by dh_clean

 deleting is probably the best thing, the question is how to achieve that
 here:
 - strip the autom4te.cache from the pristine-tar import?

pristine-tar imports the 'upstream' branch, not master. Don't delete
from 'upstream', only from 'master'.

 - patch the offending sources away?

I don't understand this? please elaborate.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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

Why are we using a custom Git Commit hook

2011-09-27 Thread Reinhard Tartler
Hi,

I noticed that our packages use a custom git-commit-hook that is
installed in /git/pkg-multimedia/git-commit-notice. However, I also
noticed that other teams seem to use /usr/local/bin/git-commit-notice. I
wonder why don't use the system wide one too. For reference see the diff
below:

--- /git/pkg-multimedia/git-commit-notice   2010-09-04 19:49:26.0 
+
+++ /usr/local/bin/git-commit-notice2011-05-23 10:26:34.116049606 +
@@ -138,22 +138,19 @@
 
# Check if we've got anyone to send to
if [ -z $recipients ]; then
-   echo 2 *** hooks.recipients is not set so no email will be 
sent
+   echo 2 *** hooks.mailinglist is not set so no email will be 
sent
echo 2 *** for $refname update $oldrev-$newrev
exit 0
fi
 
# Email parameters
-   # For ease of mailing list management, we use the pusher's ID
-   # as committer
-   committer=$(id -un)@users.alioth.debian.org
-   if [ -z $committer ] ; then
-   echo 2 Could not identify username, not sending email
-   exit 1
-   fi
+   # The committer will be obtained from the latest existing rev; so
+   # for a deletion it will be the oldrev, for the others, then newrev
+   committer=$(git show --pretty=full -s $rev |
+   perl -M'Encode qw/encode/' -Mencoding=utf-8 -n -e 'print if 
(s{^Commit: (.*)( .*)}{encode(MIME-Q, \.$1.\) . $2}e);')
# The email subject will contain the best description of the ref
# that we can build from the parameters
-   describe=$(git describe --tags $rev 2/dev/null)
+   describe=$(git describe $rev 2/dev/null)
if [ -z $describe ]; then
describe=$rev
fi
@@ -177,7 +174,6 @@
fi
for merged in $(git rev-parse --not --branches | grep -v $(git 
rev-parse $refname) | git rev-list --reverse --stdin $oldrev..$newrev); do
 
-   describe=$(git log --pretty=%s $merged^..$merged)
generate_commit_log $merged | $sendmail
 
if [ -n $cia_project ]; then
@@ -204,8 +200,7 @@
echo Reply-To: $reply_to
fi
cat -EOF
-   Date: `date --rfc-2822`
-   Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname, 
${change_type}d. $describe
+   Subject: ${EMAILPREFIX}$subjectdesc $refname_type, $short_refname, 
${change_type}d. $describe
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Git-Refname: $refname
@@ -229,14 +224,8 @@
 generate_commit_log()
 {
rev=$1
-   # Again, use the pushers ID instead of committe
-   committer=$(id -un)@users.alioth.debian.org
-
-   if [ $GIT_DIR = . ] ; then
-   repo=$(basename $(pwd) .git)
-   else
-   repo=$(basename $GIT_DIR .git)
-   fi
+   committer=$(git show --pretty=full -s $rev | 
+   perl -M'Encode qw/encode/' -Mencoding=utf-8 -n -e 'print if 
(s{^Commit: (.*)( .*)}{encode(MIME-Q, \.$1.\) . $2}e);')
 
cat -EOF
From: $committer
@@ -247,7 +236,7 @@
echo Reply-To: $reply_to
fi
cat -EOF
-   Subject: ${EMAILPREFIX}$repo/$short_refname: $describe
+   Subject: ${EMAILPREFIX}$subjectdesc $refname_type, $short_refname, 
${change_type}d. $describe
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Git-Refname: $refname
@@ -670,6 +659,11 @@
 envelopesender=$(git repo-config hooks.envelopesender)
 cia_project=$(git repo-config hooks.cia-project)
 sendmail=/usr/sbin/sendmail -t
+subjectdesc=$(git repo-config hooks.subjectdesc)
+
+if [ -z $subjectdesc ]; then
+   subjectdesc=$projectdesc
+fi
 
 # --- Main loop
 # Allow dual mode: run from the command line just like the update hook, or if


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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


Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread Reinhard Tartler
On Di, Sep 27, 2011 at 20:50:01 (CEST), Jonas Smedegaard wrote:

 On 11-09-27 at 08:33pm, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 18:57:14 (CEST), Jonas Smedegaard wrote:
 
  On 11-09-27 at 06:49pm, Reinhard Tartler wrote:
  On Di, Sep 27, 2011 at 17:30:51 (CEST), 
  zmoelnig-gu...@users.alioth.debian.org wrote:
  
   The following commit has been merged in the master branch:
   commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
   Author: IOhannes m zmölnig zmoel...@iem.at
   Date:   Tue Sep 27 17:13:52 2011 +0200
  
   preserve autom4te.cache
   
   which is in the upstream tarball though it never should have 
   gone there...
 
  [snip]
 
  Why not deleting it in the clean target and remove it from the 
  packaging (i.e., 'master') branch?
 
  IMO a noble ideal to preserve upstream sources as pristine as possible.
 
 we do that in the upstream branch, and use pristine-tar.
 
 Deleting it from the branch worked best for me in the past and avoids
 annoying warnings from git.

 branch is a VCS term.

 What I am talking about is not (only) to preserve (when possible) 
 pristine upstream source in VCS, but also as shipped source package.

 I.e. to not remove it from the packaging as you explicitly seem to 
 suggest.

Ah, you are splitting hairs. No, that's not what I've meant with that.

At least, we seem to agree on what to do. :-)


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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

Re: [SCM] pd-zexy/master: preserve autom4te.cache

2011-09-27 Thread Jonas Smedegaard
On 11-09-27 at 09:55pm, Reinhard Tartler wrote:
 On Di, Sep 27, 2011 at 20:50:01 (CEST), Jonas Smedegaard wrote:
 
  On 11-09-27 at 08:33pm, Reinhard Tartler wrote:
  On Di, Sep 27, 2011 at 18:57:14 (CEST), Jonas Smedegaard wrote:
  
   On 11-09-27 at 06:49pm, Reinhard Tartler wrote:
   On Di, Sep 27, 2011 at 17:30:51 (CEST), 
   zmoelnig-gu...@users.alioth.debian.org wrote:
   
The following commit has been merged in the master branch:
commit ce6b55f7d5eaed7c6d805e920cc93607a33e408c
Author: IOhannes m zmölnig zmoel...@iem.at
Date:   Tue Sep 27 17:13:52 2011 +0200
   
preserve autom4te.cache

which is in the upstream tarball though it never should 
have gone there...
  
   [snip]
  
   Why not deleting it in the clean target and remove it from the 
   packaging (i.e., 'master') branch?
  
   IMO a noble ideal to preserve upstream sources as pristine as 
   possible.
  
  we do that in the upstream branch, and use pristine-tar.
  
  Deleting it from the branch worked best for me in the past and 
  avoids annoying warnings from git.
 
  branch is a VCS term.
 
  What I am talking about is not (only) to preserve (when possible) 
  pristine upstream source in VCS, but also as shipped source package.
 
  I.e. to not remove it from the packaging as you explicitly seem to 
  suggest.
 
 Ah, you are splitting hairs. No, that's not what I've meant with that.

Ah, when we disagree on tiny details, _I_ am the one splitting hair?!?



 At least, we seem to agree on what to do. :-)

Oh, we do?  Great! :-)


 - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Git post-receive hook updated

2011-09-27 Thread Reinhard Tartler

Hi,

I've update (most) pkg-multimedia post-receive hooks to read like this:

#!/bin/sh
exec /git/pkg-multimedia/bin/common-post-receive-hook

I.e., I've written a common hook file. From that hook file, I'm calling
the /git/pkg-multimedia/git-commit-notice scripts (cf. my previous mail
on that matter) as well as
/home/groups/pet/PET2/pkg-multimedia/pet-git-helper in order to keep our
PET instance at http://pet.debian.net/pkg-multimedia/pet.cgi up to date.

Unfortunately, I couldn't update the following repositories' hooks due to
insufficient permissions. Dear Alioth admins, could you please fix the
permissions of all git repositories of pkg-multimedia to be group
writeable? Besides, I understand from alioth FAQ 4.4 that there should
be cronjob that fixes permissions. Is that correct and if yes, why
doesn't it work for pkg-multimedia?

Thanks in advance!

aj-snapshot.git/hooks/post-receive
aliki.git/hooks/post-receive
avidemux.git/hooks/post-receive
azr3-jack.git/hooks/post-receive
blender.git/hooks/post-receive
dino.git/hooks/post-receive
drc.git/hooks/post-receive
gxtuner.git/hooks/post-receive
jack-stdio.git/hooks/post-receive
jalv.git/hooks/post-receive
jmeters.git/hooks/post-receive
jnoisemeter.git/hooks/post-receive
libaacs.git/hooks/post-receive
libdssialsacompat.git/hooks/post-receive
libdvdcss.git/hooks/post-receive
lilv.git/hooks/post-receive
machina.git/hooks/post-receive
mp3fs.git/hooks/post-receive
mpd-sima.git/hooks/post-receive
mudita24.git/hooks/post-receive
muse.git/hooks/post-receive
openni.git/hooks/post-receive
osceleton.git/hooks/post-receive
pd-flite.git/hooks/post-receive
pd-pdstring.git/hooks/post-receive
petri-foo.git/hooks/post-receive
primesense-kinect-sensor.git/hooks/post-receive
primesense-nite-nonfree.git/hooks/post-receive
qsynth.git/hooks/post-receive
so-synth-lv2.git/hooks/post-receive
suil.git/hooks/post-receive
yafaray-blender2.5-exporter.git/hooks/post-receive
yafaray.git/hooks/post-receive


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

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


Re: Git post-receive hook updated

2011-09-27 Thread Jonas Smedegaard
On 11-09-27 at 11:48pm, Reinhard Tartler wrote:

 I've update (most) pkg-multimedia post-receive hooks to read like this:
 
 #!/bin/sh
 exec /git/pkg-multimedia/bin/common-post-receive-hook

Cool!


 - 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/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Why are we using a custom Git Commit hook

2011-09-27 Thread Felipe Sateler
On Tue, Sep 27, 2011 at 15:42, Reinhard Tartler siret...@tauware.de wrote:
 Hi,

 I noticed that our packages use a custom git-commit-hook that is
 installed in /git/pkg-multimedia/git-commit-notice. However, I also
 noticed that other teams seem to use /usr/local/bin/git-commit-notice. I
 wonder why don't use the system wide one too. For reference see the diff
 below:

I will comment on the patch. Beware that I'm using gmail's web
interface so the patch will most likely get garbled.


 --- /git/pkg-multimedia/git-commit-notice       2010-09-04 19:49:26.0 
 +
 +++ /usr/local/bin/git-commit-notice    2011-05-23 10:26:34.116049606 +
 @@ -138,22 +138,19 @@

        # Check if we've got anyone to send to
        if [ -z $recipients ]; then
 -               echo 2 *** hooks.recipients is not set so no email will be 
 sent
 +               echo 2 *** hooks.mailinglist is not set so no email will 
 be sent

This I have no idea. Probably a bugfix in the upstream script.

                echo 2 *** for $refname update $oldrev-$newrev
                exit 0
        fi

        # Email parameters
 -       # For ease of mailing list management, we use the pusher's ID
 -       # as committer
 -       committer=$(id -un)@users.alioth.debian.org
 -       if [ -z $committer ] ; then
 -               echo 2 Could not identify username, not sending email
 -               exit 1
 -       fi
 +       # The committer will be obtained from the latest existing rev; so
 +       # for a deletion it will be the oldrev, for the others, then newrev
 +       committer=$(git show --pretty=full -s $rev |
 +               perl -M'Encode qw/encode/' -Mencoding=utf-8 -n -e 'print if 
 (s{^Commit: (.*)( .*)}{encode(MIME-Q, \.$1.\) . $2}e);')

THe above change was suggested by Loïc. The commits list is moderated
to avoid spam. I changed the script to use the alioth user of the
pusher as the sender, so that they can be whitelisted and avoid having
to manually approve them.

        # The email subject will contain the best description of the ref
        # that we can build from the parameters
 -       describe=$(git describe --tags $rev 2/dev/null)
 +       describe=$(git describe $rev 2/dev/null)
        if [ -z $describe ]; then
                describe=$rev
        fi
 @@ -177,7 +174,6 @@
                fi
                for merged in $(git rev-parse --not --branches | grep -v $(git 
 rev-parse $refname) | git rev-list --reverse --stdin $oldrev..$newrev); do

 -                       describe=$(git log --pretty=%s $merged^..$merged)
                        generate_commit_log $merged | $sendmail

                        if [ -n $cia_project ]; then
 @@ -204,8 +200,7 @@
                echo Reply-To: $reply_to
        fi
        cat -EOF
 -       Date: `date --rfc-2822`
 -       Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname, 
 ${change_type}d. $describe
 +       Subject: ${EMAILPREFIX}$subjectdesc $refname_type, $short_refname, 
 ${change_type}d. $describe
        MIME-Version: 1.0
        Content-Type: text/plain; charset=UTF-8
        X-Git-Refname: $refname
 @@ -229,14 +224,8 @@
  generate_commit_log()
  {
        rev=$1
 -       # Again, use the pushers ID instead of committe
 -       committer=$(id -un)@users.alioth.debian.org
 -
 -       if [ $GIT_DIR = . ] ; then
 -               repo=$(basename $(pwd) .git)
 -       else
 -               repo=$(basename $GIT_DIR .git)
 -       fi
 +       committer=$(git show --pretty=full -s $rev |
 +               perl -M'Encode qw/encode/' -Mencoding=utf-8 -n -e 'print if 
 (s{^Commit: (.*)( .*)}{encode(MIME-Q, \.$1.\) . $2}e);')

        cat -EOF
        From: $committer
 @@ -247,7 +236,7 @@
                echo Reply-To: $reply_to
        fi
        cat -EOF
 -       Subject: ${EMAILPREFIX}$repo/$short_refname: $describe
 +       Subject: ${EMAILPREFIX}$subjectdesc $refname_type, $short_refname, 
 ${change_type}d. $describe

This and the above are to send more meaningful subjects in the commit messages.

        MIME-Version: 1.0
        Content-Type: text/plain; charset=UTF-8
        X-Git-Refname: $refname
 @@ -670,6 +659,11 @@
  envelopesender=$(git repo-config hooks.envelopesender)
  cia_project=$(git repo-config hooks.cia-project)
  sendmail=/usr/sbin/sendmail -t
 +subjectdesc=$(git repo-config hooks.subjectdesc)
 +
 +if [ -z $subjectdesc ]; then
 +       subjectdesc=$projectdesc
 +fi

This I don't know about.


-- 

Saludos,
Felipe Sateler

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

Re: Ardour 3

2011-09-27 Thread Adrian Knoth
On 09/27/11 14:25, Jaromír Mikeš wrote:

 Hi all,

Hi!

 I am just curious if exists in team plan to introduce Ardour 3 alpas
 in experimental?

I once started:

   http://anonscm.debian.org/gitweb/?p=pkg-multimedia/ardour3.git;a=summary

But as we just learned, there's no point in doing that atm.


I used it mainly to keep track with upstream, so that we're ready to
roll our own once the alpha/beta phase is over.

So if you like, feel free to polish/update it a bit. I've sent an e-mail
to pkg-mmm earlier this year about open issues on that package.


Cheers

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


Bug#643024: libffado2: jackd can't start with libffado version 2.0.99+svn1995-1

2011-09-27 Thread Adrian Knoth
On 09/26/11 17:54, Gilles Crevecoeur wrote:

 Package: libffado2
 Version: 2.0.99+svn1995-1
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,

Hi!

 When I have tried to start jackd the following lines was printed :

Confirmed.

 So, I have tried to compile my own version, and thus I have installed the
 binutils-gold package for this, with the same results.

Confirmed, binutils-gold no longer is a working workaround.

 I guess, it seems to come from the new upstream version of libffado.

No, it doesn't. If you checkout svn 1994 instead of 1995, it will also
fail with binutils-gold.

We have replacement code ready (a new debug module).


I'll update the package as soon as we have a working upstream version.


HTH and thanks for reporting



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