Re: (ITS#7093) test000-rootdse: line 66: kill: (5333) - No such process

2011-11-23 Thread michael
It seems to work with git master fadb48a723756ac0111731f7650f7da1a23c12a3 So you can close this ITS. If any issue is in the RE24 I will file new ITS. Ciao, Michael.

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit

2011-11-23 Thread h . b . furuseth
draft-behera-ldap-password-policy: - Says this should be supported via attribute SubtreeSpecification in the pwdPolicy subentry. I think OpenLDAP does not support this attribute, it accepts it but does not do anything. - Leaves room to make the requested behavior configurable in

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread michael
I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good backup LDIF (data1) the bug happens again. I noticed that in data1 the entries which were mixed up later in

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread quanah
--On Wednesday, November 23, 2011 8:18 PM + mich...@stroeder.com wrote: I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good backup LDIF (data1) the bug

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread michael
Quanah Gibson-Mount wrote: --On Wednesday, November 23, 2011 8:18 PM + mich...@stroeder.com wrote: I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... But with the old last good

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread quanah
--On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder mich...@stroeder.com wrote: Can you provide these two data sets? As said in my first posting: This is private address book data. So nope. Can you provide it outside of the ITS system in a private manner to Howard? That is

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread michael
Quanah Gibson-Mount wrote: --On Wednesday, November 23, 2011 9:48 PM +0100 Michael Ströder mich...@stroeder.com wrote: Can you provide these two data sets? As said in my first posting: This is private address book data. So nope. Can you provide it outside of the ITS system in a private

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread quanah
--On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder mich...@stroeder.com wrote: No way. Then it is unlikely this will get fixed until you can provide a dummy data set that triggers the issue. Personally this is why I keep an NDA with Symas. --Quanah -- Quanah Gibson-Mount

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread michael
Quanah Gibson-Mount wrote: --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder mich...@stroeder.com wrote: No way. Then it is unlikely this will get fixed until you can provide a dummy data set that triggers the issue. As said I'll try to provide test data. But what strikes

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread quanah
--On Wednesday, November 23, 2011 11:16 PM +0100 Michael Ströder mich...@stroeder.com wrote: Quanah Gibson-Mount wrote: --On Wednesday, November 23, 2011 10:34 PM +0100 Michael Ströder mich...@stroeder.com wrote: No way. Then it is unlikely this will get fixed until you can provide a

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread hyc
mich...@stroeder.com wrote: I've re-tested with git RE24 65a49595f563573f91da936ea27f5eaf6b21a48d with *nearly* the same data (data2) and the bug does not seem to happen again. Hmm... You still haven't answered this first question: If you revert the code to an older commit, does it produce

Re: (ITS#7090) back-mdb produces wrong slapcat output

2011-11-23 Thread michael
Howard Chu wrote: This would imply that the error is isolated to slapcat. Since you claim the problem did not occur in an earlier revision, Well, that's not sure anymore since I could simply not have observed it before because the slapcat'ed LDIF was always in tree order. Not sure. As said.