openldap-devel November 2008

openldap-devel@openldap.org

20 participants
40 discussions

GCC 4.4
by Quanah Gibson-Mount 20 Nov '08

20 Nov '08

Debian has a bug (505421) about OpenLDAP not building with the upcoming gcc 4.4. We may want to take a look at resolving that. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 2

Re: commit: ldap/servers/slapd schema_check.c
by Hallvard B Furuseth 19 Nov '08

19 Nov '08

ando(a)OpenLDAP.org writes: > schema_check.c 1.114 -> 1.115 > clear rc if value must be added (ITS#5819) Looking at that code, I don't think textbuf should be filled either when rc is set to LDAP_SUCCESS. -- Hallvard

2 1

test049, test050, test053 in HEAD now fail
by Hallvard B Furuseth 18 Nov '08

18 Nov '08

test049 fails with invalid DN "cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com" in the consumer because core.schema with 'ou' and 'dc' is not loaded. test050 similarly fails on "dc=example,dc=com". test053 also fails, i have not checked why. Like test050 it keeps waiting for syncrepl to receive changes, then gives up. If it makes a difference, my configuration is ./configure --enable-dynamic --enable-modules --enable-dynamic --enable-dynacl --enable-aci --enable-crypt --enable-lmpasswd --enable-modules --enable-spasswd --enable-rlookups --enable-slapi --enable-backends=mod --disable-ndb --disable-sql --enable-overlays=mod -- Hallvard

6 16

minor test stuff
by Howard Chu 18 Nov '08

18 Nov '08

The long fixed-length waits in the syncrepl tests always annoy me. Is anyone actually testing on hardware that takes longer than 1 second to sync? (The last time I tested on such a slow machine was the z/OS partition I ported to back in 2002/2003.) Would anyone object to dropping the all syncrepl intervals to say, 2 seconds, and setting the delays to around 5 seconds? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

RE24 testing again
by Quanah Gibson-Mount 18 Nov '08

18 Nov '08

Please test current RE24, it has been synch'd with the fixes found for the last round of testing. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 7

Please test RE24
by Quanah Gibson-Mount 17 Nov '08

17 Nov '08

Please test RE24. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

7 16

Re: commit: ldap/servers/slapd/overlays dynlist.c
by Hallvard B Furuseth 17 Nov '08

17 Nov '08

quanah(a)OpenLDAP.org writes: > dynlist.c 1.58 -> 1.59 > Fix prev commit Still using the wrong length. Should both be soc_cname, or both ad_cname? -- Hallvard

1 0

Re: commit: ldap/servers/slapd/overlays dynlist.c
by Hallvard B Furuseth 16 Nov '08

16 Nov '08

ando(a)OpenLDAP.org wrote: > dynlist.c 1.57 -> 1.58 > add optional URI to allow restricting the scope of application of a > specific dynamic list expansion rule (ITS#5761) Bug: Third arg here should be an integer, not a string. + ptr = lutil_strncopy( ptr, dli->dli_oc->soc_cname.bv_val, dli->dli_ad->ad_cname.bv_val ); -- Hallvard

2 1

IDL bit vectors
by Howard Chu 16 Nov '08

16 Nov '08

Seems like I keep poking at this idea again every couple years. If we use a <base,vector> we can cover a much wider range without losing any precision. For a 32 bit machine, 32 bits per word would cover 5 bits worth of entry IDs. So 27 bits would comprise the base, and the next 32 bits would represent up to 32 entry IDs. To avoid wasting those 5 unneeded bits in the base, we could use them as a run-length counter and use multiple vectors per base. But it might be better to slide things over and use just a 24 bit base, and use the bottom 8 bits of the word as a bitmask to represent which following vectors are present. E.g. ......01 means 1 vector follows, representing base+ 0-31. ......02 means 1 vector follows, representing base+32-63. ......05 means 2 vectors follow, base+0-31 then base+64-95. That allows us to represent up to 256 entryIDs in only 288 bits (instead of the 16384 bits we currently need). That would allow us to track about 1.86M entryIDs in the same space we currently use to track only 64K entryIDs. It seems we would still need some kind of range representation to handle IDLs with more than 1.86M entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 5

"widely supported scripting language" for make test (was ITS#5809)
by Michael Ströder 16 Nov '08

16 Nov '08

Redirected this to openldap-devel list. ando(a)sys-net.it wrote: > Quanah Gibson-Mount wrote: > >>> I'm hitting an issue like this in some of the replication tests I'm >>> currently performing. For this purpose, I think we could hack >>> ldapsearch (or add a new prog, or use a script on ldapsearch output) >>> that sorts entries content attribute-wise and, within each attribute, >>> value-wise. Something like "sort" applied entry-wise after unwrapping >>> line folding, optionally case-insensitive would probably suffice. >> I have a script somewhere from Matt Backes @ Symas that sorts LDIF >> files. It was useful for seeing if it made any difference in slapadd (it >> didn't). > > Well, if it were distributable, and written in a widely supported > scripting language, it would be quite useful... What do you consider a "widely supported scripting language"? During some discussions about the test suite I felt that having a more powerful scripting language would help dealing with some of the problems in a more elegant way. Ciao, Michael.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel November 2008