Re: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Luca Falavigna
Hi!

Il 25/04/2010 17.33, Jonas Smedegaard ha scritto:
  jack-audio-connection-kit (1.9.5~dfsg-1) unstable; urgency=low
  .
[ Jonas Smedegaard ]
* Use system waf. Build-depend on waf.
- Strip binary waf file (too risky to blindly invoke, and too much
  hassle unpacking and inspecting properly).

I'm trying to remove waf from Debian (see [1]), and this package is the
last one still build-depending on it. Could you please undo this change?

Regards,

[1] http://lists.debian.org/debian-devel/2010/02/msg00714.html

-- 

  .''`.
 : :' :   Luca Falavigna dktrkr...@debian.org
 `. `'
   `-



signature.asc
Description: OpenPGP 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Jonas Smedegaard

Hi Luca,

On Mon, Apr 26, 2010 at 05:52:34PM +0200, Luca Falavigna wrote:

Il 25/04/2010 17.33, Jonas Smedegaard ha scritto:

 jack-audio-connection-kit (1.9.5~dfsg-1) unstable; urgency=low
 .
   [ Jonas Smedegaard ]
   * Use system waf. Build-depend on waf.
   - Strip binary waf file (too risky to blindly invoke, and too much
 hassle unpacking and inspecting properly).


I'm trying to remove waf from Debian (see [1]), and this package is the 
last one still build-depending on it. Could you please undo this 
change?


I want to, just haven't figured out yet a way to use the shipped waf in 
a way that I can trust: I really do not want to blindly execute an 
upstream-shipped binary chunk.  yes, I am aware that it is not really a 
binary blob but a self-extracting tarball of some kind, just haven't 
figured out a way to script unpacking it and verifying if its content is 
sane.


Would you perhaps happen to know of an elegant approach?  Or maybe you 
have a list of prior users of your waf package so that I can go examine 
those myself (and hope that what I find is not horrible relaxed 
execution everywhere)?



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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Luca Falavigna
Il giorno Mon, 26 Apr 2010 18:39:40 +0200
Jonas Smedegaard jo...@jones.dk ha scritto:

 I want to, just haven't figured out yet a way to use the shipped waf in 
 a way that I can trust: I really do not want to blindly execute an 
 upstream-shipped binary chunk.  yes, I am aware that it is not really a 
 binary blob but a self-extracting tarball of some kind, just haven't 
 figured out a way to script unpacking it and verifying if its content is 
 sane.

Upstream does not even provide a way to unpack bundle bzip2 archive,
that's another weak point of it. It creates a .waf-version-something
directory in your root folder (e.g, jack-audio-connection-kit has 
.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in
http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree)
There you will wind wafadmin directory (which has .py files waf relies
on to run) and t.bz2 (which ships some environment black magic).

 Would you perhaps happen to know of an elegant approach?  Or maybe you 
 have a list of prior users of your waf package so that I can go examine 
 those myself (and hope that what I find is not horrible relaxed 
 execution everywhere)?

No, it's waf design fault. Elegant approach is providing a system-wide
installation package, but upstream doesn't like it and blames us
instead for his bugs. That's crazy! :)

You could try this approach if you feel so (I could provide a patch):
* run ./waf --version (to create .waf-version-something dir)
* move .waf-version-something/wafadmin to $(CURDIR)
* remove .waf-version-something
* do some sed to remove bundle bzip2 archive from waf, and store the
  remaining bits to waf-light script
* patch waf-light to understand wafadmin directory in $(CURDIR)

Please let me know,
Thanks!

-- 
  .''`.
 :  :' :   Luca Falavigna dktrkr...@debian.org
 `.  `'
   `-


signature.asc
Description: 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Jonas Smedegaard

On Mon, Apr 26, 2010 at 08:37:07PM +0200, Luca Falavigna wrote:

Il giorno Mon, 26 Apr 2010 18:39:40 +0200
Jonas Smedegaard jo...@jones.dk ha scritto:

I want to, just haven't figured out yet a way to use the shipped waf 
in a way that I can trust: I really do not want to blindly execute an 
upstream-shipped binary chunk.  yes, I am aware that it is not really 
a binary blob but a self-extracting tarball of some kind, just 
haven't figured out a way to script unpacking it and verifying if its 
content is sane.


Upstream does not even provide a way to unpack bundle bzip2 archive, 
that's another weak point of it. It creates a .waf-version-something 
directory in your root folder (e.g, jack-audio-connection-kit has 
.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in 
http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree) 
There you will wind wafadmin directory (which has .py files waf relies 
on to run) and t.bz2 (which ships some environment black magic).


Would you perhaps happen to know of an elegant approach?  Or maybe 
you have a list of prior users of your waf package so that I can go 
examine those myself (and hope that what I find is not horrible 
relaxed execution everywhere)?


No, it's waf design fault. Elegant approach is providing a system-wide 
installation package, but upstream doesn't like it and blames us 
instead for his bugs. That's crazy! :)


You could try this approach if you feel so (I could provide a patch):
* run ./waf --version (to create .waf-version-something dir)
* move .waf-version-something/wafadmin to $(CURDIR)
* remove .waf-version-something
* do some sed to remove bundle bzip2 archive from waf, and store the
 remaining bits to waf-light script
* patch waf-light to understand wafadmin directory in $(CURDIR)

Please let me know,
Thanks!


A patch would be awesome!

I notice several multimedia projects jumping on the waf craze, so fear 
that we cannot simply close our eyes to this issue, and I refuse to 
trust invoking black magic voodoo as part of standard build routines.


When figuring out a full set of routines to unpack, verify and use waf 
indirectly, I strongly consider adding a CDBS module to handle it - well 
aware that I might trigger the wrath of upstream waf developers in doing 
so... :-/



 - 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Jonas Smedegaard

[sent again, cc Luca this time]

On Mon, Apr 26, 2010 at 08:37:07PM +0200, Luca Falavigna wrote:

Il giorno Mon, 26 Apr 2010 18:39:40 +0200
Jonas Smedegaard jo...@jones.dk ha scritto:

I want to, just haven't figured out yet a way to use the shipped waf 
in a way that I can trust: I really do not want to blindly execute an 
upstream-shipped binary chunk.  yes, I am aware that it is not really 
a binary blob but a self-extracting tarball of some kind, just 
haven't figured out a way to script unpacking it and verifying if its 
content is sane.


Upstream does not even provide a way to unpack bundle bzip2 archive, 
that's another weak point of it. It creates a .waf-version-something 
directory in your root folder (e.g, jack-audio-connection-kit has 
.waf-1.5.0-8e39a4c1c16303c1e8f010bf330305f6, as you can also see in 
http://git.debian.org/?p=pkg-multimedia/jack-audio-connection-kit.git;a=tree) 
There you will wind wafadmin directory (which has .py files waf relies 
on to run) and t.bz2 (which ships some environment black magic).


Would you perhaps happen to know of an elegant approach?  Or maybe 
you have a list of prior users of your waf package so that I can go 
examine those myself (and hope that what I find is not horrible 
relaxed execution everywhere)?


No, it's waf design fault. Elegant approach is providing a system-wide 
installation package, but upstream doesn't like it and blames us 
instead for his bugs. That's crazy! :)


You could try this approach if you feel so (I could provide a patch):
* run ./waf --version (to create .waf-version-something dir)
* move .waf-version-something/wafadmin to $(CURDIR)
* remove .waf-version-something
* do some sed to remove bundle bzip2 archive from waf, and store the
 remaining bits to waf-light script
* patch waf-light to understand wafadmin directory in $(CURDIR)

Please let me know,
Thanks!


A patch would be awesome!

I notice several multimedia projects jumping on the waf craze, so fear 
that we cannot simply close our eyes to this issue, and I refuse to 
trust invoking black magic voodoo as part of standard build routines.


When figuring out a full set of routines to unpack, verify and use waf 
indirectly, I strongly consider adding a CDBS module to handle it - well 
aware that I might trigger the wrath of upstream waf developers in doing 
so... :-/



  - 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: Accepted jack-audio-connection-kit 1.9.5~dfsg-1 (source amd64)

2010-04-26 Thread Jonas Smedegaard

On Mon, Apr 26, 2010 at 11:44:49PM +0200, Luca Falavigna wrote:

Il giorno Mon, 26 Apr 2010 20:57:44 +0200
Jonas Smedegaard jo...@jones.dk ha scritto:


A patch would be awesome!


Here it is: http://people.debian.org/~dktrkranz/local_waf.patch
I tested it and package built. I didn't test if resulting binaries are
sane, and the same applies to the build log itself.

Keep in mind this is an untested, ugly hack ;)


I will not have time to look at it the upcoming days, but thanks a lot!

I don't mind it being ugly - I can tighten it up myself - just great to 
have a hack that (supposedly) works to work from :-D



 - Jonas

--
* Jonas Smedegaard - idealist  Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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