Re: Difficulties bringing waf15 updates into Samba (was:?Re:?[PATCH]?build scripts enhancements)

[Thomas Nagy]

On Sat, 27 Jun 2015 16:04:15 +0200, Michael Adam wrote:

> On 2015-06-27 at 10:54 +0200, Thomas Nagy wrote:
> > On Sat, 27 Jun 2015 01:30:15 +0200, Michael Adam wrote:
> > 
> > > On 2015-06-26 at 23:30 +0200, Thomas Nagy wrote:
> > > > On Fri, 26 Jun 2015 19:51:56 +1200, Andrew Bartlett wrote:
> > > > 
> > > > > On Fri, 2015-06-26 at 07:52 +0200, Thomas Nagy wrote:
> > > > > > On Fri, 26 Jun 2015 12:28:05 +1200, Andrew Bartlett wrote:
> > > > > > 
> > > > > > > On Fri, 2015-06-19 at 18:36 +0200, Thomas Nagy wrote:
> > > > > > > > Please apply the patches attached to this message and
> > > > > > > > update your Waf 1.5 copy from the source repository
> > > > > > > > https://github.com/waf-project/waf.waf15
> > > > > > > > 
> > > > > > > > Thomas
> > > > > > > 
> > > > > > > If we update waf again, we currently have to keep the
> > > > > > > local patch to python.py
> > > > > > > [...]
> > > > > > > Do you have any thoughts on a better way to do this?
> > > > > > > 
> > > > > > > We also can't import the whole waf tree, or carry it as a
> > > > > > > submodule, as that would bring in waf/doc/book which is
> > > > > > > non-free.  (Carrying that would cause all distributions,
> > > > > > > not just Debian, to then have to expunge it from our
> > > > > > > tarball, and may even cause issues with our obligations
> > > > > > > to our fiscal sponsor, which strictly requires that Samba
> > > > > > > distributes only free software).
> > > > > > 
> > > > > > Are the new git submodules in Samba causing some confusion?
> > > > > 
> > > > > We are talking about, but not using submodules.  We have
> > > > > started to mirror the git repos we would use, so we don't get
> > > > > caught out when external hosting services change. 
> > > > 
> > > > My bad, I did not understand the submodule situation. Yet, this
> > > > will not be a problem any longer; the files in attachment will
> > > > apply directly to the Samba tree. The last new ones represent
> > > > another important step towards the Waf 1.8 API usage.
> > > > 
> > > > > Either way, it would be most helpful if you could assist us with
> > > > > liberating the non-free docs.
> > > > 
> > > > I realize now that this would not only be useless - there has
> > > > never been any need to copy the BSD documentation to the Samba
> > > > tree - but also counter productive. The update script is very
> > > > coarse
> > > 
> > > Right, we could simply filter the docs from being
> > > copied. This does not seem to be a real issue to me.
> > > 
> > > > and has already lead to poorly reviewed modifications.
> > > 
> > > E.g. ?
> > 
> > See: https://lists.samba.org/archive/samba-technical/2015-June/108117.html
> 
> Yes, and? For all I can tell, this is about a poorly reviewed
> change in upstream waf if at all, but not in Samba. 

Yet the bug landed in Samba (no one uses the Waf 1.5 branch anymore). The standard double-review-by-team-members would probably have caught this.

> We have to
> keep that additional patch on top until it is merged upstream or
> or the regression is fixed upstream otherwise. Hence the request
> to fix it upstream so we can go with vanilla upstream again.
> Nothing strange on the Samba part I can see here. Completely
> reasonable.
> 
> We may want to go with vanilla upstream anyways and keep a
> list of add-on patches that we need until the get available
> upstream.

Well, this is absolutely fine to me. Just have the changes integrated so that we can continue the transition to Waf 1.8 and get rid of Samba's Waf 1.5 fork.

It would be a shame to have enhancements getting forgotten and bitrot again.

Thomas