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.
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?
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.