From michael at stroeder.com Tue Oct 11 16:50:54 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 11 Oct 2011 16:50:54 +0200 Subject: [python-ldap] python-ldap 2.4.x packages in Linux distributions? Message-ID: <4E9457CE.5030006@stroeder.com> HI! Hopefully some package maintainers of Linux distributions are reading here. Are there any obstacles upgrading python-ldap packages in your Linux distribution? If yes, which one? I'm asking because there are some new features in python-ldap 2.4.x (more sophisticated LDAPv3 controls) which are crucial for some applications. Ciao, Michael. From pakraticus at gmail.com Tue Oct 11 18:48:15 2011 From: pakraticus at gmail.com (Christopher Dukes) Date: Tue, 11 Oct 2011 12:48:15 -0400 Subject: [python-ldap] python-ldap 2.4.x packages in Linux distributions? In-Reply-To: <4E9457CE.5030006@stroeder.com> References: <4E9457CE.5030006@stroeder.com> Message-ID: <1318351695.7191.150.camel@pakrat-6223> On Tue, 2011-10-11 at 16:50 +0200, Michael Str?der wrote: > HI! > > Hopefully some package maintainers of Linux distributions are reading here. > > Are there any obstacles upgrading python-ldap packages in your Linux > distribution? If yes, which one? > > I'm asking because there are some new features in python-ldap 2.4.x (more > sophisticated LDAPv3 controls) which are crucial for some applications. Add the new features you need. Just keep the old versions available. Be clear in your documentation about the minimum version of openldap and python you are using with your newer work. I would also encourage you to assert those (or slightly more liberal) minimums in setup.py. I'm going to be stuck with python-2.4.3 on my RHEL5 systems for the foreseeable future. As long as the latest version of python-ldap that supports python-2.4.3 and openldap-2.4.23 is available for download, that's fine. I'm stuck with python-2.6.2 and openldap-2.4.23 on AIX for the foreseeable future. Again, as long as the latest version of python-ldap that works with both is available for download, that's fine. I do maintain python-ldap RPMs for AIX for my employer. And if you do choose to assert a minimum version of openldap, keep in mind that ctypes don't work on AIX. I'm also stuck with python-2.6.6 and openldap-2.4.23 on RHEL6 systems for the foreseeable future. I'll let the ubuntu, debian, and SLES folks pipe up with what minimum versions they'll be stuck with for a while. So my questions are. Do you want to continue supporting python-ldap on python 2.5 and earlier? As python 2.7 is the last python 2.x, do you want to start work on porting to python 3.x? > > Ciao, Michael. > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap From mailinglist0 at skurfer.com Thu Oct 13 15:43:19 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Thu, 13 Oct 2011 09:43:19 -0400 Subject: [python-ldap] python-ldap 2.4.x packages in Linux distributions? In-Reply-To: <1318351695.7191.150.camel@pakrat-6223> References: <4E9457CE.5030006@stroeder.com> <1318351695.7191.150.camel@pakrat-6223> Message-ID: <983C5598-CB05-473E-A439-4F84F8915892@skurfer.com> On Oct 11, 2011, at 12:48 PM, Christopher Dukes wrote: > I'm going to be stuck with python-2.4.3 on my RHEL5 systems for the foreseeable future. As long as the latest version of python-ldap that supports python-2.4.3 and openldap-2.4.23 is available for download, that's fine. Same here, but since Red Hat provides a python-ldap package (2.2.0), I imagine that?s what most people on these systems will end up using. Same with RHEL6, which includes 2.3.10. I guess I?m saying I wouldn?t worry *too* much about breaking things for RHEL users since 1. They will always have access to a working version from RHN 2. Policy might require them to stick with Red Hat provided/supported versions of things 3. If we?re using RHEL, having the latest versions of things clearly isn?t a priority :) > I'm stuck with python-2.6.2 and openldap-2.4.23 on AIX for the foreseeable future. Aren?t you ?stuck? with whatever you?re willing to build yourself? It?s not as though IBM provides useful packages or a way to install them. (I?m honestly asking. We recently acquired a bunch of AIX systems, so if there?s an easier way to install things and their dependencies, I?d like to know.) -- Rob McBroom From chris.dukes.aix at gmail.com Thu Oct 13 21:03:36 2011 From: chris.dukes.aix at gmail.com (Christopher Dukes) Date: Thu, 13 Oct 2011 15:03:36 -0400 Subject: [python-ldap] python-ldap 2.4.x packages in Linux distributions? In-Reply-To: <983C5598-CB05-473E-A439-4F84F8915892@skurfer.com> References: <4E9457CE.5030006@stroeder.com> <1318351695.7191.150.camel@pakrat-6223> <983C5598-CB05-473E-A439-4F84F8915892@skurfer.com> Message-ID: <1318532616.4386.34.camel@pakrat-6223> On Thu, 2011-10-13 at 09:43 -0400, Rob McBroom wrote: > On Oct 11, 2011, at 12:48 PM, Christopher Dukes wrote: > > > I'm going to be stuck with python-2.4.3 on my RHEL5 systems for the foreseeable future. As long as the latest version of python-ldap that supports python-2.4.3 and openldap-2.4.23 is available for download, that's fine. > > Same here, but since Red Hat provides a python-ldap package (2.2.0), I imagine that?s what most people on these systems will end up using. Same with RHEL6, which includes 2.3.10. I end up using python-virtualenv quite a bit. The last time I checked python-ldap works quite nicely built in a virtualenv, and I readily use that for anything other than python-ssl (refuses to install in the right locations in the virtualenv) and PIL (Just too much pain to build). > > I guess I?m saying I wouldn?t worry *too* much about breaking things for RHEL users since > > 1. They will always have access to a working version from RHN > 2. Policy might require them to stick with Red Hat provided/supported versions of things > 3. If we?re using RHEL, having the latest versions of things clearly isn?t a priority :) As I said, I use virtualenv, so within policy I can go newer. The same is the case for many people using buildout schemes for whole application deployment. My remark was more in reference to the sudden disappearance of older versions of python-ldap from pypi.org shortly after python-ldap 2.4 was released. *IF* there are significant API changes, python-ldap-2.4.3 needs to remain on pypi. > > > I'm stuck with python-2.6.2 and openldap-2.4.23 on AIX for the foreseeable future. > > Aren?t you ?stuck? with whatever you?re willing to build yourself? It?s not as though IBM provides useful packages or a way to install them. (I?m honestly asking. We recently acquired a bunch of AIX systems, so if there?s an easier way to install things and their dependencies, I?d like to know.) Let me introduce you to perzl.org. Mike Perzl is very helpful in keeping fairly up to date RPMs available for AIX. It's enough that it's not too painful having AIMP (AIX IHS Mysql PHP/Python) stacks for folks expecting LAMP stacks. My general policy is "If it isn't available as LPP, RPM, Install Shield Multi Platform, or easy_install/pip, it won't be installed on AIX." We have a bus factor of 1 for porting fedora RPMs to AIX, a bus factor of 3 for abusing setuptools to create an RPM, and a bus factor of 5 or 6 for installing from pre-packaged software. > From pietro at bertera.it Mon Oct 24 12:32:33 2011 From: pietro at bertera.it (Pietro Bertera) Date: Mon, 24 Oct 2011 12:32:33 +0200 Subject: [python-ldap] Sizelimit in search Message-ID: Hi all, Using python-ldap I realized that option OPT_SIZELIMIT during search are ignored. There is a mistake in my code or OPT_SIZELIMIT is unimplemented in search ? How can I limit the search results without using paging searches ? Best regards, -- Bertera Pietro http://www.bertera.it From michael at stroeder.com Mon Oct 24 20:55:03 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 24 Oct 2011 20:55:03 +0200 Subject: [python-ldap] Sizelimit in search In-Reply-To: References: Message-ID: <4EA5B487.7060808@stroeder.com> Pietro Bertera wrote: > Using python-ldap I realized that option OPT_SIZELIMIT during search > are ignored. > There is a mistake in my code or OPT_SIZELIMIT is unimplemented in search ? > > How can I limit the search results without using paging searches ? Use the key-word argument sizelimit: http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext If you actually want to retrieve the partial results until ldap.SIZELIMIT_EXCEEDED is raised you have to use the async search method and retrieve the results as they come. You also might want to use ldap.resiter for that. http://www.python-ldap.org/doc/html/ldap-resiter.html Ciao, Michael. From pietro at bertera.it Mon Oct 24 21:55:32 2011 From: pietro at bertera.it (Pietro Bertera) Date: Mon, 24 Oct 2011 21:55:32 +0200 Subject: [python-ldap] Sizelimit in search In-Reply-To: <4EA5B487.7060808@stroeder.com> References: <4EA5B487.7060808@stroeder.com> Message-ID: Hi Michael, 2011/10/24 Michael Str?der : > > Use the key-word argument sizelimit: > > http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext Ok, many thanks. IMHO the documentation about this creates a bit 'of confusion: http://www.python-ldap.org/doc/html/ldap.html#options OPT_SIZELIMIT is listed in options settable via ldap.set_option() > If you actually want to retrieve the partial results until > ldap.SIZELIMIT_EXCEEDED is raised you have to use the async search method and > retrieve the results as they come. You also might want to use ldap.resiter for > that. Yes, resiter is very cool. I'm grateful for your work in python-ldap library: a beautiful piece of code. Regards, -- Bertera Pietro http://www.bertera.it From michael at stroeder.com Mon Oct 24 22:16:54 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 24 Oct 2011 22:16:54 +0200 Subject: [python-ldap] Sizelimit in search In-Reply-To: References: <4EA5B487.7060808@stroeder.com> Message-ID: <4EA5C7B6.8030008@stroeder.com> Pietro Bertera wrote: > IMHO the documentation about this creates a bit 'of confusion: > http://www.python-ldap.org/doc/html/ldap.html#options > OPT_SIZELIMIT is listed in options settable via ldap.set_option() Hmm, yes. This part is very closely modeled after the C API which is even considered broken by hardcore C programmers. :-/ Ciao, Michael. From cmikk at qwest.net Tue Oct 25 22:21:57 2011 From: cmikk at qwest.net (Chris Mikkelson) Date: Tue, 25 Oct 2011 15:21:57 -0500 Subject: [python-ldap] Memory leak fixes. Message-ID: <20111025202157.GA82884@uerige.oss.uswest.net> Two patches attached. The first cleans up a previously-leaked object in a few exception cases. The second fixes a leak of an empty list for every intermediate message, which was causing trouble in a long-running ldap sync client. -- Chris Mikkelson | That is a form of errant pedantry up with which cmikk at qwest.net | I will not put. | -- Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixed-cases-where-references-were-not-being-decremen.patch Type: text/x-diff Size: 1714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fixed-a-leak-of-PyList-objects.patch Type: text/x-diff Size: 1084 bytes Desc: not available URL: From michael at stroeder.com Wed Oct 26 20:38:41 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 26 Oct 2011 20:38:41 +0200 Subject: [python-ldap] Memory leak fixes. In-Reply-To: <20111025202157.GA82884@uerige.oss.uswest.net> References: <20111025202157.GA82884@uerige.oss.uswest.net> Message-ID: <4EA853B1.4030403@stroeder.com> Chris, Chris Mikkelson wrote: > Two patches attached. > > The first cleans up a previously-leaked object in a few > exception cases. > > The second fixes a leak of an empty list for every > intermediate message, which was causing trouble in > a long-running ldap sync client. many thanks for the patches. I'm also observing growing memory in my long-running web2ldap demo service. I've committed these patches in CVS HEAD. So please everybody should test and report problems. Ciao, Michael. From michael at stroeder.com Wed Oct 26 21:02:04 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 26 Oct 2011 21:02:04 +0200 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110803152452.GA37837@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E37A73E.3040604@stroeder.com> <20110802142404.GA33550@uerige.oss.uswest.net> <20110803152452.GA37837@uerige.oss.uswest.net> Message-ID: <4EA8592C.8010308@stroeder.com> Chris Mikkelson wrote: > Patch attached. > > Demo script also attached. It "mirrors" the DNs of entries > matching a search into a dbm, and prints out its updates. I'm currently testing your module ldap.syncrepl with a slightly modified demo script. Especially I'm interested in refreshAndPersist mode. This seems to work for Modify Requests performed in the provider. But in case of Add, ModRDN and Delete Requests at least the demo does not produce what I'd expect. But maybe it's just me. I will further test it. Anyway I've committed your code (with small clean-ups) to CVS HEAD will release this as experimental addition along with 2.4.4 since it does not affect the rest of python-ldap and we'll see what progress this makes. Ciao, Michael. From michael at stroeder.com Wed Oct 26 20:44:21 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 26 Oct 2011 20:44:21 +0200 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110803152452.GA37837@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E37A73E.3040604@stroeder.com> <20110802142404.GA33550@uerige.oss.uswest.net> <20110803152452.GA37837@uerige.oss.uswest.net> Message-ID: <4EA85505.4080209@stroeder.com> Chris Mikkelson wrote: > Patch attached. > > Demo script also attached. It "mirrors" the DNs of entries > matching a search into a dbm, and prints out its updates. I'm currently testing your module ldap.syncrepl with a slightly modified demo script. Especially I'm interested in refreshAndPersist mode. This seems to work for Modify Requests performed in the provider. But in case of Add, ModRDN and Delete Requests at least the demo does not produce what I'd expect. But maybe it's just me. I will further test it. Anyway I've committed your code (with small clean-ups) to CVS HEAD will release this as experimental addition along with 2.4.4 since it does not affect the rest of python-ldap and we'll see what progress this makes. Ciao, Michael. From michael at stroeder.com Wed Oct 26 20:58:47 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 26 Oct 2011 20:58:47 +0200 Subject: [python-ldap] LDAP Sync (RFC 4533) support In-Reply-To: <20110803152452.GA37837@uerige.oss.uswest.net> References: <20110727215025.GA11995@uerige.oss.uswest.net> <4E37A73E.3040604@stroeder.com> <20110802142404.GA33550@uerige.oss.uswest.net> <20110803152452.GA37837@uerige.oss.uswest.net> Message-ID: <4EA85867.5070104@stroeder.com> Chris Mikkelson wrote: > Patch attached. > > Demo script also attached. It "mirrors" the DNs of entries > matching a search into a dbm, and prints out its updates. I'm currently testing your module ldap.syncrepl with a slightly modified demo script. Especially I'm interested in refreshAndPersist mode. This seems to work for Modify Requests performed in the provider. But in case of Add, ModRDN and Delete Requests at least the demo does not produce what I'd expect. But maybe it's just me. I will further test it. Anyway I've committed your code (with small clean-ups) to CVS HEAD will release this as experimental addition along with 2.4.4 since it does not affect the rest of python-ldap and we'll see what progress this makes. Ciao, Michael. From michael at stroeder.com Wed Oct 26 21:48:46 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 26 Oct 2011 21:48:46 +0200 Subject: [python-ldap] ANN: python-ldap 2.4.4 Message-ID: <4EA8641E.3070602@stroeder.com> Find a new release of python-ldap: http://pypi.python.org/pypi/python-ldap/2.4.4 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Project's web site: http://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.4 2011-10-26 Changes since 2.4.3: Modules/ * Format intermediate messages as 3-tuples instead of 4-tuples to match the format of other response messages. (thanks to Chris Mikkelson) * Fixes for memory leaks (thanks to Chris Mikkelson) Lib/ * New experimental(!) sub-module ldap.syncrepl implementing syncrepl consumer (see RFC 4533, thanks to Chris Mikkelson) Doc/ * Cleaned up rst files * Added missing classes From mmdonley at aol.com Fri Oct 28 23:11:58 2011 From: mmdonley at aol.com (MURL DONLEY) Date: Fri, 28 Oct 2011 17:11:58 -0400 Subject: [python-ldap] Macintosh Installation Message-ID: <2115A83B-743F-4ECE-92B2-412DAFC9A09A@aol.com> Any advice appreciated. I have an Intel MacBook Core2Duo running Mac OS X 10.5.8 Leopard. Other relevant installs: cyrus-sasl2 @2.1.23_3+kerberos openldap @2.4.21_4 openssl @1.0.0e_1 python27 @2.7.2_1 I want to install python-ldap-2.4.4 I do not see the relevant info to modify setup.cfg in the expanded tarball. I have looked at the samples in the Build folder, but am not satisfied that I know enough to proceed with: python setup.py build python setup.py install I can see that I need to make the following changes: library_dirs = /opt/local/lib/sasl2 include_dirs = /opt/local/include/sasl to link to the cyrus-sasl2 libraries, but I don't know what other steps are needed/advised. Thanks, MD -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglist0 at skurfer.com Sat Oct 29 12:03:10 2011 From: mailinglist0 at skurfer.com (Rob McBroom) Date: Sat, 29 Oct 2011 06:03:10 -0400 Subject: [python-ldap] Macintosh Installation In-Reply-To: <2115A83B-743F-4ECE-92B2-412DAFC9A09A@aol.com> References: <2115A83B-743F-4ECE-92B2-412DAFC9A09A@aol.com> Message-ID: On Oct 28, 2011, at 5:11 PM, MURL DONLEY wrote: > I want to install python-ldap-2.4.4 > I do not see the relevant info to modify setup.cfg in the expanded tarball. > I have looked at the samples in the Build folder, but am not satisfied that > I know enough to proceed with: > > python setup.py build > python setup.py install One problem you?re sure to run into is that /usr/lib/libldap_r.dylib is very old. Too old for python-ldap-2.4.4. I figured out how to do this in 10.7 and I?ve heard from others that it works for 10.6 as well. http://projects.skurfer.com/posts/2011/python_ldap_lion/ I?m not sure about 10.5, but maybe it?s close enough. For instance, the `-arch x86_64` might not be necessary. You can run `file /usr/local/lib/libldap.dylib` after building OpenLDAP to see if it?s 32 or 64 bit. -- Rob McBroom From lanjelot at gmail.com Fri Nov 4 16:13:14 2011 From: lanjelot at gmail.com (lanjelot) Date: Fri, 4 Nov 2011 16:13:14 +0100 Subject: [python-ldap] How to use the PasswordPolicy Control Message-ID: How to use the PasswordPolicy Control Hi list, When I provide a PasswordPolicyControl during a bind(), I fail to understand how to read the PasswordPolicy response. Below is the code: import sys import ldap from ldap.controls.ppolicy import PasswordPolicyControl binddn = 'cn=mec,dc=blah,dc=com' bindpw = 'password1' pwctrl = PasswordPolicyControl() l = ldap.initialize('ldap://localhost') l.set_option(ldap.OPT_SERVER_CONTROLS, [pwctrl]) try: msgid = l.simple_bind_s(binddn, bindpw, serverctrls=[pwctrl]) except ldap.LDAPError as e: print 'exc:', sys.exc_info() r = l.get_option(ldap.OPT_SERVER_CONTROLS) Below is its execution output: $ python edit.py exc: (, INVALID_CREDENTIALS({'desc': 'Invalid credentials'},), ) Traceback (most recent call last): File "edit.py", line 14, in r = l.get_option(ldap.OPT_SERVER_CONTROLS) File "/usr/lib/python2.6/site-packages/ldap/ldapobject.py", line 600, in get_option result = DecodeControlTuples(result) File "/usr/lib/python2.6/site-packages/ldap/controls/__init__.py", line 141, in DecodeControlTuples control.decodeControlValue(encodedControlValue) File "/usr/lib/python2.6/site-packages/ldap/controls/ppolicy.py", line 65, in decodeControlValue ppolicyValue,_ = decoder.decode(encodedControlValue,asn1Spec=PasswordPolicyResponseValue()) File "/usr/lib/python2.6/site-packages/pyasn1/codec/ber/decoder.py", line 560, in __call__ 'Short octet stream on tag decoding' pyasn1.error.SubstrateUnderrunError: Short octet stream on tag decoding I get the same error with python-ldap-2.4.3 or python-ldap-2.4.4. And I am sure that my openldap-2.4.24 server is properly setup because I do get the "Account locked" message as expected when using ldapsearch: $ ldapsearch -h 127.0.0.1 -D 'cn=joe,dc=blah,dc=com' -w bad_password -e ppolicy ldap_bind: Invalid credentials (49); Account locked What am i missing? From michael at stroeder.com Fri Nov 4 18:07:49 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 04 Nov 2011 18:07:49 +0100 Subject: [python-ldap] How to use the PasswordPolicy Control In-Reply-To: References: Message-ID: <4EB41BE5.3010008@stroeder.com> lanjelot wrote: > How to use the PasswordPolicy Control > > When I provide a PasswordPolicyControl during a bind(), I fail to > understand how to read the PasswordPolicy response. IMO this code is not usable yet. Further work is needed in this area. The main problem is that in case of an error an exception is raised by python-ldap and the response control is not tied to the exception. I'm not sure the response control is even extracted from the LDAP PDU. > l.set_option(ldap.OPT_SERVER_CONTROLS, [pwctrl]) This is not needed (and I somewhat doubt it works). > msgid = l.simple_bind_s(binddn, bindpw, serverctrls=[pwctrl]) That's correct. > except ldap.LDAPError as e: > print 'exc:', sys.exc_info() > r = l.get_option(ldap.OPT_SERVER_CONTROLS) I doubt that's really usable especially since it's not thread-safe. Ciao, Michael. From bmccann at andmore.com Fri Nov 11 16:57:33 2011 From: bmccann at andmore.com (McCann, Brian) Date: Fri, 11 Nov 2011 10:57:33 -0500 Subject: [python-ldap] Issues installing py-ldap2 Message-ID: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> Hi all. I've spent a few hours trying to figure this out and it's driving me nutty. I have one FreeBSD "ports" machine I build packages on, then install those packages on all my various servers (of the same OS version. In this case, FreeBSD 6.2) On that machine, I've built and packaged py-ldap2 without issue. When I try to install that package on another machine, it fails. Here's the output of the pkg_add (story continues after output): ---Start--- extra_compile_args: -g extra_objects: include_dirs: /opt/openldap-RE24/include /usr/include/sasl library_dirs: /opt/openldap-RE24/lib libs: ldap_r lber sasl2 ssl crypto file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found warning: no files found matching 'Makefile' warning: no files found matching 'Modules/LICENSE' file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found file Lib/ldap.py (for module ldap) not found file Lib/ldap/controls.py (for module ldap.controls) not found file Lib/ldap/extop.py (for module ldap.extop) not found file Lib/ldap/schema.py (for module ldap.schema) not found In file included from Modules/LDAPObject.c:9: Modules/errors.h:8:18: lber.h: No such file or directory Modules/errors.h:9:18: ldap.h: No such file or directory In file included from Modules/LDAPObject.c:9: Modules/errors.h:12: error: syntax error before '*' token In file included from Modules/LDAPObject.c:11: Modules/LDAPObject.h:12:2: #error Current python-ldap requires OpenLDAP 2.x In file included from Modules/LDAPObject.c:11: Modules/LDAPObject.h:23: error: syntax error before "LDAP" Modules/LDAPObject.h:31: error: syntax error before '*' token In file included from Modules/LDAPObject.c:12: Modules/ldapcontrol.h:11: error: syntax error before '*' token Modules/ldapcontrol.h:12: error: syntax error before "LDAPControl" Modules/ldapcontrol.h:13: error: syntax error before '*' token In file included from Modules/LDAPObject.c:13: Modules/message.h:11: error: syntax error before '*' token In file included from Modules/LDAPObject.c:14: Modules/berval.h:10: warning: "struct berval" declared inside parameter list Modules/berval.h:10: warning: its scope is only this definition or declaration, which is probably not what you want Modules/berval.h:12: warning: "struct berval" declared inside parameter list Modules/berval.h:13: warning: "struct berval" declared inside parameter list Modules/LDAPObject.c:18:18: sasl.h: No such file or directory Modules/LDAPObject.c:26: error: syntax error before '*' token Modules/LDAPObject.c: In function `newLDAPObject': Modules/LDAPObject.c:31: error: structure has no member named `ldap' Modules/LDAPObject.c:31: error: `l' undeclared (first use in this function) Modules/LDAPObject.c:31: error: (Each undeclared identifier is reported only once Modules/LDAPObject.c:31: error: for each function it appears in.) Modules/LDAPObject.c: In function `dealloc': Modules/LDAPObject.c:42: error: structure has no member named `ldap' Modules/LDAPObject.c:45: error: structure has no member named `ldap' Modules/LDAPObject.c:49: error: structure has no member named `ldap' Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:76: error: syntax error before '*' token Modules/LDAPObject.c: In function `LDAPMod_DEL': Modules/LDAPObject.c:80: error: `lm' undeclared (first use in this function) Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:103: error: syntax error before '*' token Modules/LDAPObject.c: In function `Tuple_to_LDAPMod': Modules/LDAPObject.c:109: error: `LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:109: error: `lm' undeclared (first use in this function) Modules/LDAPObject.c:127: error: syntax error before ')' token Modules/LDAPObject.c:131: error: `LDAP_MOD_BVALUES' undeclared (first use in this function) Modules/LDAPObject.c:147: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:147: warning: division by zero Modules/LDAPObject.c:147: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:147: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:147: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:159: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:159: warning: division by zero Modules/LDAPObject.c:159: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:159: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c:159: error: invalid application of `sizeof' to incomplete type `berval' Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:194: error: syntax error before '*' token Modules/LDAPObject.c: In function `LDAPMods_DEL': Modules/LDAPObject.c:195: error: `LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:195: error: `lmp' undeclared (first use in this function) Modules/LDAPObject.c:196: error: `lms' undeclared (first use in this function) Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:206: error: syntax error before '*' token Modules/LDAPObject.c: In function `List_to_LDAPMods': Modules/LDAPObject.c:210: error: `LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:210: error: `lms' undeclared (first use in this function) Modules/LDAPObject.c:227: error: syntax error before ')' token Modules/LDAPObject.c:227: error: syntax error before ')' token Modules/LDAPObject.c:227: error: syntax error before ')' token Modules/LDAPObject.c:227: error: syntax error before ')' token Modules/LDAPObject.c:227: error: syntax error before ')' token Modules/LDAPObject.c: In function `l_ldap_unbind_ext': Modules/LDAPObject.c:332: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:332: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:333: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:351: error: structure has no member named `ldap' Modules/LDAPObject.c:357: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:358: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_abandon_ext': Modules/LDAPObject.c:373: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:373: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:374: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:392: error: structure has no member named `ldap' Modules/LDAPObject.c:398: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:399: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_add_ext': Modules/LDAPObject.c:414: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:414: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:415: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:419: error: `LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:419: error: `mods' undeclared (first use in this function) Modules/LDAPObject.c:439: error: structure has no member named `ldap' Modules/LDAPObject.c:445: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:446: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_simple_bind': Modules/LDAPObject.c:462: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:462: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:463: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:464: error: storage size of 'cred' isn't known Modules/LDAPObject.c:467: error: `ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:467: error: syntax error before "cred_len" Modules/LDAPObject.c:482: error: structure has no member named `ldap' Modules/LDAPObject.c:482: error: `LDAP_SASL_SIMPLE' undeclared (first use in this function) Modules/LDAPObject.c:488: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:489: error: structure has no member named `ldap' Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:553: error: syntax error before "sasl_interact_t" Modules/LDAPObject.c: In function `interaction': Modules/LDAPObject.c:559: error: `SASLObject' undeclared (first use in this function) Modules/LDAPObject.c:562: error: `interact' undeclared (first use in this function) Modules/LDAPObject.c:569: error: `LDAP_OPERATIONS_ERROR' undeclared (first use in this function) Modules/LDAPObject.c:589: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c: At top level: Modules/LDAPObject.c:601: error: syntax error before '*' token Modules/LDAPObject.c: In function `py_ldap_sasl_interaction': Modules/LDAPObject.c:607: error: `sasl_interact_t' undeclared (first use in this function) Modules/LDAPObject.c:607: error: `interact' undeclared (first use in this function) Modules/LDAPObject.c:607: error: syntax error before ')' token Modules/LDAPObject.c:608: error: `defaults' undeclared (first use in this function) Modules/LDAPObject.c:610: error: `SASL_CB_LIST_END' undeclared (first use in this function) Modules/LDAPObject.c:612: error: `flags' undeclared (first use in this function) Modules/LDAPObject.c:616: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c: In function `l_ldap_sasl_interactive_bind_s': Modules/LDAPObject.c:627: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:627: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:628: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:634: error: `LDAP_SASL_QUIET' undeclared (first use in this function) Modules/LDAPObject.c:674: error: structure has no member named `ldap' Modules/LDAPObject.c:677: error: syntax error before ')' token Modules/LDAPObject.c:686: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:687: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_compare_ext': Modules/LDAPObject.c:745: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:745: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:746: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:751: error: storage size of 'value' isn't known Modules/LDAPObject.c:754: error: `ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:754: error: syntax error before "value_len" Modules/LDAPObject.c:769: error: structure has no member named `ldap' Modules/LDAPObject.c:775: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:776: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_delete_ext': Modules/LDAPObject.c:790: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:790: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:791: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:810: error: structure has no member named `ldap' Modules/LDAPObject.c:816: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:817: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_modify_ext': Modules/LDAPObject.c:832: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:832: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:833: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:837: error: `LDAPMod' undeclared (first use in this function) Modules/LDAPObject.c:837: error: `mods' undeclared (first use in this function) Modules/LDAPObject.c:857: error: structure has no member named `ldap' Modules/LDAPObject.c:864: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:865: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_rename': Modules/LDAPObject.c:881: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:881: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:882: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:902: error: structure has no member named `ldap' Modules/LDAPObject.c:908: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:909: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_result4': Modules/LDAPObject.c:920: error: `LDAP_RES_ANY' undeclared (first use in this function) Modules/LDAPObject.c:929: error: `LDAPMessage' undeclared (first use in this function) Modules/LDAPObject.c:929: error: `msg' undeclared (first use in this function) Modules/LDAPObject.c:947: error: structure has no member named `ldap' Modules/LDAPObject.c:951: error: structure has no member named `ldap' Modules/LDAPObject.c:963: error: `LDAP_TIMEOUT' undeclared (first use in this function) Modules/LDAPObject.c:969: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:971: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:971: error: `serverctrls' undeclared (first use in this function) Modules/LDAPObject.c:973: error: `LDAP_RES_SEARCH_ENTRY' undeclared (first use in this function) Modules/LDAPObject.c:975: error: `LDAP_RES_SEARCH_REFERENCE' undeclared (first use in this function) Modules/LDAPObject.c:977: error: `LDAP_RES_INTERMEDIATE' undeclared (first use in this function) Modules/LDAPObject.c:981: error: `LDAP_RES_EXTENDED' undeclared (first use in this function) Modules/LDAPObject.c:983: error: structure has no member named `ldap' Modules/LDAPObject.c:991: error: structure has no member named `ldap' Modules/LDAPObject.c:998: error: `LDAP_REFERRAL' undeclared (first use in this function) Modules/LDAPObject.c:1004: error: structure has no member named `ldap' Modules/LDAPObject.c:1008: error: `LDAP_NO_MEMORY' undeclared (first use in this function) Modules/LDAPObject.c:1009: error: structure has no member named `ldap' Modules/LDAPObject.c:1009: error: `LDAP_OPT_ERROR_NUMBER' undeclared (first use in this function) Modules/LDAPObject.c:1011: error: structure has no member named `ldap' Modules/LDAPObject.c:1015: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_search_ext': Modules/LDAPObject.c:1057: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1057: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1058: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1095: error: structure has no member named `ldap' Modules/LDAPObject.c:1103: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1104: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_whoami_s': Modules/LDAPObject.c:1117: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1117: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1118: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1139: error: structure has no member named `ldap' Modules/LDAPObject.c:1145: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1146: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_start_tls_s': Modules/LDAPObject.c:1164: error: structure has no member named `ldap' Modules/LDAPObject.c:1165: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1166: error: structure has no member named `ldap' Modules/LDAPObject.c:1166: error: `LDAP_OPT_ERROR_NUMBER' undeclared (first use in this function) Modules/LDAPObject.c:1167: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_passwd': Modules/LDAPObject.c:1211: error: storage size of 'user' isn't known Modules/LDAPObject.c:1213: error: storage size of 'oldpw' isn't known Modules/LDAPObject.c:1215: error: storage size of 'newpw' isn't known Modules/LDAPObject.c:1219: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1219: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1220: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1228: error: `ber_len_t' undeclared (first use in this function) Modules/LDAPObject.c:1228: error: syntax error before "user_len" Modules/LDAPObject.c:1229: error: syntax error before "oldpw_len" Modules/LDAPObject.c:1230: error: syntax error before "newpw_len" Modules/LDAPObject.c:1245: error: structure has no member named `ldap' Modules/LDAPObject.c:1257: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1258: error: structure has no member named `ldap' Modules/LDAPObject.c: In function `l_ldap_extended_operation': Modules/LDAPObject.c:1270: error: variable `reqvalue' has initializer but incomplete type Modules/LDAPObject.c:1270: warning: excess elements in struct initializer Modules/LDAPObject.c:1270: warning: (near initialization for `reqvalue') Modules/LDAPObject.c:1270: warning: excess elements in struct initializer Modules/LDAPObject.c:1270: warning: (near initialization for `reqvalue') Modules/LDAPObject.c:1270: error: storage size of 'reqvalue' isn't known Modules/LDAPObject.c:1273: error: `LDAPControl' undeclared (first use in this function) Modules/LDAPObject.c:1273: error: `server_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1274: error: `client_ldcs' undeclared (first use in this function) Modules/LDAPObject.c:1295: error: structure has no member named `ldap' Modules/LDAPObject.c:1305: error: `LDAP_SUCCESS' undeclared (first use in this function) Modules/LDAPObject.c:1306: error: structure has no member named `ldap' error: Setup script exited with error: command 'cc' failed with exit status 1 pkg_add: command '/usr/bin/env PYTHONPATH=/usr/local/lib/python2.7/site-packages /usr/local/bin/easy_install-2.7 -q -N -S /usr/local/lib/python2.7/site-packages -d /usr/local/lib/python2.7/site-packages -s /usr/local/bin python-ldap==2.4.3' failed ---End--- What's driving me bonkers and what I THINK is the cause of the problem is the "include_dirs: /opt/openldap-RE24/include /usr/include/sasl" and "library_dirs: /opt/openldap-RE24/lib". Those are just wrong. When I build the package, it uses "include_dirs: /usr/local/include /usr/include/sasl" and "library_dirs: /usr/local/lib". Those directories will get the installer to actually find the missing lber.h, etc. I un-tarballed the tbz file and grep'd through all the files looking for "RE24", and couldn't find where it's getting that include path from. Can someone please point me in the right direction here? Thanks, --Brian From chris.dukes.aix at gmail.com Fri Nov 11 17:28:35 2011 From: chris.dukes.aix at gmail.com (Christopher Dukes) Date: Fri, 11 Nov 2011 11:28:35 -0500 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> Message-ID: <1321028915.4386.146.camel@pakrat-6223> On Fri, 2011-11-11 at 10:57 -0500, McCann, Brian wrote: > Hi all. I've spent a few hours trying to figure this out and it's driving me nutty. > > I have one FreeBSD "ports" machine I build packages on, then install those packages on all my various servers (of the same OS version. In this case, FreeBSD 6.2) On that machine, I've built and packaged py-ldap2 without issue. When I try to install that package on another machine, it fails. Here's the output of the pkg_add (story continues after output): You clipped off what you ran to give all the error output of "Hey I can't find some really critical files." The command you ran to produce the error messages is more important than the error messages. [SNEEP of long crap indicating files not found] Anyways this isn't a python-ldap question so much as "How do I effectively distribute Ports on FreeBSD" Read the "pkg_add" manpage, drop down to the Environment section. Note the environment variables "PKG_PATH", "PACKAGEROOT", and "PACKAGESITE". For the clients installing packages you built... set those environment variables appropriately, and use 'pkg_add -r', or use portmaster with the appropriate options to use the remote or "local" repositories. If you need further assistance, seek abuse on the appropriate FreeBSD mailing list. > What's driving me bonkers and what I THINK is the cause of the problem is the "include_dirs: /opt/openldap-RE24/include /usr/include/sasl" and "library_dirs: /opt/openldap-RE24/lib". Those are just wrong. When I build the package, it uses "include_dirs: /usr/local/include /usr/include/sasl" and "library_dirs: /usr/local/lib". Those directories will get the installer to actually find the missing lber.h, etc. I un-tarballed the tbz file and grep'd through all the files looking for "RE24", and couldn't find where it's getting that include path from. > > Can someone please point me in the right direction here? > > Thanks, > --Brian > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap From bmccann at andmore.com Fri Nov 11 17:46:08 2011 From: bmccann at andmore.com (McCann, Brian) Date: Fri, 11 Nov 2011 11:46:08 -0500 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <1321028915.4386.146.camel@pakrat-6223> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> <1321028915.4386.146.camel@pakrat-6223> Message-ID: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> The command I ran was "pkg_add py27-ldap2-2.4.3.tbz". I ran it again with more verbose output...here's what it does. ---Start--- # pkg_add -v py27-ldap2-2.4.3.tbz Requested space: 600708 bytes, free space: 295809024 bytes in /var/tmp/instmp.8IEBP1 pkg_add: package ss_vpnclient.6.2-RELEASE-p7-08021918 has no origin recorded Package 'py27-ldap2-2.4.3' depends on 'openldap-client-2.4.26' with 'net/openldap24-client' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'python27-2.7.2_2' with 'lang/python27' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-setuptools-0.6c11_1' with 'devel/py-setuptools' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-asn1-0.0.13,1' with 'devel/py-asn1' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-asn1-modules-0.0.1a' with 'devel/py-asn1-modules' origin. - already installed. extract: Package name is py27-ldap2-2.4.3 extract: CWD to /usr/local extract: /usr/local/share/licenses/py27-ldap2-2.4.3/catalog.mk extract: /usr/local/share/licenses/py27-ldap2-2.4.3/LICENSE extract: /usr/local/share/licenses/py27-ldap2-2.4.3/PSFL extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/PKG-INFO extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/SOURCES.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/dependency_links.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/native_libs.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/not-zip-safe extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/requires.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/top_level.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.so extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.pyo extract: CWD to /usr/local extract: execute '/usr/bin/env PYTHONPATH=/usr/local/lib/python2.7/site-packages /usr/local/bin/easy_install-2.7 -q -N -S /usr/local/lib/python2.7/site-packages -d /usr/local/lib/python2.7/site-packages -s /usr/local/bin python-ldap==2.4.3' ---End--- After that execute line is where the previous paste comes in...so you could say easy_install is the program "causing" the error. I'm installing this package from a local file, not a remote repo or anything. I SCP'd the file from the machine I built the package on to the target machine. Something else that confuses me is why is easy_install even trying to compile anything at all. Based on the files the package extracted, it doesn't have any C code, nor can I even locate these "Modules/errors.h" etc files after I run pkg_add. I would THINK if easy_install was fetching them on its own from the Internet, it would say so in its output. Thanks --Brian -----Original Message----- From: Christopher Dukes [mailto:chris.dukes.aix at gmail.com] Sent: Friday, November 11, 2011 11:29 AM To: McCann, Brian Cc: python-ldap at python.org Subject: Re: [python-ldap] Issues installing py-ldap2 On Fri, 2011-11-11 at 10:57 -0500, McCann, Brian wrote: > Hi all. I've spent a few hours trying to figure this out and it's driving me nutty. > > I have one FreeBSD "ports" machine I build packages on, then install those packages on all my various servers (of the same OS version. In this case, FreeBSD 6.2) On that machine, I've built and packaged py-ldap2 without issue. When I try to install that package on another machine, it fails. Here's the output of the pkg_add (story continues after output): You clipped off what you ran to give all the error output of "Hey I can't find some really critical files." The command you ran to produce the error messages is more important than the error messages. [SNEEP of long crap indicating files not found] Anyways this isn't a python-ldap question so much as "How do I effectively distribute Ports on FreeBSD" Read the "pkg_add" manpage, drop down to the Environment section. Note the environment variables "PKG_PATH", "PACKAGEROOT", and "PACKAGESITE". For the clients installing packages you built... set those environment variables appropriately, and use 'pkg_add -r', or use portmaster with the appropriate options to use the remote or "local" repositories. If you need further assistance, seek abuse on the appropriate FreeBSD mailing list. > What's driving me bonkers and what I THINK is the cause of the problem is the "include_dirs: /opt/openldap-RE24/include /usr/include/sasl" and "library_dirs: /opt/openldap-RE24/lib". Those are just wrong. When I build the package, it uses "include_dirs: /usr/local/include /usr/include/sasl" and "library_dirs: /usr/local/lib". Those directories will get the installer to actually find the missing lber.h, etc. I un-tarballed the tbz file and grep'd through all the files looking for "RE24", and couldn't find where it's getting that include path from. > > Can someone please point me in the right direction here? > > Thanks, > --Brian > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap From bmccann at andmore.com Fri Nov 11 17:59:26 2011 From: bmccann at andmore.com (McCann, Brian) Date: Fri, 11 Nov 2011 11:59:26 -0500 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> <1321028915.4386.146.camel@pakrat-6223> <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> Message-ID: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BCA@hermod.andmore.com> Ok...my ignorance with easy_install is coming out here. I ran the easy_install line myself and took out the "-q", and I now see it downloading a package from pypi. Not totally sure WHY, but that's what it's doing. I think that's my problem, since the Makefile on FreeBSD sets-up setup.cfg with the correct include paths... --Brian -----Original Message----- From: python-ldap-bounces+bmccann=andmore.com at python.org [mailto:python-ldap-bounces+bmccann=andmore.com at python.org] On Behalf Of McCann, Brian Sent: Friday, November 11, 2011 11:46 AM To: Christopher Dukes Cc: python-ldap at python.org Subject: Re: [python-ldap] Issues installing py-ldap2 The command I ran was "pkg_add py27-ldap2-2.4.3.tbz". I ran it again with more verbose output...here's what it does. ---Start--- # pkg_add -v py27-ldap2-2.4.3.tbz Requested space: 600708 bytes, free space: 295809024 bytes in /var/tmp/instmp.8IEBP1 pkg_add: package ss_vpnclient.6.2-RELEASE-p7-08021918 has no origin recorded Package 'py27-ldap2-2.4.3' depends on 'openldap-client-2.4.26' with 'net/openldap24-client' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'python27-2.7.2_2' with 'lang/python27' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-setuptools-0.6c11_1' with 'devel/py-setuptools' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-asn1-0.0.13,1' with 'devel/py-asn1' origin. - already installed. Package 'py27-ldap2-2.4.3' depends on 'py27-asn1-modules-0.0.1a' with 'devel/py-asn1-modules' origin. - already installed. extract: Package name is py27-ldap2-2.4.3 extract: CWD to /usr/local extract: /usr/local/share/licenses/py27-ldap2-2.4.3/catalog.mk extract: /usr/local/share/licenses/py27-ldap2-2.4.3/LICENSE extract: /usr/local/share/licenses/py27-ldap2-2.4.3/PSFL extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/PKG-INFO extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/SOURCES.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/dependency_links.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/native_libs.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/not-zip-safe extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/requires.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/EGG-INFO/top_level.txt extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/_ldap.so extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/dsml.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/async.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/cidict.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/libldap.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/ppolicy.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/psearch.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/readentry.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/sessiontrack.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/controls/simple.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/dn.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/extop/dds.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/filter.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/functions.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/ldapobject.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/logger.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/modlist.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/resiter.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/sasl.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/__init__.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/models.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/subentry.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldap/schema/tokenizer.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldapurl.pyo extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.py extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.pyc extract: /usr/local/lib/python2.7/site-packages/python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg/ldif.pyo extract: CWD to /usr/local extract: execute '/usr/bin/env PYTHONPATH=/usr/local/lib/python2.7/site-packages /usr/local/bin/easy_install-2.7 -q -N -S /usr/local/lib/python2.7/site-packages -d /usr/local/lib/python2.7/site-packages -s /usr/local/bin python-ldap==2.4.3' ---End--- After that execute line is where the previous paste comes in...so you could say easy_install is the program "causing" the error. I'm installing this package from a local file, not a remote repo or anything. I SCP'd the file from the machine I built the package on to the target machine. Something else that confuses me is why is easy_install even trying to compile anything at all. Based on the files the package extracted, it doesn't have any C code, nor can I even locate these "Modules/errors.h" etc files after I run pkg_add. I would THINK if easy_install was fetching them on its own from the Internet, it would say so in its output. Thanks --Brian -----Original Message----- From: Christopher Dukes [mailto:chris.dukes.aix at gmail.com] Sent: Friday, November 11, 2011 11:29 AM To: McCann, Brian Cc: python-ldap at python.org Subject: Re: [python-ldap] Issues installing py-ldap2 On Fri, 2011-11-11 at 10:57 -0500, McCann, Brian wrote: > Hi all. I've spent a few hours trying to figure this out and it's driving me nutty. > > I have one FreeBSD "ports" machine I build packages on, then install those packages on all my various servers (of the same OS version. In this case, FreeBSD 6.2) On that machine, I've built and packaged py-ldap2 without issue. When I try to install that package on another machine, it fails. Here's the output of the pkg_add (story continues after output): You clipped off what you ran to give all the error output of "Hey I can't find some really critical files." The command you ran to produce the error messages is more important than the error messages. [SNEEP of long crap indicating files not found] Anyways this isn't a python-ldap question so much as "How do I effectively distribute Ports on FreeBSD" Read the "pkg_add" manpage, drop down to the Environment section. Note the environment variables "PKG_PATH", "PACKAGEROOT", and "PACKAGESITE". For the clients installing packages you built... set those environment variables appropriately, and use 'pkg_add -r', or use portmaster with the appropriate options to use the remote or "local" repositories. If you need further assistance, seek abuse on the appropriate FreeBSD mailing list. > What's driving me bonkers and what I THINK is the cause of the problem is the "include_dirs: /opt/openldap-RE24/include /usr/include/sasl" and "library_dirs: /opt/openldap-RE24/lib". Those are just wrong. When I build the package, it uses "include_dirs: /usr/local/include /usr/include/sasl" and "library_dirs: /usr/local/lib". Those directories will get the installer to actually find the missing lber.h, etc. I un-tarballed the tbz file and grep'd through all the files looking for "RE24", and couldn't find where it's getting that include path from. > > Can someone please point me in the right direction here? > > Thanks, > --Brian > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap _______________________________________________ python-ldap mailing list python-ldap at python.org http://mail.python.org/mailman/listinfo/python-ldap From chris.dukes.aix at gmail.com Fri Nov 11 18:19:12 2011 From: chris.dukes.aix at gmail.com (Christopher Dukes) Date: Fri, 11 Nov 2011 12:19:12 -0500 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> <1321028915.4386.146.camel@pakrat-6223> <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> Message-ID: <1321031952.4386.164.camel@pakrat-6223> On Fri, 2011-11-11 at 11:46 -0500, McCann, Brian wrote: > The command I ran was "pkg_add py27-ldap2-2.4.3.tbz". I ran it again with more verbose output...here's what it does. First and foremost... as you are running FreeBSD 6, no one actually cares. It's older than Legacy. Sorry. Second, none of your problems are actually with python-ldap. They are purely problems with your understanding of FreeBSD package management. 'pkg_add tarball' does not chase dependencies. 'pkg_add -r tarball' chases dependencies and sometimes gets them right. 'portmaster' and 'portupgrade' can chase dependencies correctly... but there is pain. > [SNEEP] > extract: execute '/usr/bin/env PYTHONPATH=/usr/local/lib/python2.7/site-packages /usr/local/bin/easy_install-2.7 -q -N -S /usr/local/lib/python2.7/site-packages -d /usr/local/lib/python2.7/site-packages -s /usr/local/bin python-ldap==2.4.3' > ---End--- > That's coming from USE_PYDISTUTILS=easy_install and ports/Mk/bsd.python.mk putting an @exec and @unexec in the +COMMENTS in the tarball. As for why they do that... Take it to a FreeBSD mailing list. If you want to do things right... either stick with the compiled ports that the FreeBSD community makes available, or use 'portmaster' or 'portupgrade' to manage your packages on your build server and use http or NFS or rsync to distribute built packages to your clients. Between the presence of FreeBSD 6 and your use of 'pkg_add tarball' I suspect that you have version control hell on your non-build server systems. > > After that execute line is where the previous paste comes in...so you could say easy_install is the program "causing" the error. > > I'm installing this package from a local file, not a remote repo or anything. I SCP'd the file from the machine I built the package on to the target machine. > > Something else that confuses me is why is easy_install even trying to compile anything at all. Based on the files the package extracted, it doesn't have any C code, nor can I even locate these "Modules/errors.h" etc files after I run pkg_add. I would THINK if easy_install was fetching them on its own from the Internet, it would say so in its output. And yet you've not bothered to see what {pre,post}-{un,}install scripts are in the package, nor to factor in any issues in package dependencies. It isn't like *install scripts are a new concept, I've been seeing them in package managers that were available in 1987. From bmccann at andmore.com Fri Nov 11 18:25:02 2011 From: bmccann at andmore.com (McCann, Brian) Date: Fri, 11 Nov 2011 12:25:02 -0500 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <1321031952.4386.164.camel@pakrat-6223> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> <1321028915.4386.146.camel@pakrat-6223> <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> <1321031952.4386.164.camel@pakrat-6223> Message-ID: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BCB@hermod.andmore.com> I was just in the process of replying. I discovered the root of the problem. The machine that builds the ports is FreeBSD 6.2-RELEASE. The machines the packages are getting installed on are 6.3-RELEASE-p7. Easy install is looking for an egg named "python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-P7.i386.egg" and failing, because the egg is really named "python_ldap-2.4.3-py2.7-freebsd-6.2-RELEASE-i386.egg". It's then going and doing a fresh download/install. Because the setup.cfg is "stock" with the wrong directories when using FreeBSD, it's barfing. Thanks for your help...off to work out a fix. --Brian -----Original Message----- From: Christopher Dukes [mailto:chris.dukes.aix at gmail.com] Sent: Friday, November 11, 2011 12:19 PM To: McCann, Brian Cc: python-ldap at python.org Subject: RE: [python-ldap] Issues installing py-ldap2 On Fri, 2011-11-11 at 11:46 -0500, McCann, Brian wrote: > The command I ran was "pkg_add py27-ldap2-2.4.3.tbz". I ran it again with more verbose output...here's what it does. First and foremost... as you are running FreeBSD 6, no one actually cares. It's older than Legacy. Sorry. Second, none of your problems are actually with python-ldap. They are purely problems with your understanding of FreeBSD package management. 'pkg_add tarball' does not chase dependencies. 'pkg_add -r tarball' chases dependencies and sometimes gets them right. 'portmaster' and 'portupgrade' can chase dependencies correctly... but there is pain. > [SNEEP] > extract: execute '/usr/bin/env PYTHONPATH=/usr/local/lib/python2.7/site-packages /usr/local/bin/easy_install-2.7 -q -N -S /usr/local/lib/python2.7/site-packages -d /usr/local/lib/python2.7/site-packages -s /usr/local/bin python-ldap==2.4.3' > ---End--- > That's coming from USE_PYDISTUTILS=easy_install and ports/Mk/bsd.python.mk putting an @exec and @unexec in the +COMMENTS in the tarball. As for why they do that... Take it to a FreeBSD mailing list. If you want to do things right... either stick with the compiled ports that the FreeBSD community makes available, or use 'portmaster' or 'portupgrade' to manage your packages on your build server and use http or NFS or rsync to distribute built packages to your clients. Between the presence of FreeBSD 6 and your use of 'pkg_add tarball' I suspect that you have version control hell on your non-build server systems. > > After that execute line is where the previous paste comes in...so you could say easy_install is the program "causing" the error. > > I'm installing this package from a local file, not a remote repo or anything. I SCP'd the file from the machine I built the package on to the target machine. > > Something else that confuses me is why is easy_install even trying to compile anything at all. Based on the files the package extracted, it doesn't have any C code, nor can I even locate these "Modules/errors.h" etc files after I run pkg_add. I would THINK if easy_install was fetching them on its own from the Internet, it would say so in its output. And yet you've not bothered to see what {pre,post}-{un,}install scripts are in the package, nor to factor in any issues in package dependencies. It isn't like *install scripts are a new concept, I've been seeing them in package managers that were available in 1987. From michael at stroeder.com Fri Nov 11 19:05:50 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 11 Nov 2011 19:05:50 +0100 Subject: [python-ldap] Issues installing py-ldap2 In-Reply-To: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BCB@hermod.andmore.com> References: <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC4@hermod.andmore.com> <1321028915.4386.146.camel@pakrat-6223> <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BC8@hermod.andmore.com> <1321031952.4386.164.camel@pakrat-6223> <249E65CE1FE3FE42B8E7D93EA3B1A9F301E3066D3BCB@hermod.andmore.com> Message-ID: <4EBD63FE.5040501@stroeder.com> McCann, Brian wrote: > Because the setup.cfg is "stock" with the wrong directories when using > FreeBSD, it's barfing. Originally every installer/packager was supposed to tweak setup.cfg to contain what's needed on a specific OS platform. So I did not take care of setting library_dirs and library_dirs to be ready for a wide range of platforms. But given PyPI and easy_install I'm willing to discuss a common setup.cfg shipped in the source distribution which special cases on most platforms. I'm aware that this can get very complicated alone for the various Linux distros. Ciao, Michael. From michael at stroeder.com Thu Nov 17 20:38:04 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 17 Nov 2011 20:38:04 +0100 Subject: [python-ldap] default setup.cfg for PyPI and setup tools Message-ID: <4EC5629C.1090609@stroeder.com> HI! I'm trying to improve the default setup.cfg shipped in python-ldap source distribution on PyPI to accomodate most platforms. The problems are: 1. There's no such thing like autoconf before. So the defines have to be set in advance without knowing something about the platform installation. 2. The OpenLDAP libs can be build with or without SASL and SSL/TLS support and there are currently three different SSL/TLS implementations supported (OpenSSL, libnss, GnuTLS). I've checked in a version of setup.cfg to CVS HEAD which directly contains the defines instead of deriving them from libs. Please test this on your platform. Especially Debian/Ubuntu with OpenLDAP libs linked against GnuTLS and Red Hat with OpenLDAP libs linked against libnss should test whether this works out of the box. Ciao, Michael. From tktucker at gmail.com Mon Nov 21 21:30:01 2011 From: tktucker at gmail.com (Tom Tucker) Date: Mon, 21 Nov 2011 15:30:01 -0500 Subject: [python-ldap] Capture Results Message-ID: How do I display the results from my last add, change or delete? I am missing something using the "result" method. Thank you in advance. l = ldap.initialize("ldap://localhost:389/") dn = "uid=%s,ou=people,dc=autotrader,dc=com" % (modifier) l.simple_bind_s( dn, modifier_passwd) dn="uid=%s,ou=People,dc=autotrader,dc=com" % (user_to_be_modified) mod_attrs = [ (ldap.MOD_REPLACE, attr, value)] execute_results = l.modify_s(dn, mod_attrs) result_type, result_data = l.result(execute_results, 0) l.unbind_s() -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Nov 21 21:41:11 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 21 Nov 2011 21:41:11 +0100 Subject: [python-ldap] Capture Results In-Reply-To: References: Message-ID: <4ECAB767.5070205@stroeder.com> Tom Tucker wrote: > > How do I display the results from my last add, change or delete? What result do you expect? The write operations usually do not return a meaningful result except you used a special LDAPv3 extended control before. > I am missing > something using the "result" method. > Thank you in advance. > > l = ldap.initialize("ldap://localhost:389/") > dn = "uid=%s,ou=people,dc=autotrader,dc=com" % (modifier) > l.simple_bind_s( dn, modifier_passwd) > dn="uid=%s,ou=People,dc=autotrader,dc=com" % (user_to_be_modified) > > mod_attrs = [ (ldap.MOD_REPLACE, attr, value)] > execute_results = l.modify_s(dn, mod_attrs) > result_type, result_data = l.result(execute_results, 0) You should make yourself more familiar with the difference of asynchronous call modify() and synchronous call modify_s(). See http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.modify Also in general the first note here: http://www.python-ldap.org/doc/html/ldap.html#sending-ldap-requests So when using execute_results = l.modify_s(dn, mod_attrs) the var execute_results contains the result (which is None) whereas execute_results = l.modify(dn, mod_attrs) the var execute_results contains the message ID to be used when calling l.result() afterwards as you did. Ciao, Michael. From amalinowski at cgr.harvard.edu Wed Nov 23 02:16:55 2011 From: amalinowski at cgr.harvard.edu (Malinowski, Adam) Date: Tue, 22 Nov 2011 20:16:55 -0500 Subject: [python-ldap] mutex bug in 2.4.4 Message-ID: <090BBF843CD9C749B53A37A86BAA263599BD53894C@FASXCH02.fasmail.priv> Hi, There appears to be a bug in stable 2.4.4 version of python-module when used in multi-threaded python environment. I haven't found any info on the mailing list about this, so I thought it should be reported. A different object is used in lock acquire() and release(), which leads to call to release() always fail, also other blocked callers could be stuck forever. Perhaps the change was never tested in multi-threaded python. Falling back to using the global module mutex lock seems to fix it. I suppose the desired behavior is to make sure the shared open ldap handle is used by a single module at a time. bash-4.1# diff -Nir Lib/ldap/functions-orig.py Lib/ldap/functions.py 52c52,53 < lock.acquire() --- > #lock.acquire() > ldap._ldap_module_lock.acquire() Thanks, Adam Malinowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Nov 23 12:24:54 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Wed, 23 Nov 2011 12:24:54 +0100 Subject: [python-ldap] mutex bug in 2.4.4 In-Reply-To: <090BBF843CD9C749B53A37A86BAA263599BD53894C@FASXCH02.fasmail.priv> References: <090BBF843CD9C749B53A37A86BAA263599BD53894C@FASXCH02.fasmail.priv> Message-ID: <4ECCD806.6040007@stroeder.com> Adam, Side note: Mailing list python-ldap at python.org only accepts postings by subscribers. I had to manually approve your posting. So please subscribe to the mailing list if you want to follow the discussion. Malinowski, Adam wrote: > There appears to be a bug in stable 2.4.4 version of python-module when used > in multi-threaded python environment. I haven?t found any info on the mailing > list about this, so I thought it should be reported. > > A different object is used in lock acquire() and release(), which leads to > call to release() always fail, also other blocked callers could be stuck > forever. How did you come to this conclusion? Do you have a traceback of the calls? > Perhaps the change was never tested in multi-threaded python. My web2ldap is a multi-threaded web app where the same LDAPObject instances get possibly used by multiple threads. IMO it works as designed. Not sure whether this hits all locking conditions though. > Falling back to using the global module mutex lock seems to fix it. Sorry, your patch does not make sense to me. _ldap_function_call() takes an instance of threading.Lock or compatible. If lock is None no locking is done. Your patch completely changes that behaviour and also you're not releasing ldap._ldap_module_lock. Ciao, Michael. From jaraco at jaraco.com Wed Nov 23 17:02:09 2011 From: jaraco at jaraco.com (Jason R. Coombs) Date: Wed, 23 Nov 2011 16:02:09 +0000 Subject: [python-ldap] Windows binary builds for x64 with SSL Message-ID: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> I'd like to see 64-bit builds of Python-LDAP with SSL support for Windows. The builds on PyPI are built against 32-bit Python. The builds by Christoph Grothe don't include SSL (because last I checked, he doesn't want to deal with export control issues). So it looks like I need to build them from source, but it seems even the source is in CVS. So I've forked the code at https://bitbucket.org/jaraco/python-ldap. First question: Would the python-ldap maintainers consider using Mercurial or Git for a repository? Feel free to use the converted repository on Bitbucket for this purpose. Second question: Does anyone have any tips on building python-ldap for Windows? Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6448 bytes Desc: not available URL: From jaraco at jaraco.com Wed Nov 23 17:18:54 2011 From: jaraco at jaraco.com (Jason R. Coombs) Date: Wed, 23 Nov 2011 16:18:54 +0000 Subject: [python-ldap] Windows binary builds for x64 with SSL In-Reply-To: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> References: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> Message-ID: <7E79234E600438479EC119BD241B48D6A1B319@CH1PRD0602MB098.namprd06.prod.outlook.com> I apologize. I mistakenly copied Christoph's last name. It's Christoph Gohlke. From: python-ldap-bounces+jaraco=jaraco.com at python.org [mailto:python-ldap-bounces+jaraco=jaraco.com at python.org] On Behalf Of Jason R. Coombs Sent: Wednesday, 23 November, 2011 11:02 To: python-ldap at python.org Subject: [python-ldap] Windows binary builds for x64 with SSL I'd like to see 64-bit builds of Python-LDAP with SSL support for Windows. The builds on PyPI are built against 32-bit Python. The builds by Christoph Grothe don't include SSL (because last I checked, he doesn't want to deal with export control issues). So it looks like I need to build them from source, but it seems even the source is in CVS. So I've forked the code at https://bitbucket.org/jaraco/python-ldap. First question: Would the python-ldap maintainers consider using Mercurial or Git for a repository? Feel free to use the converted repository on Bitbucket for this purpose. Second question: Does anyone have any tips on building python-ldap for Windows? Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6448 bytes Desc: not available URL: From michael at stroeder.com Wed Nov 23 18:48:21 2011 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Wed, 23 Nov 2011 18:48:21 +0100 Subject: [python-ldap] Windows binary builds for x64 with SSL In-Reply-To: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> References: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> Message-ID: <4ECD31E5.1090806@stroeder.com> Jason R. Coombs wrote: > So it looks like I need to build them from source, but it seems even the > source is in CVS. So I?ve forked the code at > https://bitbucket.org/jaraco/python-ldap. > > First question: Would the python-ldap maintainers consider using Mercurial or > Git for a repository? Feel free to use the converted repository on Bitbucket > for this purpose. Yes, considering a distributed VCS but I don't have the time switching at the moment. See also the mailing list archive for a discussion about that and my disliking of cloned repos. I definitely won't do any support for that. Mainly my personal view is: People have to flood me with patches solving real problems to convince me to change anything. All my inquiries for input or code help on this mailing list are lost like in a black hole. Switching the VCS itself won't produce a single line of code. If you have some spare time and interest in helping out this is a good starting point looking what should be improved: http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/TODO?view=markup Ciao, Michael. From waldemar.osuch at gmail.com Thu Nov 24 05:47:09 2011 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Wed, 23 Nov 2011 21:47:09 -0700 Subject: [python-ldap] Windows binary builds for x64 with SSL In-Reply-To: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> References: <7E79234E600438479EC119BD241B48D6A1B2AD@CH1PRD0602MB098.namprd06.prod.outlook.com> Message-ID: On Wed, Nov 23, 2011 at 09:02, Jason R. Coombs wrote: > > Second question: Does anyone have any tips on building python-ldap for > Windows? The problem with building python-ldap on Windows is getting all the dependencies built first. In Linux environments they usually come for "free" from your distribution. First get yourself a MinGW environment. TDM-GCC http://tdm-gcc.tdragon.net/ seems to be a good starting point Next comes building the dependencies. Some time ago I went trough the pain of doing just that using MinGW32. The instructions found at http://www.bowmansolutions.com/mingw-openldap/ should give you a head start. Waldemar From michael at stroeder.com Fri Nov 25 13:31:10 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 25 Nov 2011 13:31:10 +0100 Subject: [python-ldap] ANN: python-ldap 2.4.5 Message-ID: <4ECF8A8E.50808@stroeder.com> Find a new release of python-ldap: http://pypi.python.org/pypi/python-ldap/2.4.4 python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Project's web site: http://www.python-ldap.org/ Ciao, Michael. ---------------------------------------------------------------- Released 2.4.5 2011-11-25 Changes since 2.4.4: Installation: * defines for SASL and SSL in setup.cfg to be more friendly to Python setup tools (easy_install) Lib/ * Fixed typo in ldap.functions._ldap_function_call() which always released ldap._ldap_module_lock instead of local lock * ldap.controls.ppolicy: Fixed decoding the password policy response control Demo/ * Demo script for ldap.controls.ppolicy From john at nmt.edu Mon Nov 28 22:45:53 2011 From: john at nmt.edu (John W. Shipman) Date: Mon, 28 Nov 2011 14:45:53 -0700 (MST) Subject: [python-ldap] One vote for 3.x Message-ID: We have a number of applications here that use python-ldap. We're just starting to convert our application base to Python 3.2. So please record one vote for a 3.x version. Best regards, John Shipman (john at nmt.edu), Applications Specialist, NM Tech Computer Center, Speare 119, Socorro, NM 87801, (575) 835-5735, http://www.nmt.edu/~john ``Let's go outside and commiserate with nature.'' --Dave Farber From michael at stroeder.com Tue Nov 29 11:09:25 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Nov 2011 11:09:25 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: References: Message-ID: <4ED4AF55.7080900@stroeder.com> John W. Shipman wrote: > We have a number of applications here that use python-ldap. We're > just starting to convert our application base to Python 3.2. So > please record one vote for a 3.x version. I'm pretty sure there would be many votes for a 3.x version. But there are currently not very many people really considering spending work time needed into it to get a well maintained version. Please see the mailing list archive about this. Ciao, Michael. From chris.dukes.aix at gmail.com Tue Nov 29 14:42:18 2011 From: chris.dukes.aix at gmail.com (Chris Dukes) Date: Tue, 29 Nov 2011 08:42:18 -0500 Subject: [python-ldap] One vote for 3.x In-Reply-To: <4ED4AF55.7080900@stroeder.com> References: <4ED4AF55.7080900@stroeder.com> Message-ID: <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> On Tue, 2011-11-29 at 11:09 +0100, Michael Str?der wrote: > John W. Shipman wrote: > > We have a number of applications here that use python-ldap. We're > > just starting to convert our application base to Python 3.2. So > > please record one vote for a 3.x version. > > I'm pretty sure there would be many votes for a 3.x version. But there are > currently not very many people really considering spending work time needed > into it to get a well maintained version. > > Please see the mailing list archive about this. My two cents for anyone wanting to start on it. 1) Start by either getting _ldap.so to work with python 3.x, *OR* replace _ldap.so with pure python calling 'ctypes' that maintains close to the same interface. The latter will probably be quicker to develop. The former will work on less loved OSes like AIX. 2) Look at the python-ldap APIs you actually use and start getting them clean for python 3.x. -- Chris Dukes. This message is not confidential. Due to the nature of how email is sent, it's only slightly more private than a postcard. Use GPG if you want correspondence to be confidential and private. From michael at stroeder.com Tue Nov 29 14:46:31 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 29 Nov 2011 14:46:31 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> Message-ID: <4ED4E237.5070806@stroeder.com> Chris Dukes wrote: > On Tue, 2011-11-29 at 11:09 +0100, Michael Str?der wrote: >> John W. Shipman wrote: >>> We have a number of applications here that use python-ldap. We're >>> just starting to convert our application base to Python 3.2. So >>> please record one vote for a 3.x version. >> >> I'm pretty sure there would be many votes for a 3.x version. But there are >> currently not very many people really considering spending work time needed >> into it to get a well maintained version. >> >> Please see the mailing list archive about this. > > My two cents for anyone wanting to start on it. > 1) Start by either getting _ldap.so to work with python 3.x, *OR* > replace _ldap.so with pure python calling 'ctypes' that maintains close > to the same interface. The latter will probably be quicker to develop. > The former will work on less loved OSes like AIX. > 2) Look at the python-ldap APIs you actually use and start getting them > clean for python 3.x. Hmm, the current API was too closely modeled after the LDAP C API which is also considered to have its deficiencies. I'd rather recommend to rethink the whole approach because the code of the calling application massively changes anyway. Ciao, Michael. From stefanik at dscon.sk Tue Nov 29 14:41:07 2011 From: stefanik at dscon.sk (Dusan Stefanik) Date: Tue, 29 Nov 2011 14:41:07 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: References: Message-ID: <20111129134107.GB11083@dscon.dsx.cz> Hi, I have python-ldap 2.4.4 for python 3.x (tested on python 3.2 with demo scripts) useful for testing concepts or developing(not for deploy). I can send it but I'm currently out of office (patch is in my office computer) for 2weeks. Dusan On 28/11/11 at 02:45pm, John W. Shipman wrote: > We have a number of applications here that use python-ldap. We're > just starting to convert our application base to Python 3.2. So > please record one vote for a 3.x version. > > Best regards, > John Shipman (john at nmt.edu), Applications Specialist, NM Tech Computer Center, > Speare 119, Socorro, NM 87801, (575) 835-5735, http://www.nmt.edu/~john > ``Let's go outside and commiserate with nature.'' --Dave Farber > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > From ilya at glas.net Tue Nov 29 15:31:52 2011 From: ilya at glas.net (Ilya Etingof) Date: Tue, 29 Nov 2011 18:31:52 +0400 (GMT-4) Subject: [python-ldap] One vote for 3.x In-Reply-To: <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> Message-ID: > 1) Start by either getting _ldap.so to work with python 3.x, *OR* > replace _ldap.so with pure python calling 'ctypes' that maintains close > to the same interface. The latter will probably be quicker to develop. > The former will work on less loved OSes like AIX. In the former case it might be more easier and robust to use pyasn1 than ctypes. BTW, pyasn1 seems to already be used in python-ldap for LDAP Controls. -ilya From michael at stroeder.com Tue Nov 29 15:42:43 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Nov 2011 15:42:43 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> Message-ID: <4ED4EF63.4030203@stroeder.com> Ilya Etingof wrote: > >> 1) Start by either getting _ldap.so to work with python 3.x, *OR* >> replace _ldap.so with pure python calling 'ctypes' that maintains close >> to the same interface. The latter will probably be quicker to develop. >> The former will work on less loved OSes like AIX. > > In the former case it might be more easier and robust to use pyasn1 than > ctypes. BTW, pyasn1 seems to already be used in python-ldap for LDAP Controls. I already considered that. But there are currently two reasons I'd stick to using the OpenLDAP C client libs: 1. Speed: It's definitely a difference decoding large search results compared to occasionally en-/decoding some LDAP controls. But off course this needs exact profiling. 2. Functionality: It will be much work to implement everything, especially the SASL stuff. Ciao, Michael. From ilya at glas.net Tue Nov 29 16:08:13 2011 From: ilya at glas.net (Ilya Etingof) Date: Tue, 29 Nov 2011 19:08:13 +0400 (GMT-4) Subject: [python-ldap] One vote for 3.x In-Reply-To: <4ED4EF63.4030203@stroeder.com> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> <4ED4EF63.4030203@stroeder.com> Message-ID: Yes, pyasn1 is slow compared to C implementations. Off the top of my head, my estimation is that pure encoding/decoding operations are 5-10 times slower with pyasn1. >> In the former case it might be easier and more robust to use pyasn1 than >> ctypes. BTW, pyasn1 seems to already be used in python-ldap for LDAP Controls. > > I already considered that. But there are currently two reasons I'd stick to > using the OpenLDAP C client libs: > > 1. Speed: It's definitely a difference decoding large search results compared > to occasionally en-/decoding some LDAP controls. But off course this needs > exact profiling. > > 2. Functionality: It will be much work to implement everything, especially the > SASL stuff. From michael at stroeder.com Tue Nov 29 17:49:08 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 29 Nov 2011 17:49:08 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> <4ED4EF63.4030203@stroeder.com> Message-ID: <4ED50D04.4040007@stroeder.com> Ilya Etingof wrote: > Yes, pyasn1 is slow compared to C implementations. Off the top of my head, > my estimation is that pure encoding/decoding operations are 5-10 times slower > with pyasn1. Like other modules you could try to rewrite the pure encoding/decoding operations into a C module which is optionally imported (like StringIO vs. cStringIO). But sure this will a lot of work. Sorry, I can't help with that since I'm not a C programmer. Anyway the whole SASL and SSL/TLS stuff will be a lot of work. Or one would have to wrap cyrus-sasl libs and try to use a good crypto module. All in all this is much effort. Given the experience with contributions so far this is unlikely to happen any time soon. Continous support is needed not just small patches. And as said in a former posting a couple of months ago: Personally I don't have a need for Python 3.x at the moment. Ciao, Michael. >>> In the former case it might be easier and more robust to use pyasn1 than >>> ctypes. BTW, pyasn1 seems to already be used in python-ldap for LDAP Controls. >> >> I already considered that. But there are currently two reasons I'd stick to >> using the OpenLDAP C client libs: >> >> 1. Speed: It's definitely a difference decoding large search results compared >> to occasionally en-/decoding some LDAP controls. But off course this needs >> exact profiling. >> >> 2. Functionality: It will be much work to implement everything, especially the >> SASL stuff. From lists at cheimes.de Thu Dec 1 01:13:45 2011 From: lists at cheimes.de (Christian Heimes) Date: Thu, 01 Dec 2011 01:13:45 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> Message-ID: Am 29.11.2011 14:42, schrieb Chris Dukes: > My two cents for anyone wanting to start on it. > 1) Start by either getting _ldap.so to work with python 3.x, *OR* > replace _ldap.so with pure python calling 'ctypes' that maintains close > to the same interface. The latter will probably be quicker to develop. > The former will work on less loved OSes like AIX. *OR* use Cython [1] to interface with libldap. I've tried both ctypes and Cython in the past. Nowadays I use Cython exclusively to optimized code and interfacing with C/C++ libraries. Cython is a great tool because it takes care of all the boiler plate stuff you don't want to write manually. Cython looks like Python code with some C annotations. Anybody with basic knowledge of C and Python can understand and modify the code -- you don't need to know the Python C API. Carefully written Cython code compiles to C extensions for every major version of CPython from 2.4 to 3.2 without additional work. Cython is used in several major projects, e.g. NumPy. lxml is written entirely in Python and Cython. Christian [1] http://cython.org/ From michael at stroeder.com Thu Dec 1 09:50:59 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 Dec 2011 09:50:59 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> Message-ID: <4ED73FF3.5030509@stroeder.com> Christian Heimes wrote: > Am 29.11.2011 14:42, schrieb Chris Dukes: >> My two cents for anyone wanting to start on it. >> 1) Start by either getting _ldap.so to work with python 3.x, *OR* >> replace _ldap.so with pure python calling 'ctypes' that maintains close >> to the same interface. The latter will probably be quicker to develop. >> The former will work on less loved OSes like AIX. > > *OR* use Cython [1] to interface with libldap. I've tried both ctypes > and Cython in the past. Nowadays I use Cython exclusively to optimized > code and interfacing with C/C++ libraries. Cython is a great tool > because it takes care of all the boiler plate stuff you don't want to > write manually. Cython looks like Python code with some C annotations. > Anybody with basic knowledge of C and Python can understand and modify > the code -- you don't need to know the Python C API. Carefully written > Cython code compiles to C extensions for every major version of CPython > from 2.4 to 3.2 without additional work. This sounds very interesting. But don't you then need Cython installed to build a certain module? And how about pre-compiled binaries? Do they need extra Cython parts shipped along with them? Ciao, Michael. From mail at timgolden.me.uk Thu Dec 1 10:14:07 2011 From: mail at timgolden.me.uk (Tim Golden) Date: Thu, 01 Dec 2011 09:14:07 +0000 Subject: [python-ldap] One vote for 3.x In-Reply-To: <4ED73FF3.5030509@stroeder.com> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> <4ED73FF3.5030509@stroeder.com> Message-ID: <4ED7455F.3060509@timgolden.me.uk> On 01/12/2011 08:50, Michael Str?der wrote: > Christian Heimes wrote: >> *OR* use Cython [1] to interface with libldap. I've tried both ctypes >> and Cython in the past. Nowadays I use Cython exclusively to optimized >> code and interfacing with C/C++ libraries. Cython is a great tool >> because it takes care of all the boiler plate stuff you don't want to >> write manually. Cython looks like Python code with some C annotations. >> Anybody with basic knowledge of C and Python can understand and modify >> the code -- you don't need to know the Python C API. Carefully written >> Cython code compiles to C extensions for every major version of CPython >> from 2.4 to 3.2 without additional work. > > But don't you then need Cython installed to build a certain module? Cython (essentially) converts Python to the equivalent C. So you can either ship the original source and require Cython to be available at build time. Or you can ship the results of the Cython "preprocess" which are just .c files. This is covered (in brief) here: http://docs.cython.org/src/quickstart/build.html > > And how about pre-compiled binaries? Do they need extra Cython parts shipped > along with them? Same again: Cython converts Python to C so there's no extra Cython parts needed; it just saves you from writing out the extension modules longhand. (Obviously I'm simplifying things here but that's the effect). The main Cython developer (Stefan Behnel) is always keen for people to use Cython; I'm sure he'd be happy to advise. TJG From jens at dataflake.org Thu Dec 1 10:08:47 2011 From: jens at dataflake.org (Jens Vagelpohl) Date: Thu, 1 Dec 2011 10:08:47 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: <4ED73FF3.5030509@stroeder.com> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> <4ED73FF3.5030509@stroeder.com> Message-ID: <03B1F9F5-30C2-4407-8F7B-3AFD24B18BEE@dataflake.org> On Dec 1, 2011, at 09:50 , Michael Str?der wrote: > But don't you then need Cython installed to build a certain module? > > And how about pre-compiled binaries? Do they need extra Cython parts shipped > along with them? Cython just adds a step before the actual C compiling. You run it against the Cython source files, which will convert the Cython .pyx into standard .c files. Those can then be built like any other C extension and Cython does not need to be installed. That means if you check those resulting C files into the version control system the build process will remain identical for all consumers of your egg. Only the developers need to know about Cython. I'm doing some work for a customer on a new SAP R/3 connection library, and they use Cython for the C bits as well. jens From lists at cheimes.de Thu Dec 1 16:50:20 2011 From: lists at cheimes.de (Christian Heimes) Date: Thu, 01 Dec 2011 16:50:20 +0100 Subject: [python-ldap] One vote for 3.x In-Reply-To: <4ED73FF3.5030509@stroeder.com> References: <4ED4AF55.7080900@stroeder.com> <1322574138.4525.142.camel@greasy-desktop.gateway.2wire.net> <4ED73FF3.5030509@stroeder.com> Message-ID: <4ED7A23C.2030909@cheimes.de> Am 01.12.2011 09:50, schrieb Michael Str?der: > This sounds very interesting. > > But don't you then need Cython installed to build a certain module? > > And how about pre-compiled binaries? Do they need extra Cython parts shipped > along with them? You don't need a Cython installation if you ship the generated C files with the source package. There aren't any runtime dependencies on Cython, too. Lxml compiles are and works without an installation of Cython because it ships the Cython files and the autogenerated C files. Christian From bradskins at gmail.com Wed Dec 7 19:54:29 2011 From: bradskins at gmail.com (Bradley McCandless) Date: Wed, 7 Dec 2011 11:54:29 -0700 Subject: [python-ldap] PyPy-LDAP Message-ID: Hello, I've built a PyPy version of python-ldap (2.4.6), and I get the following error when I try to import: Python 2.7.1 (?, Dec 02 2011, 19:18:28) [PyPy 1.7.0 with GCC 4.6.2] on freebsd9 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``calling the translation tool chain a 'script' is kind of offensive'' >>>> from ldap import * Fatal error in cpyext, CPython compatibility layer, calling PyTuple_Check Either report a bug or consider not using this particular extension RPython traceback: File "module_cpyext_api_4.c", line 28061, in PyTuple_Check File "module_cpyext_pyobject.c", line 6540, in CpyTypedescr_type_realize File "module_cpyext_typeobject.c", line 1034, in type_realize File "module_cpyext_typeobject.c", line 2540, in _type_realize File "module_cpyext_typeobject.c", line 4836, in W_PyCTypeObject___init__ File "module_cpyext_pyobject.c", line 1213, in BaseCpyTypedescr_realize Segmentation fault: 11 I asked on the PyPy IRC and they suggested that PyTuple_Check is running before initializing module. Any thoughts on a fix? -brads -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Wed Dec 7 20:10:26 2011 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 Dec 2011 20:10:26 +0100 Subject: [python-ldap] PyPy-LDAP In-Reply-To: References: Message-ID: <4EDFBA22.9070003@stroeder.com> Frankly I've never used PyPy and I have no clue what PyTuple_Check is about. Also a short search did not return sample code on how to use it. I'd be willing to accept a patch for python-ldap if the import of something is truly optional. Ciao, Michael. Bradley McCandless wrote: > Hello, > > I've built a PyPy version of python-ldap (2.4.6), and I get the following > error when I try to import: > > Python 2.7.1 (?, Dec 02 2011, 19:18:28) > [PyPy 1.7.0 with GCC 4.6.2] on freebsd9 > Type "help", "copyright", "credits" or "license" for more information. > And now for something completely different: ``calling the translation tool > chain a 'script' is kind of offensive'' >>>>> from ldap import * > Fatal error in cpyext, CPython compatibility layer, calling PyTuple_Check > Either report a bug or consider not using this particular extension > > RPython traceback: > File "module_cpyext_api_4.c", line 28061, in PyTuple_Check > File "module_cpyext_pyobject.c", line 6540, in CpyTypedescr_type_realize > File "module_cpyext_typeobject.c", line 1034, in type_realize > File "module_cpyext_typeobject.c", line 2540, in _type_realize > File "module_cpyext_typeobject.c", line 4836, in W_PyCTypeObject___init__ > File "module_cpyext_pyobject.c", line 1213, in BaseCpyTypedescr_realize > Segmentation fault: 11 > > I asked on the PyPy IRC and they suggested that PyTuple_Check is running > before initializing module. Any thoughts on a fix? > > -brads From dmalcolm at redhat.com Wed Dec 7 22:41:36 2011 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 07 Dec 2011 16:41:36 -0500 Subject: [python-ldap] Suspected memory leak in Modules/errors.c:LDAPerr Message-ID: <1323294096.2300.23.camel@surprise> I'm running an experimental static analysis tool [1] over python-ldap, and it discovered what looks like a real reference leak: Modules/errors.c: In function ?LDAPerr?, if it executes this code: else PyErr_SetObject(LDAPexception_class, Py_BuildValue("{s:i}", "errnum", errnum)); then Py_BuildValue returns a new dictionary with refcount 1, owned by the caller; PyErr_SetObject adds a new ref; the first ref is leaked; hence the dictionary is leaked every time HTML version of the above attached. Having said that, it looks like this branch is only followed when receiving an unexpected error ID. Hope this is helpful Dave [1] http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradskins at gmail.com Wed Dec 7 23:11:00 2011 From: bradskins at gmail.com (Bradley McCandless) Date: Wed, 7 Dec 2011 15:11:00 -0700 Subject: [python-ldap] Suspected memory leak in Modules/errors.c:LDAPerr In-Reply-To: <1323294096.2300.23.camel@surprise> References: <1323294096.2300.23.camel@surprise> Message-ID: Hello, Just removing the DECREF on line on line 129 of errors.c solves the issue. http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2011-12-07/errors.c.LDAPinit_errors-refcount-errors.html >From #pypy.irc.freenode.net: *exarku n: *brads : So, you can point out that errors.c:129 should not be Py_DECREF'ing the exception class, because the module re-uses the exception class later on. *exarkun *: brads : And it only works on CPython by accident -brad On Wed, Dec 7, 2011 at 2:41 PM, David Malcolm wrote: > I'm running an experimental static analysis tool [1] over python-ldap, > and it discovered what looks like a real reference leak: > > Modules/errors.c: In function ?LDAPerr?, > if it executes this code: > else > PyErr_SetObject(LDAPexception_class, > Py_BuildValue("{s:i}", "errnum", errnum)); > > then Py_BuildValue returns a new dictionary with refcount 1, owned by > the caller; PyErr_SetObject adds a new ref; the first ref is leaked; > hence the dictionary is leaked every time > > HTML version of the above attached. > > Having said that, it looks like this branch is only followed when > receiving an unexpected error ID. > > Hope this is helpful > Dave > > > [1] http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html > > _______________________________________________ > python-ldap mailing list > python-ldap at python.org > http://mail.python.org/mailman/listinfo/python-ldap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmalcolm at redhat.com Wed Dec 7 23:22:07 2011 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 07 Dec 2011 17:22:07 -0500 Subject: [python-ldap] Suspected memory leak in Modules/errors.c:LDAPerr In-Reply-To: References: <1323294096.2300.23.camel@surprise> Message-ID: <1323296528.2300.32.camel@surprise> On Wed, 2011-12-07 at 15:11 -0700, Bradley McCandless wrote: > Just removing the DECREF on line on line 129 of errors.c solves the > issue. I believe Bradley is reporting on the PyPy issue from this thread: http://mail.python.org/pipermail/python-ldap/2011q4/003070.html Bradley, am I correct? (sorry, I'm not subscribed to this list). > http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2011-12-07/errors.c.LDAPinit_errors-refcount-errors.html The above is another output file from my experimental refcount-checking tool ([1] below), which I posted to #pypy on Freenode, where we were discussing the PyPy issue. (I had to comment out the majority of the seterrobj() macro invocations in order to workaround a bug in my tool) > From #pypy.irc.freenode.net: > > > exarkun: brads: So, you can point out that errors.c:129 should not be > Py_DECREF'ing the exception class, because the module re-uses the > exception class later on. > > exarkun: brads: And it only works on CPython by accident The code is assuming that the references within the dictionary are going to keep the LDAPexception_class object alive. This works in CPython, but fails under PyPy; my understanding is that this is because PyPy implements Python.h as a series of thin proxy objects around its "real" object implementations, and the proxy object for the exception gets cleaned up when the DECREF happens. Given that LDAPexception_class is a global, it makes sense to own a reference to it. (The tool is also reporting on some possible crashes calling PyDict_SetItemString with NULL, when running under low memory conditions) Hope this is helpful. Dave > -brad > > > On Wed, Dec 7, 2011 at 2:41 PM, David Malcolm > wrote: > I'm running an experimental static analysis tool [1] over > python-ldap, > and it discovered what looks like a real reference leak: > > Modules/errors.c: In function ?LDAPerr?, > if it executes this code: > else > PyErr_SetObject(LDAPexception_class, > Py_BuildValue("{s:i}", "errnum", errnum)); > > then Py_BuildValue returns a new dictionary with refcount 1, > owned by > the caller; PyErr_SetObject adds a new ref; the first ref is > leaked; > hence the dictionary is leaked every time > > HTML version of the above attached. > > Having said that, it looks like this branch is only followed > when > receiving an unexpected error ID. > > Hope this is helpful > Dave > > > [1] > http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html From michael at stroeder.com Thu Dec 8 19:14:42 2011 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Thu, 08 Dec 2011 19:14:42 +0100 Subject: [python-ldap] Suspected memory leak in Modules/errors.c:LDAPerr In-Reply-To: <1323296528.2300.32.camel@surprise> References: <1323294096.2300.23.camel@surprise> <1323296528.2300.32.camel@surprise> Message-ID: <4EE0FE92.4060205@stroeder.com> Hi Bradley and David, thanks for your analysis and experiments with PyPy. I'm not familiar with all this. If you prepare a patch (until tomorrow evening) I will test and commit it but I have currently no time during the next weeks to dive into that. Ciao, Michael. David Malcolm wrote: > On Wed, 2011-12-07 at 15:11 -0700, Bradley McCandless wrote: > >> Just removing the DECREF on line on line 129 of errors.c solves the >> issue. > > I believe Bradley is reporting on the PyPy issue from this thread: > http://mail.python.org/pipermail/python-ldap/2011q4/003070.html > Bradley, am I correct? > > (sorry, I'm not subscribed to this list). > >> http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2011-12-07/errors.c.LDAPinit_errors-refcount-errors.html > > The above is another output file from my experimental refcount-checking > tool ([1] below), which I posted to #pypy on Freenode, where we were > discussing the PyPy issue. > > (I had to comment out the majority of the seterrobj() macro invocations > in order to workaround a bug in my tool) > >> From #pypy.irc.freenode.net: >> >> >> exarkun: brads: So, you can point out that errors.c:129 should not be >> Py_DECREF'ing the exception class, because the module re-uses the >> exception class later on. >> >> exarkun: brads: And it only works on CPython by accident > > The code is assuming that the references within the dictionary are going > to keep the LDAPexception_class object alive. This works in CPython, > but fails under PyPy; my understanding is that this is because PyPy > implements Python.h as a series of thin proxy objects around its "real" > object implementations, and the proxy object for the exception gets > cleaned up when the DECREF happens. > > Given that LDAPexception_class is a global, it makes sense to own a > reference to it. > > (The tool is also reporting on some possible crashes calling > PyDict_SetItemString with NULL, when running under low memory > conditions) > > Hope this is helpful. > Dave > >> -brad >> >> >> On Wed, Dec 7, 2011 at 2:41 PM, David Malcolm >> wrote: >> I'm running an experimental static analysis tool [1] over >> python-ldap, >> and it discovered what looks like a real reference leak: >> >> Modules/errors.c: In function ?LDAPerr?, >> if it executes this code: >> else >> PyErr_SetObject(LDAPexception_class, >> Py_BuildValue("{s:i}", "errnum", errnum)); >> >> then Py_BuildValue returns a new dictionary with refcount 1, >> owned by >> the caller; PyErr_SetObject adds a new ref; the first ref is >> leaked; >> hence the dictionary is leaked every time >> >> HTML version of the above attached. >> >> Having said that, it looks like this branch is only followed >> when >> receiving an unexpected error ID. >> >> Hope this is helpful >> Dave >> >> >> [1] >> http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html > From dmalcolm at redhat.com Wed Dec 14 17:49:34 2011 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 14 Dec 2011 16:49:34 -0000 Subject: [python-ldap] Suspected memory leak in Modules/errors.c:LDAPerr In-Reply-To: <4EE0FE92.4060205@stroeder.com> References: <1323294096.2300.23.camel@surprise> <1323296528.2300.32.camel@surprise> <4EE0FE92.4060205@stroeder.com> Message-ID: <1323881342.2369.54.camel@surprise> On Thu, 2011-12-08 at 19:14 +0100, Michael Str?der wrote: > Hi Bradley and David, > > thanks for your analysis and experiments with PyPy. > > I'm not familiar with all this. If you prepare a patch (until tomorrow > evening) I will test and commit it but I have currently no time during the > next weeks to dive into that. Attached is a minimal patch against CVS HEAD which removes the erroneous Py_DECREF(). Hope this is helpful Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-erroneous-Py_DECREF-on-global-LDAPexception_class.patch Type: text/x-patch Size: 552 bytes Desc: not available URL: