Il giorno Mon, 26 Apr 2010 18:39:40 +0200
Jonas Smedegaard <> 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;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,

 :  :' :   Luca Falavigna <>
 `.  `'

Attachment: signature.asc
Description: PGP signature

pkg-multimedia-maintainers mailing list

Reply via email to