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

[Michael Adam]

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

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150627/31b3165c/attachment.pgp>