As you may know, Debian is kinda picky (not to say more rude words...) about source being provided, and waf tends to be a target for this..:-) As of now, the released tarballs provide some binary in buildtools/ for which the "source" is not directly provided. That may of course be debated as this can be *extracted* from the provided binary, but still. Jelmer Vernooij committed 4f4bce5301ffd8c12aed1b108affa1a75feefb67 in master to fix this. Could it be considered for 3.6.6? That would make our packagers life a lot easier than patching sources ourselves and it certainly has no impact as waf is not directly used in the build. Thanks a lot for considering this.
Cherry-picking fails: user@host:/data/git/samba/v3-6-test> git cherry-pick -x 4f4bce5301ffd8c12aed1b108affa1a75feefb67 Automatic cherry-pick failed. After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result with: git commit -c 4f4bce5301ffd8c12aed1b108affa1a75feefb67 Jelmer, can you please provide a patch for v3-6-test? Thanks!
Do we really support the waf build in 3.6? I was a bit confused to find autogen-waf.sh in v3-6-test/source3...
FWIW I didn't put this patch into 3.6 intentionally, but only into master. I agree that the right thing to do is to ship the unpacked source, since it is the preferred form of modification. That's why I fixed it in Git master. But we're not really using the waf build in Debian's 3.6 package, and I think unpacking the waf source for 3.6 is just noise. It's not something worth doing for older release series, especially if waf shipped but not used.
I still think this is a non-issue for an existing release like 3.6 which just ships waf but doesn't use it. Considering we're already working on 4.1 (which has a fix for this bug) and since Debian will ship 4.0 soon, I'm going to mark this as wontfix.