openldap-bugs November 2007

openldap-bugs@openldap.org

44 participants
170 discussions

Re: (ITS#5228) Patches for minor typos in man pages
by sam.varshavchik＠gmail.com 11 Nov '07

11 Nov '07

------=_Part_2936_9723584.1194823201662 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline No problem. Here are the fixes diff-ed against CVS HEAD: http://www.tldp.org/manpages/openldap-2.4.6-manpatch.txt This is also attached to this message. On Nov 11, 2007 3:18 PM, Gavin Henry <ghenry(a)openldap.org> wrote: > sam.varshavchik(a)gmail.com wrote: > > Full_Name: Sam Varshavchik > > Version: 2.4.6 > > OS: Linux > > URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > Submission from: (NULL) (216.254.115.190) > > > > > > Attached please find patches for minor typos and fixes to various manual pages > > in openldap 2.4.6 > > > > http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > > > > > > > Thanks. > > It may be using doing a cvs diff to create one doc patch? > > -- > Kind Regards, > > Gavin Henry. > OpenLDAP Engineering Team. > > E ghenry(a)OpenLDAP.org > > Community developed LDAP software. > > http://www.openldap.org/project/ > ------=_Part_2936_9723584.1194823201662 Content-Type: text/plain; name=openldap-2.4.6-manpatch.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f8w6u5m50 Content-Disposition: attachment; filename=openldap-2.4.6-manpatch.txt SW5kZXg6IGRvYy9tYW4vbWFuMS9sZGFwbW9kaWZ5LjEKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Jl cG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW4xL2xkYXBtb2RpZnkuMSx2CnJldHJpZXZp bmcgcmV2aXNpb24gMS41MQpkaWZmIC1VMyAtcjEuNTEgbGRhcG1vZGlmeS4xCi0tLSBkb2MvbWFu L21hbjEvbGRhcG1vZGlmeS4xCTIgSmFuIDIwMDcgMTk6MDA6NTMgLTAwMDAJMS41MQorKysgZG9j L21hbi9tYW4xL2xkYXBtb2RpZnkuMQkxMSBOb3YgMjAwNyAyMzoxNjowNCAtMDAwMApAQCAtMzI2 LDYgKzMyNiw3IEBACiAgICAgdGl0bGU6IHRoZSB3b3JsZCdzIG1vc3QgZmFtb3VzIG15dGhpY2Fs IG1hbmFnZXIKICAgICBtYWlsOiBiamVuc2VuQGV4YW1wbGUuY29tCiAgICAgdWlkOiBiamVuc2Vu CisuZmkKIC5MUAogdGhlIGNvbW1hbmQ6CiAuTFAKQEAgLTM0NCw2ICszNDUsNyBAQAogLm5mCiAg ICAgZG46IGNuPUJhcmJhcmEgSmVuc2VuLGRjPWV4YW1wbGUsZGM9Y29tCiAgICAgY2hhbmdldHlw ZTogZGVsZXRlCisuZmkKIC5MUAogdGhlIGNvbW1hbmQ6CiAuTFAKSW5kZXg6IGRvYy9tYW4vbWFu My9sZGFwX2V4dGVuZGVkX29wZXJhdGlvbi4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09w ZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuMy9sZGFwX2V4dGVuZGVkX29wZXJhdGlvbi4zLHYK cmV0cmlldmluZyByZXZpc2lvbiAxLjUKZGlmZiAtVTMgLXIxLjUgbGRhcF9leHRlbmRlZF9vcGVy YXRpb24uMwotLS0gZG9jL21hbi9tYW4zL2xkYXBfZXh0ZW5kZWRfb3BlcmF0aW9uLjMJMiBKYW4g MjAwNyAxOTowMDo1NCAtMDAwMAkxLjUKKysrIGRvYy9tYW4vbWFuMy9sZGFwX2V4dGVuZGVkX29w ZXJhdGlvbi4zCTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0zMiw3ICszMiw3IEBACiBj b25zdCBzdHJ1Y3QgYmVydmFsICpcZklyZXF1ZXN0ZGF0YVxmQiwKIExEQVBDb250cm9sICoqXGZJ c2N0cmxzXGZCLAogTERBUENvbnRyb2wgKipcZkljY3RybHNcZkIsCi1jaGFyICoqXGZJcmV0b2lk cFxmQjsKK2NoYXIgKipcZklyZXRvaWRwXGZCLAogc3RydWN0IGJlcnZhbCAqKlxmSXJldGRhdGFw XGZCICk7CiAuUkUKIC5TSCBERVNDUklQVElPTgpJbmRleDogZG9jL21hbi9tYW4zL2xkYXBfZ2V0 X3ZhbHVlcy4zCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09wZW5MREFQL3BrZy9sZGFwL2Rv Yy9tYW4vbWFuMy9sZGFwX2dldF92YWx1ZXMuMyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xOQpk aWZmIC1VMyAtcjEuMTkgbGRhcF9nZXRfdmFsdWVzLjMKLS0tIGRvYy9tYW4vbWFuMy9sZGFwX2dl dF92YWx1ZXMuMwkyIEphbiAyMDA3IDE5OjI1OjE2IC0wMDAwCTEuMTkKKysrIGRvYy9tYW4vbWFu My9sZGFwX2dldF92YWx1ZXMuMwkxMSBOb3YgMjAwNyAyMzoxNjowNCAtMDAwMApAQCAtMTcsMzIg KzE3LDMyIEBACiAuZnQKIExEQVAgKmxkOwogTERBUE1lc3NhZ2UgKmVudHJ5OwotY2hhciAqYXR0 cgorY2hhciAqYXR0cjsKIC5MUAogLmZ0IEIKIHN0cnVjdCBiZXJ2YWwgKipsZGFwX2dldF92YWx1 ZXNfbGVuKGxkLCBlbnRyeSwgYXR0cikKIC5mdAogTERBUCAqbGQ7CiBMREFQTWVzc2FnZSAqZW50 cnk7Ci1jaGFyICphdHRyCitjaGFyICphdHRyOwogLkxQCiAuZnQgQgotbGRhcF9jb3VudF92YWx1 ZXModmFscykKK2ludCBsZGFwX2NvdW50X3ZhbHVlcyh2YWxzKQogLmZ0CiBjaGFyICoqdmFsczsK IC5MUAogLmZ0IEIKLWxkYXBfY291bnRfdmFsdWVzX2xlbih2YWxzKQoraW50IGxkYXBfY291bnRf dmFsdWVzX2xlbih2YWxzKQogLmZ0CiBzdHJ1Y3QgYmVydmFsICoqdmFsczsKIC5MUAogLmZ0IEIK LWxkYXBfdmFsdWVfZnJlZSh2YWxzKQordm9pZCBsZGFwX3ZhbHVlX2ZyZWUodmFscykKIC5mdAog Y2hhciAqKnZhbHM7CiAuTFAKIC5mdCBCCi1sZGFwX3ZhbHVlX2ZyZWVfbGVuKHZhbHMpCit2b2lk IGxkYXBfdmFsdWVfZnJlZV9sZW4odmFscykKIC5mdAogc3RydWN0IGJlcnZhbCAqKnZhbHM7CiAu U0ggREVTQ1JJUFRJT04KSW5kZXg6IGRvYy9tYW4vbWFuMy9sZGFwX3BhcnNlX3Zsdl9jb250cm9s LjMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9t YW4zL2xkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS41CmRp ZmYgLVUzIC1yMS41IGxkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwotLS0gZG9jL21hbi9tYW4zL2xk YXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwk2IEF1ZyAyMDA3IDE1OjI0OjE0IC0wMDAwCTEuNQorKysg ZG9jL21hbi9tYW4zL2xkYXBfcGFyc2Vfdmx2X2NvbnRyb2wuMwkxMSBOb3YgMjAwNyAyMzoxNjow NCAtMDAwMApAQCAtMTIsNyArMTIsNyBAQAogI2luY2x1ZGUgPGxkYXAuaD4KIC5MUAogLmZ0IEIK LWludCBsZGFwX3BhcnNlX3Zsdl9jb250cm9sKCBsZCwgY3RybHAsIHRhcmdldF9wb3NwLCBsaXN0 X2NvdW50cCwgY29udGV4dHAsIGVycmNvZGVwICk7ICAKK2ludCBsZGFwX3BhcnNlX3Zsdl9jb250 cm9sKCBsZCwgY3RybHAsIHRhcmdldF9wb3NwLCBsaXN0X2NvdW50cCwgY29udGV4dHAsIGVycmNv ZGVwICkKIC5mdAogTERBUCAqbGQ7CiBMREFQQ29udHJvbCAqKmN0cmxwOwpJbmRleDogZG9jL21h bi9tYW4zL2xkYXBfdXJsLjMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtn L2xkYXAvZG9jL21hbi9tYW4zL2xkYXBfdXJsLjMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjIK ZGlmZiAtVTMgLXIxLjIyIGxkYXBfdXJsLjMKLS0tIGRvYy9tYW4vbWFuMy9sZGFwX3VybC4zCTI0 IEp1bCAyMDA3IDE3OjExOjM5IC0wMDAwCTEuMjIKKysrIGRvYy9tYW4vbWFuMy9sZGFwX3VybC4z CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0zMSw3ICszMSw3IEBACiB9IExEQVBVUkxE ZXNjOwogLkxQCiAuZnQgQgotbGRhcF9mcmVlX3VybGRlc2MoIExEQVBVUkxEZXNjICpsdWRwICkK K3ZvaWQgbGRhcF9mcmVlX3VybGRlc2MoIExEQVBVUkxEZXNjICpsdWRwICk7CiAuU0ggREVTQ1JJ UFRJT04KIFRoZXNlIHJvdXRpbmVzIHN1cHBvcnQgdGhlIHVzZSBvZiBMREFQIFVSTHMgKFVuaWZv cm0gUmVzb3VyY2UgTG9jYXRvcnMpCiBhcyBkZXRhaWxlZCBpbiBSRkMgNDUxNi4gIExEQVAgVVJM cyBsb29rIGxpa2UgdGhpczoKSW5kZXg6IGRvYy9tYW4vbWFuNS9zbGFwby1wcG9saWN5LjUKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW41L3Ns YXBvLXBwb2xpY3kuNSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xOApkaWZmIC1VMyAtcjEuMTgg c2xhcG8tcHBvbGljeS41Ci0tLSBkb2MvbWFuL21hbjUvc2xhcG8tcHBvbGljeS41CTI0IEp1bCAy MDA3IDE3OjExOjM5IC0wMDAwCTEuMTgKKysrIGRvYy9tYW4vbWFuNS9zbGFwby1wcG9saWN5LjUJ MTEgTm92IDIwMDcgMjM6MTY6MDQgLTAwMDAKQEAgLTUwMyw3ICs1MDMsNyBAQAogLkIgdXNlclBh c3N3b3JkCiAuUAogVGhlCi0uYiB1c2VyUGFzc3dvcmQKKy5CIHVzZXJQYXNzd29yZAogYXR0cmli dXRlIGlzIG5vdCBzdHJpY3RseSBwYXJ0IG9mIHRoZQogLkIgcHBvbGljeQogbW9kdWxlLiAgSXQg aXMsIGhvd2V2ZXIsIHRoZSBhdHRyaWJ1dGUgdGhhdCBpcyB0cmFja2VkIGFuZCBjb250cm9sbGVk CkluZGV4OiBkb2MvbWFuL21hbjgvc2xhcGFjbC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBv L09wZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwYWNsLjgsdgpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMTQKZGlmZiAtVTMgLXIxLjE0IHNsYXBhY2wuOAotLS0gZG9jL21hbi9tYW44L3Ns YXBhY2wuOAkxMSBKYW4gMjAwNyAxNToyNzoxMSAtMDAwMAkxLjE0CisrKyBkb2MvbWFuL21hbjgv c2xhcGFjbC44CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0xMCw3ICsxMCw3IEBACiAu QiBbXC1EIGF1dGhjRE4gfCBcLVUgYXV0aGNJRF0KIC5CIFtcLWYgc2xhcGQuY29uZl0KIC5CIFtc LUYgY29uZmRpcl0KLS5CIFtcLW8gbmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVlXV0K IC5CIFtcLXVdCiAuQiBbXC12XQogLkIgW1wtWCBhdXRoeklEIHwgXC1vIGF1dGh6RE49RE5dCklu ZGV4OiBkb2MvbWFuL21hbjgvc2xhcGFkZC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBvL09w ZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwYWRkLjgsdgpyZXRyaWV2aW5nIHJldmlz aW9uIDEuNDgKZGlmZiAtVTMgLXIxLjQ4IHNsYXBhZGQuOAotLS0gZG9jL21hbi9tYW44L3NsYXBh ZGQuOAkxNyBPY3QgMjAwNyAyMTowODo0OCAtMDAwMAkxLjQ4CisrKyBkb2MvbWFuL21hbjgvc2xh cGFkZC44CTExIE5vdiAyMDA3IDIzOjE2OjA0IC0wMDAwCkBAIC0xNSw3ICsxNSw3IEBACiAuQiBb XC1qIGxpbmVub10KIC5CIFtcLWwgbGRpZi1maWxlXQogLkIgW1wtbiBkYm51bV0KLS5CIFtcLW8g bmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVlXV0KIC5CIFtcLXFdCiAuQiBbXC1zXQog LkIgW1wtUyBTSURdCkluZGV4OiBkb2MvbWFuL21hbjgvc2xhcGF1dGguOAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJD UyBmaWxlOiAvcmVwby9PcGVuTERBUC9wa2cvbGRhcC9kb2MvbWFuL21hbjgvc2xhcGF1dGguOCx2 CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMgpkaWZmIC1VMyAtcjEuMTIgc2xhcGF1dGguOAotLS0g ZG9jL21hbi9tYW44L3NsYXBhdXRoLjgJMjQgSnVsIDIwMDcgMTc6MTE6MzkgLTAwMDAJMS4xMgor KysgZG9jL21hbi9tYW44L3NsYXBhdXRoLjgJMTEgTm92IDIwMDcgMjM6MTY6MDQgLTAwMDAKQEAg LTksNyArOSw3IEBACiAuQiBbXC1mIHNsYXBkLmNvbmZdCiAuQiBbXC1GIGNvbmZkaXJdCiAuQiBb XC1NIG1lY2hdCi0uQiBbXC1vIG5hbWVbPXZhbHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAu QiBbXC1SIHJlYWxtXQogLkIgW1wtVSBhdXRoY0lEXQogLkIgW1wtdl0KSW5kZXg6IGRvYy9tYW4v bWFuOC9zbGFwY2F0LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xk YXAvZG9jL21hbi9tYW44L3NsYXBjYXQuOCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zNQpkaWZm IC1VMyAtcjEuMzUgc2xhcGNhdC44Ci0tLSBkb2MvbWFuL21hbjgvc2xhcGNhdC44CTIyIEp1bCAy MDA3IDE2OjMwOjQ2IC0wMDAwCTEuMzUKKysrIGRvYy9tYW4vbWFuOC9zbGFwY2F0LjgJMTEgTm92 IDIwMDcgMjM6MTY6MDUgLTAwMDAKQEAgLTE1LDcgKzE1LDcgQEAKIC5CIFtcLWddCiAuQiBbXC1s IGxkaWYtZmlsZV0KIC5CIFtcLW4gZGJudW1dCi0uQiBbXC1vIG5hbWVbPXZhbHVlXQorLkIgW1wt byBuYW1lWz12YWx1ZV1dCiAuQiBbXC1zIHN1YnRyZWUtZG5dCiAuQiBbXC12XQogLkIgCkluZGV4 OiBkb2MvbWFuL21hbjgvc2xhcGRuLjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxE QVAvcGtnL2xkYXAvZG9jL21hbi9tYW44L3NsYXBkbi44LHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjEyCmRpZmYgLVUzIC1yMS4xMiBzbGFwZG4uOAotLS0gZG9jL21hbi9tYW44L3NsYXBkbi44CTI0 IEp1bCAyMDA3IDE3OjExOjM5IC0wMDAwCTEuMTIKKysrIGRvYy9tYW4vbWFuOC9zbGFwZG4uOAkx MSBOb3YgMjAwNyAyMzoxNjowNSAtMDAwMApAQCAtOSw3ICs5LDcgQEAKIC5CIFtcLWYgc2xhcGQu Y29uZl0KIC5CIFtcLUYgY29uZmRpcl0KIC5CIFtcLU4gfCBcLVBdCi0uQiBbXC1vIG5hbWVbPXZh bHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAuQiBbXC12XQogLkIgRE4gWy4uLl0KIC5MUApJ bmRleDogZG9jL21hbi9tYW44L3NsYXBpbmRleC44Cj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9yZXBv L09wZW5MREFQL3BrZy9sZGFwL2RvYy9tYW4vbWFuOC9zbGFwaW5kZXguOCx2CnJldHJpZXZpbmcg cmV2aXNpb24gMS4yNwpkaWZmIC1VMyAtcjEuMjcgc2xhcGluZGV4LjgKLS0tIGRvYy9tYW4vbWFu OC9zbGFwaW5kZXguOAk0IE9jdCAyMDA3IDA5OjAyOjU3IC0wMDAwCTEuMjcKKysrIGRvYy9tYW4v bWFuOC9zbGFwaW5kZXguOAkxMSBOb3YgMjAwNyAyMzoxNjowNSAtMDAwMApAQCAtMTMsNyArMTMs NyBAQAogLkIgW1wtRiBjb25mZGlyXQogLkIgW1wtZ10KIC5CIFtcLW4gZGJudW1dCi0uQiBbXC1v IG5hbWVbPXZhbHVlXQorLkIgW1wtbyBuYW1lWz12YWx1ZV1dCiAuQiBbXC1xXQogLkIgW1wtdl0K IC5CIFthdHRyXSBbLi4uXQpJbmRleDogZG9jL21hbi9tYW44L3NsYXB0ZXN0LjgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpSQ1MgZmlsZTogL3JlcG8vT3BlbkxEQVAvcGtnL2xkYXAvZG9jL21hbi9tYW44L3NsYXB0ZXN0 LjgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQKZGlmZiAtVTMgLXIxLjE0IHNsYXB0ZXN0LjgK LS0tIGRvYy9tYW4vbWFuOC9zbGFwdGVzdC44CTE0IEF1ZyAyMDA3IDExOjUzOjM3IC0wMDAwCTEu MTQKKysrIGRvYy9tYW4vbWFuOC9zbGFwdGVzdC44CTExIE5vdiAyMDA3IDIzOjE2OjA1IC0wMDAw CkBAIC04LDcgKzgsNyBAQAogLkIgW1wtZCBsZXZlbF0KIC5CIFtcLWYgc2xhcGQuY29uZl0KIC5C IFtcLUYgY29uZmRpcl0KLS5CIFtcLW8gbmFtZVs9dmFsdWVdCisuQiBbXC1vIG5hbWVbPXZhbHVl XV0KIC5CIFtcLVFdCiAuQiBbXC11XQogLkIgW1wtdl0K ------=_Part_2936_9723584.1194823201662--

1 0

(ITS#5229) `make install' writes to the source tree as root
by mills＠cc.umanitoba.ca 11 Nov '07

11 Nov '07

Full_Name: Gary Mills Version: openldap-2.3.38 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.78.105.29) The usual procedure is to run `configure' and `make' in the install tree as an ordinary user, and then to run `make install' there as root. This install procedure writes to the install tree as root. In some cases, it actually relinks a shared library as root. We build on one server and install on another, where the install tree is mounted read-only. These errors prevent installation in this case. Here are some of the errors: cd overlays; make dynamic sh: slapd.conf.tmp: cannot create *** Error code 1 make: Fatal error: Command failed for target `all-cffiles' cd overlays; make dynamic touch: cannot change times on all-cffiles *** Error code 1 make: Fatal error: Command failed for target `all-cffiles' sh: ldapcompare.1.tmp: cannot create *** Error code 1 make: Fatal error: Command failed for target `all-common' The first few were fixed in servers/slapd/Makefile.in by putting all-cffiles and slapd.conf.tmp in /tmp instead of in the source tree. The man page error was fixed build/man.mk by putting the temporary man pages like $$page.$(TMP_SUFFIX) into /tmp. The relinking error looked like this: Entering subdirectory libldap ../../build/shtool mkdir -p /usr/local/lib /bin/sh ../..//libtool --mode=install ../../build/shtool install -c -m 644 libldap.la /usr/local/lib libtool: install: warning: relinking `libldap.la' ... mv: cannot rename libldap-2.3.so.0.2.26 to libldap-2.3.so.0.2.26U: Read-only file system libtool: install: error: relink `libldap.la' with the above command before installing it *** Error code 1 make: Fatal error: Command failed for target `install-local' Really, it shouldn't be doing relinking at that point, when running as root. Perhaps it could do it earlier, during the compile step. I had to do a `make install' as root in libraries/liblber on build server and then modify the Makefiles in libraries/libldap and libraries/libldap_r to link with the installed library, in order to avoid the relink on the install server. This worked, but is not a good solution.

1 0

Re: (ITS#5228) Patches for minor typos in man pages
by ghenry＠OpenLDAP.org 11 Nov '07

11 Nov '07

sam.varshavchik(a)gmail.com wrote: > Full_Name: Sam Varshavchik > Version: 2.4.6 > OS: Linux > URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > Submission from: (NULL) (216.254.115.190) > > > Attached please find patches for minor typos and fixes to various manual pages > in openldap 2.4.6 > > http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz > > > Thanks. It may be using doing a cvs diff to create one doc patch? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 11 Nov '07

11 Nov '07

dhawes(a)vt.edu wrote: > On Friday 27 July 2007 05:20, ghenry(a)openldap.org wrote: >> Hi David, >> >> http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ >> >> Will be pushed out in the next 2.4 beta. >> >> Please bear in mind that you will be looking after this overlay, so test >> as often as you can and re-submit and changes during our release cycle. >> >> Thank you for your contribution. > > Changes to work properly with 2.4.6 are at: > > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-071109.tgz > > Thanks, > > dave > > Will take a look over the next week. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 10 Nov '07

10 Nov '07

Hi, Le Sam 10 novembre 2007 16:37, ando(a)sys-net.it a écrit : >> Below I represent sets in {element1, element2} notation, to describe the >> current behaviour (in HEAD) for slap_set_join on the '+' operation: >> - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", >> "TwoThree", "TwoFour"} >> - {"One", "Two"} + {""} ==> {"One", "Two"} >> - {"One", "Two"} + {NULL} ==> {"One", "Two"} > > Although sets lack a specification, I think this behavior is desirable > in many cases: adding NULL is equivalent to adding EMPTY (""). The problem is that {NULL} is equivalent to NULL, ie the empty set. >> Consider the following set: >> set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + >> [??<scope>?<filter2>]" >> >> Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this >> works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no >> entries, this value is NULL. Therefore, the rest of the set becomes: >> "[ldap:///] + {NULL} + [??<scope>?<filter2>]" >> ...which is handed to the '+' operation in slap_set_join, to become: >> [ldap:///??<scope>?<filter2>] >> ...which obviously isn't valid. > > Well, it is valid: it's an URI with an EMPTY DN. In terms of LDAP, yes, but it can cause security issues here, as the EMPTY DN is at a higher level that any one which would have been returned by a normal result. >> The attached patch changes the last case of the current behaviour for >> slap_set_join on the '+' operation. This was already the behaviour >> before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: >> - {"One", "Two"} + {NULL} ==> {NULL} > > This is different from the above behavior, although it makes sense on > its own. Probably we need two different addition operators: one > inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies > the concatenation). > > Comments? No problem in having the two operators. I just think the normal behavior is to return NULL, has in term of sets the cartesian product A x NULL returns NULL, not A. Regards, Raphael Ouazana.

1 0

(ITS#5228) Patches for minor typos in man pages
by sam.varshavchik＠gmail.com 10 Nov '07

10 Nov '07

Full_Name: Sam Varshavchik Version: 2.4.6 OS: Linux URL: http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz Submission from: (NULL) (216.254.115.190) Attached please find patches for minor typos and fixes to various manual pages in openldap 2.4.6 http://www.tldp.org/manpages/openldap-2.4.6-manpatches.tar.gz

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 10 Nov '07

10 Nov '07

Jonathan Clarke wrote: > Pierangelo Masarati a écrit : >>> The patch attached corrects this problem on RE23 and HEAD for me >>> and doesn't have any side effects on our test set. However, it >>> may not be the "right" way - please correct if necessary! >> It seems to work correctly, but there seems to be an easier fix: just >> NULL out the pointer to lset/rset, respectively. I'm patching the >> code this way, please test if you get a chance. > > Whoops - looks like I spoke too soon. After more testing, I've > realized that the same commit this patch applied to actually changed the > behaviour of the "+" operation in the slap_set_join() function when > operating on empty sets, and can cause errors. > > The attached proposed patch restores the original design. The difference > is minor, but can cause slapd to hang indefinitely on some sets, like > the one in the generic example below. > > I understand an element in a set can have 3 possible states: > 1) non-empty string (example: "cn=user,ou=people,dc=example,dc=com") > 2) empty string (example: "", BER_BVISEMPTY) > 3) NULL (BER_BVISNULL) > > Below I represent sets in {element1, element2} notation, to describe the > current behaviour (in HEAD) for slap_set_join on the '+' operation: > - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", > "TwoThree", "TwoFour"} > - {"One", "Two"} + {""} ==> {"One", "Two"} > - {"One", "Two"} + {NULL} ==> {"One", "Two"} Although sets lack a specification, I think this behavior is desirable in many cases: adding NULL is equivalent to adding EMPTY (""). > Consider the following set: > set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + > [??<scope>?<filter2>]" > > Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this > works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no > entries, this value is NULL. Therefore, the rest of the set becomes: > "[ldap:///] + {NULL} + [??<scope>?<filter2>]" > ...which is handed to the '+' operation in slap_set_join, to become: > [ldap:///??<scope>?<filter2>] > ...which obviously isn't valid. Well, it is valid: it's an URI with an EMPTY DN. > The attached patch changes the last case of the current behaviour for > slap_set_join on the '+' operation. This was already the behaviour > before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: > - {"One", "Two"} + {NULL} ==> {NULL} This is different from the above behavior, although it makes sense on its own. Probably we need two different addition operators: one inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies the concatenation). Comments? 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(a)sys-net.it ---------------------------------------

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by dhawes＠vt.edu 09 Nov '07

09 Nov '07

On Friday 27 July 2007 05:20, ghenry(a)openldap.org wrote: > Hi David, > > http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ > > Will be pushed out in the next 2.4 beta. > > Please bear in mind that you will be looking after this overlay, so test > as often as you can and re-submit and changes during our release cycle. > > Thank you for your contribution. Changes to work properly with 2.4.6 are at: ftp://ftp.openldap.org/incoming/david_hawes-addpartial-071109.tgz Thanks, dave

1 0

Re: (ITS#5226) ldapadd: invalid format (line 1) entry: ""
by quanah＠zimbra.com 09 Nov '07

09 Nov '07

--On Thursday, November 08, 2007 11:59 PM +0000 babu.shanmugham(a)gmail.com wrote: > Full_Name: Babu Shanmugam > Version: 2.1 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.230.0.45) > > > Hey, > I am stuck u with this error....ldapadd: invalid format (line 1) entry: > "".... > > I am not sure which file to change, either init.ldif or slapd.conf. My > files contents looks like below. > > 1..slapd.conf. > > database bdb > suffix "dc=mymozilla,dc=com" > rootdn "cn=Manager,dc=mymozilla,dc=com" > rootpw passmozilla > directory C:/openldap/var/openldap-data > index objectClass eq > > 2. init.ldif : > > dn: dc=mymozilla,dc=com > objectClass: eq > objectClass: organization > objectClass: eq > description: Description of your domain > o: Something else about your domain > dc: mymozilla > > When i run this command, ldapadd -x -D "cn=Manager,dc=mymozilla,dc=com" -w > passmozilla -v -f init.ldif , i get the following error > > init.ldif > ldap_initialize( <DEFAULT> ) > ldapadd: invalid format (line 1) entry: "" Usage questions should be directed to openldap-software(a)openldap.org In answer to your question, your "objectClass" lines are very wrong. There is no objectClass named "eq", and you shouldn't have duplicate objectClass lines. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5227) old dsn acceptance
by aej＠wpi.edu 09 Nov '07

09 Nov '07

Full_Name: Allan E. Johannesen Version: 2.4.6 OS: Linux EL 4 URL: http://users.wpi.edu/~aej/schema_init.diff Submission from: (NULL) (130.215.24.208) Old CSN stamps are not accepted by 2.4.6. I guess they must be _very_ old, since there is a "2/3" CSN conversion in the release. The stamps are of the form: YYYYMMDDHH:MM:SSZ Perhaps I'm the only person in the OpenLDAP universe who might see this problem, but I adapted the 2/3 conversion for these old fields.

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2007