GCC 4.4
by Quanah Gibson-Mount
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
14 years, 10 months
Re: commit: ldap/servers/slapd schema_check.c
by Hallvard B Furuseth
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
14 years, 10 months
test049, test050, test053 in HEAD now fail
by Hallvard B Furuseth
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
14 years, 10 months
minor test stuff
by Howard Chu
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/
14 years, 10 months
RE24 testing again
by Quanah Gibson-Mount
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
14 years, 10 months
Please test RE24
by Quanah Gibson-Mount
Please test RE24.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 10 months
Re: commit: ldap/servers/slapd/overlays dynlist.c
by Hallvard B Furuseth
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
14 years, 10 months
IDL bit vectors
by Howard Chu
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/
14 years, 10 months
"widely supported scripting language" for make test (was ITS#5809)
by Michael Ströder
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.
14 years, 10 months
