[Pkg-xfce-devel] Bug#654468: Bug#645191: update on waf binary data
- Subject: [Pkg-xfce-devel] Bug#654468: Bug#645191: update on waf binary data
- From: corsac at debian.org (Yves-Alexis Perez)
- Date: Sun, 15 Apr 2012 09:18:00 +0200
- Message-id: <[🔎] 1334474280.10078.5.camel@scapa>
- In-reply-to: <20120323223922.GM17599@furrball.stateful.de>
- References: <20120309204207.GA2214@buster.stateful.de> <1331393459.2833.36.camel@scapa> <20120310174356.GX17599@furrball.stateful.de> <20120310181248.GY17599@furrball.stateful.de> <1331407441.2833.38.camel@scapa> <1331806314.2833.71.camel@scapa> <20120315193223.GC17599@furrball.stateful.de> <1331843214.2833.79.camel@scapa> <20120317014504.GE17599@furrball.stateful.de> <1331973390.24298.8.camel@scapa> <20120323223922.GM17599@furrball.stateful.de>
On ven., 2012-03-23 at 23:39 +0100, Carsten Hey wrote:
> I think we should drop ftpmaster from CC in further mails.
Maybe, since they don't seem to care about this. But considering they
decided to forbid waf, I think they should at least pay attention on how
people is trying to cope with their (imho bad) decision.
> The above was based on the assumption that these two two byte sequences
> are always the same because they can not occur in bzip2 compressed data
> for whatever reason. This assumption was wrong, waf creates the
> .tar.bz2 and then tries all possible two byte sequences until if finds
> some that do not occur in the .tar.bz2 and then sets the variables C1
> and C2 in the python waf template to these values. If we would do this
> in sed and co. we would need to parse python, which doesn't seem to be
> an option.
Well, parsing python might not be an option, but what about:
egrep -a "^C[1|2]='..'" waf
> > > http://bugs.debian.org/660193 (search for the string waf) contains
> > > snippets, based on what Tolimar pointed to in his mail, you just need to
> > > paste into the midori package and some additional notes. The remaining
> > > part is IMHO to document this in README.source. One thing I forgot to
> > > mention in my mail to #660193 is that the reason to remove the blob from
> > > the used waf script is to ensure that the unpacked waf source is used.
> > Well, in midori diff, I repack and ensure the new one and the old ones
> > are the same to be sure I don't do anything bad. Now indeed it could be
> > split in two parts, one run by maintainer, which would then hack in the
> > waf sources themeselves, and one at build time, which would pick the
> > extracted sources and make a new waf script.
> My point of all this was to provide an easy way to change the source
> code, but this can't be accomplished. You provided a way to extract the
> source to be able to review it, but not to change it.
> > And changing the way waf is used at built time is not supported and
> > might fail in bad ways too, so it's not really helpful to do things
> > *against* what advised by waf upstream.
> Users might not be advised to use an extracted source, but "#devs use
> $WAFDIR" (this is a comment in the waf script shipped in midori), so
> using the extracted wafadmin directory isn't unsupported at all.
> $WAFDIR is the directory in which the extracted wafadmin directory is
Well, when needed because we need to patch the build script (like for
the hppa issue) we can do that. In the usual case, don't touch it (and
don't break it).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part