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!). > > > >
