OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
Thanks!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
All tests passed on OpenSUSE 10.2 x86 and x86_64.
Having the same old difficulty with accept() and socklen_t/size_t on HPUX ia64, so apparently the patch for ITS#4629 still needs some work. One problem here is that the HPUX header files are not actually in sync with their libraries. So even if configure detects the size of the argument that the header file prototype used, it may not necessarily match the version of accept() that actually gets linked into the binary. (I.e., daemon.c compiled cleanly with no warnings about type mismatches, but accept fails with EADDR. Recompiling with an explicit size_t argument gets a warning, but the code runs correctly.) This is compiling in LP64 mode...
Also back-perl fails to build on HPUX because perl defines struct magic and MAGIC, and HPUX does as well (in /usr/include/sys/magic.h). For now I've worked around this by adding -D_SYS_MAGIC_INCLUDED to the CPPFLAGS to get it to compile. (Nothing actually needs the defs in <sys/magic.h>, it gets pulled in indirectly by <arpa/nameser.h> for no good reason.)
With those problems aside, test030 fails in back-meta. I haven't got a working gdb here yet so I haven't had a chance to examine the core file.
Seems to build OK on Solaris 10 sparc64. tests are still running at the moment.
Howard Chu wrote:
Quanah Gibson-Mount wrote:
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
All tests passed on OpenSUSE 10.2 x86 and x86_64.
Having the same old difficulty with accept() and socklen_t/size_t on HPUX ia64, so apparently the patch for ITS#4629 still needs some work.
With those problems aside, test030 fails in back-meta. I haven't got a working gdb here yet so I haven't had a chance to examine the core file.
This was the same problem. For the sake of getting past this test I just edited portable.h and changed the #define of ber_socklen_t to size_t.
Seems to build OK on Solaris 10 sparc64. tests are still running at the moment.
test047 crashed in rwm_dn_massage, it looks like invalid pointers were passed in. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5 (LWP 5)] 0xffffffff7cf371f0 in strlen () from /lib/64/libc.so.1 (gdb) bt #0 0xffffffff7cf371f0 in strlen () from /lib/64/libc.so.1 #1 0xffffffff7cf9f968 in _ndoprnt () from /lib/64/libc.so.1 #2 0xffffffff7cfa2094 in vsnprintf () from /lib/64/libc.so.1 #3 0x0000000100188b5c in lutil_debug (debug=2042613608, level=0, fmt=0xffffffff7c701000 "") at ../../../r24/libraries/liblber/debug.c:66 #4 0x000000010013c7a4 in rwm_dn_massage (dc=0x105, in=0x4, dn=0x100206f08) at ../../../../r24/servers/slapd/overlays/rwmdn.c:178 #5 0x000000010013c9d0 in rwm_dn_massage_pretty (dc=0xffffffff79bfe460, in=0xffffffff79bfe1d8, pdn=0xffffffff79bfe100) at ../../../../r24/servers/slapd/overlays/rwmdn.c:87
Not sure why passing from frame 5 to frame 4 would have messed up unless the function prototypes are wrong, but they look OK.
Howard Chu wrote:
Seems to build OK on Solaris 10 sparc64. tests are still running at the moment.
test047 crashed in rwm_dn_massage, it looks like invalid pointers were passed in. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 5 (LWP 5)] 0xffffffff7cf371f0 in strlen () from /lib/64/libc.so.1 (gdb) bt #0 0xffffffff7cf371f0 in strlen () from /lib/64/libc.so.1 #1 0xffffffff7cf9f968 in _ndoprnt () from /lib/64/libc.so.1 #2 0xffffffff7cfa2094 in vsnprintf () from /lib/64/libc.so.1 #3 0x0000000100188b5c in lutil_debug (debug=2042613608, level=0, fmt=0xffffffff7c701000 "") at ../../../r24/libraries/liblber/debug.c:66 #4 0x000000010013c7a4 in rwm_dn_massage (dc=0x105, in=0x4, dn=0x100206f08) at ../../../../r24/servers/slapd/overlays/rwmdn.c:178 #5 0x000000010013c9d0 in rwm_dn_massage_pretty (dc=0xffffffff79bfe460, in=0xffffffff79bfe1d8, pdn=0xffffffff79bfe100) at ../../../../r24/servers/slapd/overlays/rwmdn.c:87
Not sure why passing from frame 5 to frame 4 would have messed up unless the function prototypes are wrong, but they look OK.
The bad stack trace was a red herring. The problem here is simply passing a NULL pointer to a string-format Debug statement, and the usual stuff with Solaris libc/string library crashing on NULL pointers. Pretty sure that just protecting the Debug statement here is sufficient.
Howard Chu wrote:
The bad stack trace was a red herring. The problem here is simply passing a NULL pointer to a string-format Debug statement, and the usual stuff with Solaris libc/string library crashing on NULL pointers. Pretty sure that just protecting the Debug statement here is sufficient.
With the Debug statements patched all tests pass on Solaris 10 Sparc64.
Howard Chu wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
All tests passed on OpenSUSE 10.2 x86 and x86_64.
Having the same old difficulty with accept() and socklen_t/size_t on HPUX ia64, so apparently the patch for ITS#4629 still needs some work.
With those problems aside, test030 fails in back-meta. I haven't got a working gdb here yet so I haven't had a chance to examine the core file.
This was the same problem. For the sake of getting past this test I just edited portable.h and changed the #define of ber_socklen_t to size_t.
With that tweak all tests pass on HPUX11.23 ia64 (LP64). I don't think it's interesting to do a 32 bit build on this machine so I'm ignoring that for now.
<quote who="Howard Chu">
Howard Chu wrote:
Howard Chu wrote:
Quanah Gibson-Mount wrote:
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
All tests passed on OpenSUSE 10.2 x86 and x86_64.
Having the same old difficulty with accept() and socklen_t/size_t on HPUX ia64, so apparently the patch for ITS#4629 still needs some work.
With those problems aside, test030 fails in back-meta. I haven't got a working gdb here yet so I haven't had a chance to examine the core file.
This was the same problem. For the sake of getting past this test I just edited portable.h and changed the #define of ber_socklen_t to size_t.
With that tweak all tests pass on HPUX11.23 ia64 (LP64). I don't think it's interesting to do a 32 bit build on this machine so I'm ignoring that for now.
FYI: make test fine on Fedora 7, i386, bdb 4.2.52
Quanah Gibson-Mount wrote:
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
Build & tests work fine here on various Linux i386; testing on SuSE, x86_64.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
<quote who="Quanah Gibson-Mount">
OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86.
Thanks!
Excellent. Just build docs fine, as expected. Will start building later and report back.
Will we have an updated version of the 2.4 guide and PDF on the devel section of the site or somewhere else? We can then point users to it and ask for feedback of any missing sections etc.
Gavin.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Gavin Henry wrote:
<quote who="Quanah Gibson-Mount"> > OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check > it out and test that builds and functionality work as expected. I've > tested so far on MAC OS X x86. > > Thanks!
Excellent. Just build docs fine, as expected. Will start building later and report back.
Will we have an updated version of the 2.4 guide and PDF on the devel section of the site or somewhere else? We can then point users to it and ask for feedback of any missing sections etc.
Yes to the HTML. We've never produced PDFs in the past but I guess we could start. I personally wouldn't bother with posting PDFs until we're closer to complete here. Also since the PDF is generated from HTML anyway, I personally would just use the HTML. (One nice thing being that you can read it on a TTY, another being that you can copy/paste from it. Two strikes against PDF, in my mind.)
<quote who="Howard Chu">
Gavin Henry wrote:
<quote who="Quanah Gibson-Mount"> > OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please > check > it out and test that builds and functionality work as expected. I've > tested so far on MAC OS X x86. > > Thanks!
Excellent. Just build docs fine, as expected. Will start building later and report back.
Will we have an updated version of the 2.4 guide and PDF on the devel section of the site or somewhere else? We can then point users to it and ask for feedback of any missing sections etc.
Yes to the HTML. We've never produced PDFs in the past but I guess we could start. I personally wouldn't bother with posting PDFs until we're closer to complete here. Also since the PDF is generated from HTML anyway, I personally would just use the HTML.
For normal releases we already have:
Which has a PDF for the 2.3 Admin Guide, but until we're out of beta it can wait.
(One nice thing being that you can read it on a TTY, another being that you can copy/paste from it. Two strikes against PDF, in my mind.)
Umm, one strike. You can easily copy and paste from PDFs to the same degree you can from HTML (HTML tables I'm thinking about here, which produce the same results as c&p from PDFs), but your point is noted :-)
Thanks,
Gavin.
-
Gavin Henry -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount