[PATCHv2 1-14/14] Re: Disabling Python Modules

[Ian Stakenvicius]

On 06/03/17 10:10 AM, Ian Stakenvicius wrote:
> On 06/03/17 04:47 AM, Andrew Bartlett wrote:
>> On Tue, 2017-02-28 at 09:49 -0500, Ian Stakenvicius wrote:
>>> On 23/02/17 10:44 AM, Ian Stakenvicius wrote:
>>>> On 21/02/17 05:13 PM, Andrew Bartlett wrote:
>>>>> On Tue, 2017-02-21 at 00:01 -0500, Ian Stakenvicius wrote:
>>>>>>
>>>>>>
>>>>>> So since python isn't actually required, something along the
>>>>>> lines of
>>>>>> this should also suffice? (note, haven't tested yet)
>>>>>>
>>>>>>
>>>>>> diff --git a/ctdb/wscript b/ctdb/wscript
>>>>>> index 13384c8..5aac7eb 100644
>>>>>> --- a/ctdb/wscript
>>>>>> +++ b/ctdb/wscript
>>>>>> @@ -107,8 +107,8 @@ def configure(conf):
>>>>>>      if conf.env.standalone_ctdb:
>>>>>>          conf.SAMBA_CHECK_PERL(mandatory=True)
>>>>>>
>>>>>> -        conf.SAMBA_CHECK_PYTHON(mandatory=True,
>>>>>> version=(2,5,0))
>>>>>> -        conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=True)
>>>>>> +        conf.SAMBA_CHECK_PYTHON(mandatory=False,
>>>>>> version=(2,5,0))
>>>>>> +        conf.SAMBA_CHECK_PYTHON_HEADERS(mandatory=False)
>>>>>>
>>>>>>      if conf.CHECK_FOR_THIRD_PARTY():
>>>>>>          conf.RECURSE('third_party/popt')
>>>>>
>>>>> Can you have a practical play and ensure we not only build ctdb,
>>>>> but it
>>>>> doesn't have any of the bundled libs producing python bindings?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Bartlett
>>>>>
>>>>>
>>>>>
>>>>
>>>> I've updated the PR with this solution (and fixed a conflict
>>>> against
>>>> some recent talloc/wscript changes), and am testing ctdb standalone
>>>> builds locally now. A 'find' run within the installation prefix
>>>> location during the autobuild test finds no python bindings (or
>>>> anything else python-related) at all, so I would count this fix as
>>>> successful.
>>>>
>>>
>>> Hey all -- Travis is green on this and as far as i've seen there
>>> haven't been any additional issues reported; is there anything left
>>> to
>>> do in preparation for pushing?  Should I git-format-patch and attach
>>> here again for final review or is the github PR sufficient?
>>
>> A git-format-patch always gets more attention.  
>>
>> If you could rebase on my py3 branch (or provide a set each way), that
>> would help, because absent any more issues I want to merge that first,
>> as it is the more complex.
>>
>> I thank you for your incredible patience in this matter.
>>
>> Andrew Bartlett
>>
> 
> No problem.
> 
> FYI, I'm getting a conflict in lib/talloc/wscript , where it looks
> like your patchset dropped the checks for the system copy of talloc
> when it's not being build standalone -- is it OK to drop this?  Gentoo
> Linux in particular -always- builds samba against system talloc, I
> expect other distros do the same..
> 
> Wouldn't tevent need a check that is similar to what was done in
> lib/ldb/wscript?
> 

Hey Andrew, speaking of lib/ldb , autobuild tests are returning an
error related to a conflict in the ordering of the ldb and pyldb_util
builds:


Checking project rules ...
Target 'pyldb-util.cpython-34m' in build group 'generators' depends on
target 'ldb' from later build group 'main'
Bad group ordering - aborting


This doesn't look to have anything to do with the changes my
disable-python patchset performs on top of your py3 patchset, but if
i'm wrong please let me know.  My code is in my 'disable-python-py3'
branch and the Travis-CI results are on PR#82




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170306/4bc83a24/signature.sig>