Isn't ldif-filter supposed to deal with this? Probably, test043 needs to sort entries (-s bdb=a,hdb=a).
p.
Full_Name: Matt Hardin Version: 2.4.22 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141)
test043 fails under Windows because the contextCSN attribute for the entry dc=example,dc=com are returned in different places within the entry for the producer and consumer. To wit:
server1.flt-
dn: dc=example,dc=com dc: example objectClass: organization objectClass: domainRelatedObject objectClass: dcObject l: Anytown, Michigan st: Michigan o: Example, Inc. o: EX o: Ex. description: The Example, Inc. at Anytown postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com structuralObjectClass: organization entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20100518161938Z entryCSN: 20100518161938.140191Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20100518161938Z entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema contextCSN: 20100518162026.443250Z#000000#000#000000 hasSubordinates: TRUE
server2.flt-
dn: dc=example,dc=com dc: example objectClass: organization objectClass: domainRelatedObject objectClass: dcObject l: Anytown, Michigan st: Michigan o: Example, Inc. o: EX o: Ex. description: The Example, Inc. at Anytown postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com structuralObjectClass: organization entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20100518161938Z entryCSN: 20100518161938.140191Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20100518161938Z contextCSN: 20100518162026.443250Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE
While this is not a problem in operation, and is not specifically a bug according to the RFCs, test043 nonetheless fails because it expects an exact match in the ordering between the producer and consumer. It's not clear whether the desired fix is in slapd or in the test itself.
This test does not fail on any other platforms with which we are currently working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to ITS#6549, which is now fixed (thanks Ando!).