[PATCH] waf: Fix the build on openbsd

Jelmer Vernooij jelmer at samba.org
Fri Feb 13 16:09:27 MST 2015

On Wed, Feb 11, 2015 at 09:56:34PM +0100, Michael Adam wrote:
> On 2015-02-11 at 18:05 +0100, Jelmer Vernooij wrote:
> > On Wed, Feb 11, 2015 at 11:08:15AM +0100, Volker Lendecke wrote:
> > > On Tue, Feb 10, 2015 at 01:18:56PM -0800, Jeremy Allison wrote:
> > > 
> > > > Well that suggestion was based on the assumption
> > > > that we had decided on *not* changing wafadmin.
> > > 
> > > From my point of view this decision is wrong. I've given arguments for
> > > my opinion abundantly in this thread, the main ones are traceability of
> > > changes with version control and clarity of code. Also, if I was about to
> > > import a new version of waf, I *wanted* git to complain about conflicts,
> > > I would have no chance to scan all of wafsamba/wscript/wscript_build
> > > for potential binary patches.
> > 
> > Aside from the discussion of how to carry local changes, why do we need to
> > carry local changes in this situation at all?
> > 
> > We introduced this bug by sending a patch to upstream,
> Well in fact, we introduced build breakage on openbsd
> by simply applying a patch from upstream that was supposed
> to fix build problems on openbsd... We did not submit
> anything to upstream in this case.

AFAICT we were the reason upstream changed this code to improve
OpenBSD support. It seems only fair to also go through upstream
when we find out that fix is not correct.

> > and so it seems reasonable to also help fix the regression
> > caused by that patch there.
> If we find regressions, it does in fact generally not seem
> unreasonable to contribute back. But of course these upstream
> patches were in the first place backported from a newer
> upstream version, which complicates the situation slightly.
> And one of the problems discussed in this thread is that
> some people had problems getting the attention of upstream
> at all.
It would be great if those people could link some specific
bugs where this was the case. :-) This particular issue was not
forwarded upstream AFAICT?

> > As far as I know we don't want (or at least strongly prefer not) to have
> > Samba-specific changes in our copies of e.g. zlib or popt. Why is waf any
> > different?
> Very generally, it probably is not or should not be.
> On the other hand, waf is nothing that is found in the
> distributions like zlib or popt and where our copy is
> needed only on some platforms. Also I think that we do
> find a relatively high rate of problems we need to patch
> in waf proper or patch around in wafsamba.
So far we've managed to eventually get all patches upstream,
so it would be nice if we could continue that.

> The preferred solution would be to have them fixed in upstream
> of course if they are proper waf bugs, but it takes some time,
> and I don't know if waf 1.5 gets any patches at all any more.
waf 1.5 is still getting patches; Thomas has kindly backported
a number of the bug fixes that were relevant to samba to 1.5.

> Thomas also had proposed a patch(set) some time ago to convert
> samba to waf 1.8, which would be much better supported, and I
> spent several hours trying it, but it did not work at all for me.
> And the occurrences when we met on irc were so rare and short
> that I gave up on it again. Since he does not seem to do mailing
> lists, but only irc it is slightly difficult to keep track of
> these things. So what to do?
I think we usually manage to get a hold of him. Filing a bug
and then pinging later seems like the best way to do so.



Jelmer Vernooij <jelmer at samba.org> - https://jelmer.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150214/48b33981/attachment.pgp>

More information about the samba-technical mailing list