[389-devel] Build failed in Jenkins: NIGHTLY #92

2017-09-27 Thread mareynol 
See 


--
[...truncated 6809 lines...]
  File "/usr/lib64/python2.7/threading.py", line 804, in __bootstrap_inner
self.run()
  File 
"
 line 51, in run
conn = self.openConnection(self.inst)
  File 
"
 line 45, in openConnection
server.open()
  File 
"
 line 1127, in open
raise e
SERVER_DOWN: {'\''desc'\'': "Can'\''t contact LDAP server"}

INFO:dirsrvtests.tests.suites.replication.cleanallruv_test:test_stress_clean: 
put master 4 into read-only mode...
CRITICAL:dirsrvtests.tests.suites.replication.cleanallruv_test:test_stress_clean:
 Failed to put master 4 into read-only mode: error Can'\''t contact LDAP server
 test_multiple_tasks_with_force 

topology_m4 = 

def test_multiple_tasks_with_force(topology_m4):
"""Check that multiple tasks with a '\''force'\'' option work properly

:ID: eb76a93d-8d1c-405e-9f25-6e8d5a781098
:feature: CleanAllRUV
:setup: Replication setup with four masters
:steps: 1. Stop master 3
2. Add a bunch of updates to master 4
3. Disable replication on master 4
4. Start master 3
5. Remove agreements to master 4 from other masters
6. Run a cleanallruv task on master 1 with a '\''force'\'' 
option '\''on'\''
7. Run one more cleanallruv task on master 1 with a 
'\''force'\'' option '\''off'\''
8. Check that everything was cleaned and no hanging tasks left
:expectedresults: Everything was cleaned and no hanging tasks left
"""

log.info('\''Running test_multiple_tasks_with_force...'\'')

# Stop master 3, while we update master 4, so that 3 is behind the 
other masters
topology_m4.ms["master3"].stop(timeout=10)

# Add a bunch of updates to master 4
m4_add_users = AddUsers(topology_m4.ms["master4"], 1500)
m4_add_users.start()
m4_add_users.join()

# Disable master 4
log.info('\''test_multiple_tasks_with_force: disable master 4...'\'')
>   topology_m4.ms["master4"].replica.disableReplication(DEFAULT_SUFFIX)

:817:
 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
:453:
 in disableReplication
mtents = self.conn.mappingtree.list(suffix=nsuffix)
:70:
 in list
filt)
:162:
 in inner
return f(*args, **kwargs)
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py:597: in search_s
return 
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
:162:
 in inner
return f(*args, **kwargs)
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py:590: in search_ext_s
msgid = 
self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
:162:
 in inner
return f(*args, **kwargs)
/usr/lib64/python2.7/site-packages/ldap/ldapobject.py:586: in search_ext
timeout,sizelimit,
:162:
 in inner
return f(*args, **kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
func = 
args = ('\''cn=mapping tree,cn=config'\'', 1, '\''(cn=dc=example,dc=com)'\'', 
None, 0, None, ...)
kwargs = {}, diagnostic_message_success = None
e = SERVER_DOWN({'\''desc'\'': "Can'\''t contact LDAP server"},)

def _ldap_call(self,func,*args,**kwargs):
  """
Wrapper method mainly for serializing calls into OpenLDAP libs
and trace logs
"""
  self._ldap_object_lock.acquire()
  if __debug__:
if self._trace_level>=1:
  self._trace_file.write('\''*** %s %s - %s\n%s\n'\'' % (
repr(self),
self._uri,

[389-devel] I'm back! Please review 49378

2017-09-27 Thread William Brown 
In typical fashion, I'm taking it slow on my return. Which means I have
two patches for review.

https://pagure.io/389-ds-base/issue/49378

https://pagure.io/389-ds-base/issue/raw/files/9f43e2d45818aa9adba4bea8a41f732c565a5e03510c24b984a808e2759cabbc-0001-Ticket-49378-server-init-fails.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Please review, /49372

2017-09-27 Thread William Brown 
Fixes to the filter optimiser,
https://pagure.io/389-ds-base/issue/49372


https://pagure.io/389-ds-base/issue/raw/files/60d7f2c562f8e4d2f2ac2b1a3dd610e0c482e3e20ef290b901260d40292a2dd6-0001-Ticket-49372-filter-optimisation-improvements-for-co.patch


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: revised: Ticket 49305 - Need to wrap atomic functions for certain platforms

2017-09-27 Thread William Brown 
On Tue, 2017-09-26 at 16:56 -0400, Mark Reynolds wrote:
> https://pagure.io/389-ds-base/issue/raw/files/7249aa3bf493cffef4c7e3a3eb843d2626b3a4e6c3802a3d246e0f5cfeafbb33-0001-Ticket-49305-Need-to-wrap-atomic-calls.patch
> 

Cool, so I think this patch touches on something that we need to
consider for the future - HPUX support.

Today, we can't test this, and we are really shooting blind in our
support for it.

I've already opened this ticket to drop 32bit:

https://pagure.io/389-ds-base/issue/49365

I think that for 1.4.x we should drop HPUX support also.

This would limit our support to:

* x86_64
* aarch64
* ppc64 (le)


And for OS this would put us at:

100% support of Linux
Partial support for FreeBSD
Someone is working on re-adding Solaris


With that in mind, I think that given this atomic wrapper exists *just*
for hpux perhaps this patch should *only* be in 1.3.7 branch? I'd like
to see it cleaned out/reverted for 1.4.x. perhaps. We have a lot of old
legacy support, and I think we really need to take a clearer line on
what we do and don't support, and we need to cleanup these shim layers
because they *do* add overheads. 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Re: PR_ASSERT problem

2017-09-27 Thread William Brown 
On Wed, 2017-09-20 at 14:30 +0200, Carsten Grzemba wrote:
> my build on OpenIndiana with the IllumOS provided NSPR cores on startup of 
> some commands:
> 
> $ pwdhash 
> Assertion failure: 0 == lock->notified.length, at 
> /jenkins/jobs/oi-userland/workspace/components/library/mozilla-nspr/nspr-4.12/nspr/pr/src/pthreads/ptsynch.c:159
> /usr/bin/pwdhash: line 60: 5993: Abort(coredump)
> 
> $ pstack core
> core 'core' of 5993: /usr/bin/amd64/pwdhash-bin
>  fd7fff2b4eda _lwp_kill () + a
>  fd7fff2480e0 raise (6) + 20
>  fd7fff220818 abort () + 98
>  fd7ff943fda2  ()
>  fd7ff9457828 PR_DestroyLock () + d8
>  fd7ff978bc2a slapi_entry_free () + 11a
>  00402888 init_config () + 2d8
>  00402d43 main () + 353
>  0040235c _start () + 6c
> 
> Before I dive in the source code, has anyone a hint where I can start to 
> search what happens here?
> 

Sounds like the lock may not have been created properly? Sadly I think
you need to dive into the source,

:( 

Let me know if you need any other advice. 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[389-devel] Please review 48973: Indexing a ExactIA5Match attribute with a IgnoreIA5Match matching rule triggers a warning

2017-09-27 Thread thierry bordaz 

https://pagure.io/389-ds-base/issue/48973

https://pagure.io/389-ds-base/issue/raw/files/e9c88aa920e588d5fd279b2671c5824ae5366b2faf2cbf196eed4c73cc3058c4-0001-Ticket-48973-Indexing-a-ExactIA5Match-attribute-with.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org