From karel.slany at nic.cz Mon Aug 15 14:24:28 2011 From: karel.slany at nic.cz (Karel Slany) Date: Mon, 15 Aug 2011 16:24:28 +0200 Subject: [ldns-users] adding (partial) Python3 support Message-ID: <4E492C1C.7030307@nic.cz> Hi, recently I have been toying with the ldns sources in order to make them compile with Python3 support -- via the './configure --with-pyldns PYTHON_VERSION=3' command. I've made several changes to the supplied autoconf Python detection macros and others to make them work both with Python 2 and 3. The Python3 wrapper does now compile. However, the Python3 support is incomplete. In Python3 they have abandoned the old C I/O API in favour of the io module. Therefore SWIG does no longer support FILE* typemaps -- i.e. C functions taking FILE* arguments will generate an error in Python3. This mail contains two patches: 1) python3.diff -- Contains modifications enabling the Python3 module to compile and to run with Python3. It also contains a few working examples for Python3 which do the same as the original Python2 examples. 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not work -- this patch should fix it. The patches are against the 3523 (current) svn revision. Best regard Karel Slany -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: python3.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldns_axfr_start.diff URL: From wouter at NLnetLabs.nl Tue Aug 16 09:50:33 2011 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 16 Aug 2011 11:50:33 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <4E492C1C.7030307@nic.cz> References: <4E492C1C.7030307@nic.cz> Message-ID: <4E4A3D69.2080509@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karel, On 08/15/2011 04:24 PM, Karel Slany wrote: > recently I have been toying with the ldns sources in order to make them > compile with Python3 support -- via the './configure --with-pyldns > PYTHON_VERSION=3' command. I've made several changes to the supplied > autoconf Python detection macros and others to make them work both with > Python 2 and 3. Because we do not maintain these python implementations ourselves, it would be good if other users could tell us if these patches work for Python 2. There are large changes, and we want to support our users. If that works, the patch is likely very nice to accept. Thanks for the good work :-) Best regards, Wouter > The Python3 wrapper does now compile. However, the Python3 support is > incomplete. In Python3 they have abandoned the old C I/O API in favour > of the io module. Therefore SWIG does no longer support FILE* typemaps > -- i.e. C functions taking FILE* arguments will generate an error in > Python3. > > This mail contains two patches: > 1) python3.diff -- Contains modifications enabling the Python3 module to > compile and to run with Python3. It also contains a few working examples > for Python3 which do the same as the original Python2 examples. > > 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not > work -- this patch should fix it. > > The patches are against the 3523 (current) svn revision. > > Best regard > > Karel Slany > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t SYTL+clUdQebb9+RLJWI =yL6p -----END PGP SIGNATURE----- From ondrej at sury.org Tue Aug 16 10:04:19 2011 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 16 Aug 2011 12:04:19 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <4E4A3D69.2080509@nlnetlabs.nl> References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: Patrik, could you also test the Python 3 implementation? It was you who asked about it? O. On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Karel, > > On 08/15/2011 04:24 PM, Karel Slany wrote: >> recently I have been toying with the ldns sources in order to make them >> compile with Python3 support -- via the './configure --with-pyldns >> PYTHON_VERSION=3' command. I've made several changes to the supplied >> autoconf Python detection macros and others to make them work both with >> Python 2 and 3. > > Because we do not maintain these python implementations ourselves, it > would be good if other users could tell us if these patches work for > Python 2. ?There are large changes, and we want to support our users. > > If that works, the patch is likely very nice to accept. ?Thanks for the > good work :-) > > Best regards, > ? Wouter > >> The Python3 wrapper does now compile. However, the Python3 support is >> incomplete. In Python3 they have abandoned the old C I/O API in favour >> of the io module. Therefore SWIG does no longer support FILE* typemaps >> -- i.e. C functions taking FILE* arguments will generate an error in >> Python3. >> >> This mail contains two patches: >> 1) python3.diff -- Contains modifications enabling the Python3 module to >> compile and to run with Python3. It also contains a few working examples >> for Python3 which do the same as the original Python2 examples. >> >> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >> work -- this patch should fix it. >> >> The patches are against the 3523 (current) svn revision. >> >> Best regard >> >> Karel Slany >> >> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO > /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x > UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ > c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq > uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf > dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN > l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS > yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y > 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs > 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 > A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t > SYTL+clUdQebb9+RLJWI > =yL6p > -----END PGP SIGNATURE----- > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -- ?Ond?ej Sur? From bedrich.kosata at nic.cz Tue Aug 16 11:46:10 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Tue, 16 Aug 2011 13:46:10 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <4E4A3D69.2080509@nlnetlabs.nl> References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: <4E4A5882.1020103@nic.cz> Hi, I tried both the patches and can confirm that it fixes the AXFR example crash and that it compiles and works properly with Python 2.6. I did not test it in Python 3, but it does not break 2.6. :) Cheers Beda On 08/16/2011 11:50 AM, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Karel, > > On 08/15/2011 04:24 PM, Karel Slany wrote: >> recently I have been toying with the ldns sources in order to make them >> compile with Python3 support -- via the './configure --with-pyldns >> PYTHON_VERSION=3' command. I've made several changes to the supplied >> autoconf Python detection macros and others to make them work both with >> Python 2 and 3. > > Because we do not maintain these python implementations ourselves, it > would be good if other users could tell us if these patches work for > Python 2. There are large changes, and we want to support our users. > > If that works, the patch is likely very nice to accept. Thanks for the > good work :-) > > Best regards, > Wouter > >> The Python3 wrapper does now compile. However, the Python3 support is >> incomplete. In Python3 they have abandoned the old C I/O API in favour >> of the io module. Therefore SWIG does no longer support FILE* typemaps >> -- i.e. C functions taking FILE* arguments will generate an error in >> Python3. >> >> This mail contains two patches: >> 1) python3.diff -- Contains modifications enabling the Python3 module to >> compile and to run with Python3. It also contains a few working examples >> for Python3 which do the same as the original Python2 examples. >> >> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >> work -- this patch should fix it. >> >> The patches are against the 3523 (current) svn revision. >> >> Best regard >> >> Karel Slany >> >> >> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO > /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x > UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ > c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq > uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf > dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN > l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS > yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y > 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs > 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 > A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t > SYTL+clUdQebb9+RLJWI > =yL6p > -----END PGP SIGNATURE----- > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -- Bedrich Kosata CZ.NIC Labs From patrik at frobbit.se Tue Aug 16 13:58:47 2011 From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 16 Aug 2011 15:58:47 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: <41FBA642-DDE8-424F-99AD-33F0853E3A8D@frobbit.se> Indeed I will! Patrik On 16 aug 2011, at 12:04, Ond?ej Sur? wrote: > Patrik, > > could you also test the Python 3 implementation? It was you who asked about it? > > O. > > On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Karel, >> >> On 08/15/2011 04:24 PM, Karel Slany wrote: >>> recently I have been toying with the ldns sources in order to make them >>> compile with Python3 support -- via the './configure --with-pyldns >>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>> autoconf Python detection macros and others to make them work both with >>> Python 2 and 3. >> >> Because we do not maintain these python implementations ourselves, it >> would be good if other users could tell us if these patches work for >> Python 2. There are large changes, and we want to support our users. >> >> If that works, the patch is likely very nice to accept. Thanks for the >> good work :-) >> >> Best regards, >> Wouter >> >>> The Python3 wrapper does now compile. However, the Python3 support is >>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>> -- i.e. C functions taking FILE* arguments will generate an error in >>> Python3. >>> >>> This mail contains two patches: >>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>> compile and to run with Python3. It also contains a few working examples >>> for Python3 which do the same as the original Python2 examples. >>> >>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>> work -- this patch should fix it. >>> >>> The patches are against the 3523 (current) svn revision. >>> >>> Best regard >>> >>> Karel Slany >>> >>> >>> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >> SYTL+clUdQebb9+RLJWI >> =yL6p >> -----END PGP SIGNATURE----- >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > > > > -- > ?Ond?ej Sur? > From karel.slany at nic.cz Fri Aug 19 13:08:39 2011 From: karel.slany at nic.cz (Karel Slany) Date: Fri, 19 Aug 2011 15:08:39 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <4E4A5882.1020103@nic.cz> References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> <4E4A5882.1020103@nic.cz> Message-ID: <4E4E6057.9060803@nic.cz> Hi Wouter, as far as I know the proposed patches do not break Python2 compatibility. I've tested python 2.4, 2.6 and 2.7. I would really appreciate the patches to be applied in the SVN tree as soon as possible. Particularly for the following reasons: * During the last few days I've written some experimental code enabling FILE* support in Python3. (This enables full Python3 wrapper functionality, at least in the means of its current functionality -- see next reason. The support code may not be extremely fast, but in my opinion, it is reliable enough to serve as a initial working solution for Python3 on GNU/Linux.) * The current ldns swig wrapper generator source appears to be somewhat buggy. This may be partially caused by the evolution of the ldns C source whereas the changes weren't reflected in the wrapper code. The ldns_axfr_start patch may be one example. Another is the malfunctioning ldns-signzone.py python example. Whereas the LDNS_DEBUG define in ldns.i breaks the wrapper code when used instead of producing additional useful debugging info. It would be really nice to apply these patches as soon as possible because I'm also a bit sceptical about getting some serious (meaning lots of) feedback in this thread. It would be also nice to consider expanding the set of examples to serve as basic functionality test for the pyldns. This may help to avoid unintentional breaking of compatibility. Best regards, K. Dne 16.8.2011 13:46, Bedrich Kosata napsal(a): > Hi, > > I tried both the patches and can confirm that it fixes the AXFR example > crash and that it compiles and works properly with Python 2.6. > I did not test it in Python 3, but it does not break 2.6. :) > > Cheers > > Beda > > On 08/16/2011 11:50 AM, W.C.A. Wijngaards wrote: > Hi Karel, > > On 08/15/2011 04:24 PM, Karel Slany wrote: >>>> recently I have been toying with the ldns sources in order to make them >>>> compile with Python3 support -- via the './configure --with-pyldns >>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>> autoconf Python detection macros and others to make them work both with >>>> Python 2 and 3. > > Because we do not maintain these python implementations ourselves, it > would be good if other users could tell us if these patches work for > Python 2. There are large changes, and we want to support our users. > > If that works, the patch is likely very nice to accept. Thanks for the > good work :-) > > Best regards, > Wouter > >>>> The Python3 wrapper does now compile. However, the Python3 support is >>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>> Python3. >>>> >>>> This mail contains two patches: >>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>> compile and to run with Python3. It also contains a few working examples >>>> for Python3 which do the same as the original Python2 examples. >>>> >>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>> work -- this patch should fix it. >>>> >>>> The patches are against the 3523 (current) svn revision. >>>> >>>> Best regard >>>> >>>> Karel Slany >>>> >>>> >>>> >>>> _______________________________________________ >>>> ldns-users mailing list >>>> ldns-users at open.nlnetlabs.nl >>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From wouter at NLnetLabs.nl Fri Aug 19 13:29:45 2011 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Fri, 19 Aug 2011 15:29:45 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <4E4E6057.9060803@nic.cz> References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> <4E4A5882.1020103@nic.cz> <4E4E6057.9060803@nic.cz> Message-ID: <4E4E6549.9060507@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karel, The patch from your previous email is applied to svn trunk. The sitepackage path is still lib64, I see. I think feedback was very good. The FILE* support could be nice to have as well. Best regards, Wouter On 08/19/2011 03:08 PM, Karel Slany wrote: > Hi Wouter, > > as far as I know the proposed patches do not break Python2 > compatibility. I've tested python 2.4, 2.6 and 2.7. > > I would really appreciate the patches to be applied in the SVN tree as > soon as possible. Particularly for the following reasons: > > * During the last few days I've written some experimental code enabling > FILE* support in Python3. > (This enables full Python3 wrapper functionality, at least in the means > of its current functionality -- see next reason. The support code may > not be extremely fast, but in my opinion, it is reliable enough to serve > as a initial working solution for Python3 on GNU/Linux.) > > * The current ldns swig wrapper generator source appears to be somewhat > buggy. This may be partially caused by the evolution of the ldns C > source whereas the changes weren't reflected in the wrapper code. The > ldns_axfr_start patch may be one example. Another is the malfunctioning > ldns-signzone.py python example. Whereas the LDNS_DEBUG define in ldns.i > breaks the wrapper code when used instead of producing additional useful > debugging info. > > It would be really nice to apply these patches as soon as possible > because I'm also a bit sceptical about getting some serious (meaning > lots of) feedback in this thread. > > It would be also nice to consider expanding the set of examples to serve > as basic functionality test for the pyldns. This may help to avoid > unintentional breaking of compatibility. > > Best regards, > K. > > Dne 16.8.2011 13:46, Bedrich Kosata napsal(a): >> Hi, >> >> I tried both the patches and can confirm that it fixes the AXFR example >> crash and that it compiles and works properly with Python 2.6. >> I did not test it in Python 3, but it does not break 2.6. :) >> >> Cheers >> >> Beda >> >> On 08/16/2011 11:50 AM, W.C.A. Wijngaards wrote: >> Hi Karel, >> >> On 08/15/2011 04:24 PM, Karel Slany wrote: >>>>> recently I have been toying with the ldns sources in order to make them >>>>> compile with Python3 support -- via the './configure --with-pyldns >>>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>>> autoconf Python detection macros and others to make them work both with >>>>> Python 2 and 3. >> >> Because we do not maintain these python implementations ourselves, it >> would be good if other users could tell us if these patches work for >> Python 2. There are large changes, and we want to support our users. >> >> If that works, the patch is likely very nice to accept. Thanks for the >> good work :-) >> >> Best regards, >> Wouter >> >>>>> The Python3 wrapper does now compile. However, the Python3 support is >>>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>>> Python3. >>>>> >>>>> This mail contains two patches: >>>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>>> compile and to run with Python3. It also contains a few working examples >>>>> for Python3 which do the same as the original Python2 examples. >>>>> >>>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>>> work -- this patch should fix it. >>>>> >>>>> The patches are against the 3523 (current) svn revision. >>>>> >>>>> Best regard >>>>> >>>>> Karel Slany >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ldns-users mailing list >>>>> ldns-users at open.nlnetlabs.nl >>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOTmVJAAoJEJ9vHC1+BF+NAzgP/2BwsfW5znq+HsPiUFUdhIj9 2jeSblFgkPiF3Tglrl0AMMrdro7bj22R/+TUbwDjrg4DiLRPLi6BLFBRBi82v4k2 Fx2iV4F44I0aFrGup0XLPr6uK6xdnHCUMUucg55r4leRNztsNzwg7R7ciT32nLOh RfdFVIshzH9rArDEoUKsWi44y6czTw5oZEKJ9uzKZHQ+ogYy/Sz0hgwI3d5+QN1E ZEM4QIV0ipYVLCx7P5sIwUYVO7CBnyEHRJqnKcYCHMTcmeyVhs0TERjoEOzSm3mD QN1kp8ArS/W1axfPowXMuLkcQML6yszpu4SR4P8nM7nfj/BZVUp7GMWhpCAKEtBX 0dY9rT8x8U5fkbKcgPCtbdh2kpX2vPw2gCU6kMA2hbp2lYWkE7ZDjIyUqDq+a3GT E89SRq89gKYGCSipu8uyndq4sm6btSCH1hE7ZEzqgXD2Uk/SWt3hipIIhIHabE9V hZfSWbPCWjaBBmJ5F5w08JmhdXsauqInRqkMTskp4Za1j6Itt8XxktqgzXhmPRR8 NlYFtNVadrGLU6qwwBNidJAdNmQ86DLiAjkJAAwf0FvPklk+sJA3ssdYzXV7vihi siDVof6jqhv3tQXMPGawvrcVJNMTJn1YoAVXrZPzptBsXt0Sik7TmRbyaU+J9Myl 9J4wAi8NeLMrzC5QxK5y =Dyid -----END PGP SIGNATURE----- From patrik at frobbit.se Sun Aug 21 18:16:36 2011 From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 21 Aug 2011 20:16:36 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: Ok, I have spent some time trying to get things together, but I do not have configure karma with me today. I.e. there are many things one need to build the package that is not in the SVN repository. I am working on a mac btw. Autoconf and "automake --add-missing" has helped, as libtoolize that is called from makedist.sh is something I do not have. Because of that, I have not really been able to move forward much. Can someone help, and build a distribution for me that I can use to build the thing? I am close, maybe: # ./configure --with-pyldns --disable-gost PYTHON_VERSION=3.2 : : checking whether the C compiler (gcc) accepts the "unused" attribute... yes configure: creating ./config.status config.status: creating Makefile config.status: creating ldns/common.h config.status: creating ldns/net.h config.status: creating ldns/util.h config.status: creating packaging/libldns.pc config.status: creating packaging/ldns-config config.status: error: cannot find input file: ldns/config.h.in Patrik On 16 aug 2011, at 12.04, Ond?ej Sur? wrote: > Patrik, > > could you also test the Python 3 implementation? It was you who asked about it? > > O. > > On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Karel, >> >> On 08/15/2011 04:24 PM, Karel Slany wrote: >>> recently I have been toying with the ldns sources in order to make them >>> compile with Python3 support -- via the './configure --with-pyldns >>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>> autoconf Python detection macros and others to make them work both with >>> Python 2 and 3. >> >> Because we do not maintain these python implementations ourselves, it >> would be good if other users could tell us if these patches work for >> Python 2. There are large changes, and we want to support our users. >> >> If that works, the patch is likely very nice to accept. Thanks for the >> good work :-) >> >> Best regards, >> Wouter >> >>> The Python3 wrapper does now compile. However, the Python3 support is >>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>> -- i.e. C functions taking FILE* arguments will generate an error in >>> Python3. >>> >>> This mail contains two patches: >>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>> compile and to run with Python3. It also contains a few working examples >>> for Python3 which do the same as the original Python2 examples. >>> >>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>> work -- this patch should fix it. >>> >>> The patches are against the 3523 (current) svn revision. >>> >>> Best regard >>> >>> Karel Slany >>> >>> >>> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >> SYTL+clUdQebb9+RLJWI >> =yL6p >> -----END PGP SIGNATURE----- >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > > > > -- > ?Ond?ej Sur? > From ondrej at sury.org Sun Aug 21 21:15:16 2011 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Sun, 21 Aug 2011 23:15:16 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: Try autoremake -fi and/or call autoheader. O. 2011/8/21 Patrik F?ltstr?m : > Ok, I have spent some time trying to get things together, but I do not have configure karma with me today. > > I.e. there are many things one need to build the package that is not in the SVN repository. I am working on a mac btw. > > Autoconf and "automake --add-missing" has helped, as libtoolize that is called from makedist.sh is something I do not have. > > Because of that, I have not really been able to move forward much. > > Can someone help, and build a distribution for me that I can use to build the thing? > > I am close, maybe: > > # ./configure --with-pyldns --disable-gost PYTHON_VERSION=3.2 > : > : > checking whether the C compiler (gcc) accepts the "unused" attribute... yes > configure: creating ./config.status > config.status: creating Makefile > config.status: creating ldns/common.h > config.status: creating ldns/net.h > config.status: creating ldns/util.h > config.status: creating packaging/libldns.pc > config.status: creating packaging/ldns-config > config.status: error: cannot find input file: ldns/config.h.in > > ? Patrik > > On 16 aug 2011, at 12.04, Ond?ej Sur? wrote: > >> Patrik, >> >> could you also test the Python 3 implementation? It was you who asked about it? >> >> O. >> >> On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi Karel, >>> >>> On 08/15/2011 04:24 PM, Karel Slany wrote: >>>> recently I have been toying with the ldns sources in order to make them >>>> compile with Python3 support -- via the './configure --with-pyldns >>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>> autoconf Python detection macros and others to make them work both with >>>> Python 2 and 3. >>> >>> Because we do not maintain these python implementations ourselves, it >>> would be good if other users could tell us if these patches work for >>> Python 2. ?There are large changes, and we want to support our users. >>> >>> If that works, the patch is likely very nice to accept. ?Thanks for the >>> good work :-) >>> >>> Best regards, >>> ? Wouter >>> >>>> The Python3 wrapper does now compile. However, the Python3 support is >>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>> Python3. >>>> >>>> This mail contains two patches: >>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>> compile and to run with Python3. It also contains a few working examples >>>> for Python3 which do the same as the original Python2 examples. >>>> >>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>> work -- this patch should fix it. >>>> >>>> The patches are against the 3523 (current) svn revision. >>>> >>>> Best regard >>>> >>>> Karel Slany >>>> >>>> >>>> >>>> _______________________________________________ >>>> ldns-users mailing list >>>> ldns-users at open.nlnetlabs.nl >>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>> >>> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >>> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >>> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >>> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >>> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >>> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >>> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >>> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >>> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >>> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >>> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >>> SYTL+clUdQebb9+RLJWI >>> =yL6p >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>> >> >> >> >> -- >> ?Ond?ej Sur? >> > > -- ?Ond?ej Sur? From patrik at frobbit.se Mon Aug 22 05:12:52 2011 From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 22 Aug 2011 07:12:52 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> Message-ID: <166FFA26-C67E-4FD3-99AA-3FE8EC9765C3@frobbit.se> Did not have autoremake, but autheader existed and solved that problem. Now configure is done. Next issue, libtool: $ make ./install-sh -c -m 644 ldns/error.h ./include/ldns/ ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c make: ./libtool: No such file or directory make: *** [rdata.o] Error 1 $ which libtool /usr/bin/libtool $ ln -s /usr/bin/libtool . $ make ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c ./libtool: unknown option character `-' in: --tag=CC Usage: ./libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] Usage: ./libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table ] [-seg_addr_table_filename ] [-all_load] [-noall_load] make: *** [rdata.o] Error 1 Patrik On 21 aug 2011, at 23.15, Ond?ej Sur? wrote: > Try autoremake -fi and/or call autoheader. > > O. > > 2011/8/21 Patrik F?ltstr?m : >> Ok, I have spent some time trying to get things together, but I do not have configure karma with me today. >> >> I.e. there are many things one need to build the package that is not in the SVN repository. I am working on a mac btw. >> >> Autoconf and "automake --add-missing" has helped, as libtoolize that is called from makedist.sh is something I do not have. >> >> Because of that, I have not really been able to move forward much. >> >> Can someone help, and build a distribution for me that I can use to build the thing? >> >> I am close, maybe: >> >> # ./configure --with-pyldns --disable-gost PYTHON_VERSION=3.2 >> : >> : >> checking whether the C compiler (gcc) accepts the "unused" attribute... yes >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating ldns/common.h >> config.status: creating ldns/net.h >> config.status: creating ldns/util.h >> config.status: creating packaging/libldns.pc >> config.status: creating packaging/ldns-config >> config.status: error: cannot find input file: ldns/config.h.in >> >> Patrik >> >> On 16 aug 2011, at 12.04, Ond?ej Sur? wrote: >> >>> Patrik, >>> >>> could you also test the Python 3 implementation? It was you who asked about it? >>> >>> O. >>> >>> On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi Karel, >>>> >>>> On 08/15/2011 04:24 PM, Karel Slany wrote: >>>>> recently I have been toying with the ldns sources in order to make them >>>>> compile with Python3 support -- via the './configure --with-pyldns >>>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>>> autoconf Python detection macros and others to make them work both with >>>>> Python 2 and 3. >>>> >>>> Because we do not maintain these python implementations ourselves, it >>>> would be good if other users could tell us if these patches work for >>>> Python 2. There are large changes, and we want to support our users. >>>> >>>> If that works, the patch is likely very nice to accept. Thanks for the >>>> good work :-) >>>> >>>> Best regards, >>>> Wouter >>>> >>>>> The Python3 wrapper does now compile. However, the Python3 support is >>>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>>> Python3. >>>>> >>>>> This mail contains two patches: >>>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>>> compile and to run with Python3. It also contains a few working examples >>>>> for Python3 which do the same as the original Python2 examples. >>>>> >>>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>>> work -- this patch should fix it. >>>>> >>>>> The patches are against the 3523 (current) svn revision. >>>>> >>>>> Best regard >>>>> >>>>> Karel Slany >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> ldns-users mailing list >>>>> ldns-users at open.nlnetlabs.nl >>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>>> >>>> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >>>> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >>>> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >>>> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >>>> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >>>> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >>>> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >>>> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >>>> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >>>> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >>>> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >>>> SYTL+clUdQebb9+RLJWI >>>> =yL6p >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> ldns-users mailing list >>>> ldns-users at open.nlnetlabs.nl >>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>> >>> >>> >>> >>> -- >>> ?Ond?ej Sur? >>> >> >> > > > > -- > ?Ond?ej Sur? > From patrik at frobbit.se Mon Aug 22 07:14:52 2011 From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 22 Aug 2011 09:14:52 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> <166FFA26-C67E-4FD3-99AA-3FE8EC9765C3@frobbit.se> Message-ID: On 22 aug 2011, at 08.21, Ond?ej Sur? wrote: > Patrik, > > you need to run: > > aclocal > autoheader > libtoolize -i > autoconf # I think autoconf needs to be the last one Ok, this sort of worked. After running glibtoolize and not libtoolize. And of course after installing pcre and a new swig that had support for python3. Now when the thing is installed, I will start testing. ;-) Building must be simpler than that...phew... Patrik > This works on a clean tree. If your tree is dirty, try adding '-f' to > all except aclocal. > > O. > > 2011/8/22 Patrik F?ltstr?m : >> Did not have autoremake, but autheader existed and solved that problem. Now configure is done. >> >> Next issue, libtool: >> >> $ make >> ./install-sh -c -m 644 ldns/error.h ./include/ldns/ >> ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c >> make: ./libtool: No such file or directory >> make: *** [rdata.o] Error 1 >> $ which libtool >> /usr/bin/libtool >> $ ln -s /usr/bin/libtool . >> $ make >> ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c >> ./libtool: unknown option character `-' in: --tag=CC >> Usage: ./libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] >> Usage: ./libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table ] [-seg_addr_table_filename ] [-all_load] [-noall_load] >> make: *** [rdata.o] Error 1 >> >> Patrik >> >> On 21 aug 2011, at 23.15, Ond?ej Sur? wrote: >> >>> Try autoremake -fi and/or call autoheader. >>> >>> O. >>> >>> 2011/8/21 Patrik F?ltstr?m : >>>> Ok, I have spent some time trying to get things together, but I do not have configure karma with me today. >>>> >>>> I.e. there are many things one need to build the package that is not in the SVN repository. I am working on a mac btw. >>>> >>>> Autoconf and "automake --add-missing" has helped, as libtoolize that is called from makedist.sh is something I do not have. >>>> >>>> Because of that, I have not really been able to move forward much. >>>> >>>> Can someone help, and build a distribution for me that I can use to build the thing? >>>> >>>> I am close, maybe: >>>> >>>> # ./configure --with-pyldns --disable-gost PYTHON_VERSION=3.2 >>>> : >>>> : >>>> checking whether the C compiler (gcc) accepts the "unused" attribute... yes >>>> configure: creating ./config.status >>>> config.status: creating Makefile >>>> config.status: creating ldns/common.h >>>> config.status: creating ldns/net.h >>>> config.status: creating ldns/util.h >>>> config.status: creating packaging/libldns.pc >>>> config.status: creating packaging/ldns-config >>>> config.status: error: cannot find input file: ldns/config.h.in >>>> >>>> Patrik >>>> >>>> On 16 aug 2011, at 12.04, Ond?ej Sur? wrote: >>>> >>>>> Patrik, >>>>> >>>>> could you also test the Python 3 implementation? It was you who asked about it? >>>>> >>>>> O. >>>>> >>>>> On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Hi Karel, >>>>>> >>>>>> On 08/15/2011 04:24 PM, Karel Slany wrote: >>>>>>> recently I have been toying with the ldns sources in order to make them >>>>>>> compile with Python3 support -- via the './configure --with-pyldns >>>>>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>>>>> autoconf Python detection macros and others to make them work both with >>>>>>> Python 2 and 3. >>>>>> >>>>>> Because we do not maintain these python implementations ourselves, it >>>>>> would be good if other users could tell us if these patches work for >>>>>> Python 2. There are large changes, and we want to support our users. >>>>>> >>>>>> If that works, the patch is likely very nice to accept. Thanks for the >>>>>> good work :-) >>>>>> >>>>>> Best regards, >>>>>> Wouter >>>>>> >>>>>>> The Python3 wrapper does now compile. However, the Python3 support is >>>>>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>>>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>>>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>>>>> Python3. >>>>>>> >>>>>>> This mail contains two patches: >>>>>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>>>>> compile and to run with Python3. It also contains a few working examples >>>>>>> for Python3 which do the same as the original Python2 examples. >>>>>>> >>>>>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>>>>> work -- this patch should fix it. >>>>>>> >>>>>>> The patches are against the 3523 (current) svn revision. >>>>>>> >>>>>>> Best regard >>>>>>> >>>>>>> Karel Slany >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ldns-users mailing list >>>>>>> ldns-users at open.nlnetlabs.nl >>>>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>>>> >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>>>>> >>>>>> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >>>>>> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >>>>>> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >>>>>> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >>>>>> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >>>>>> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >>>>>> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >>>>>> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >>>>>> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >>>>>> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >>>>>> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >>>>>> SYTL+clUdQebb9+RLJWI >>>>>> =yL6p >>>>>> -----END PGP SIGNATURE----- >>>>>> _______________________________________________ >>>>>> ldns-users mailing list >>>>>> ldns-users at open.nlnetlabs.nl >>>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ?Ond?ej Sur? >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> ?Ond?ej Sur? >>> >> >> > > > > -- > ?Ond?ej Sur? > From ondrej at sury.org Mon Aug 22 06:21:44 2011 From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Mon, 22 Aug 2011 08:21:44 +0200 Subject: [ldns-users] adding (partial) Python3 support In-Reply-To: <166FFA26-C67E-4FD3-99AA-3FE8EC9765C3@frobbit.se> References: <4E492C1C.7030307@nic.cz> <4E4A3D69.2080509@nlnetlabs.nl> <166FFA26-C67E-4FD3-99AA-3FE8EC9765C3@frobbit.se> Message-ID: Patrik, you need to run: aclocal autoheader libtoolize -i autoconf # I think autoconf needs to be the last one This works on a clean tree. If your tree is dirty, try adding '-f' to all except aclocal. O. 2011/8/22 Patrik F?ltstr?m : > Did not have autoremake, but autheader existed and solved that problem. Now configure is done. > > Next issue, libtool: > > $ make > ./install-sh ?-c -m 644 ldns/error.h ./include/ldns/ > ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c > make: ./libtool: No such file or directory > make: *** [rdata.o] Error 1 > $ which libtool > /usr/bin/libtool > $ ln -s /usr/bin/libtool . > $ make > ./libtool --tag=CC --quiet --mode=compile gcc -I. -DHAVE_CONFIG_H -Wwrite-strings -W -Wall -O2 -g -I/opt/local/include -c rdata.c > ./libtool: unknown option character `-' in: --tag=CC > Usage: ./libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT] > Usage: ./libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table ] [-seg_addr_table_filename ] [-all_load] [-noall_load] > make: *** [rdata.o] Error 1 > > ? Patrik > > On 21 aug 2011, at 23.15, Ond?ej Sur? wrote: > >> Try autoremake -fi and/or call autoheader. >> >> O. >> >> 2011/8/21 Patrik F?ltstr?m : >>> Ok, I have spent some time trying to get things together, but I do not have configure karma with me today. >>> >>> I.e. there are many things one need to build the package that is not in the SVN repository. I am working on a mac btw. >>> >>> Autoconf and "automake --add-missing" has helped, as libtoolize that is called from makedist.sh is something I do not have. >>> >>> Because of that, I have not really been able to move forward much. >>> >>> Can someone help, and build a distribution for me that I can use to build the thing? >>> >>> I am close, maybe: >>> >>> # ./configure --with-pyldns --disable-gost PYTHON_VERSION=3.2 >>> : >>> : >>> checking whether the C compiler (gcc) accepts the "unused" attribute... yes >>> configure: creating ./config.status >>> config.status: creating Makefile >>> config.status: creating ldns/common.h >>> config.status: creating ldns/net.h >>> config.status: creating ldns/util.h >>> config.status: creating packaging/libldns.pc >>> config.status: creating packaging/ldns-config >>> config.status: error: cannot find input file: ldns/config.h.in >>> >>> ? Patrik >>> >>> On 16 aug 2011, at 12.04, Ond?ej Sur? wrote: >>> >>>> Patrik, >>>> >>>> could you also test the Python 3 implementation? It was you who asked about it? >>>> >>>> O. >>>> >>>> On Tue, Aug 16, 2011 at 11:50, W.C.A. Wijngaards wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Hi Karel, >>>>> >>>>> On 08/15/2011 04:24 PM, Karel Slany wrote: >>>>>> recently I have been toying with the ldns sources in order to make them >>>>>> compile with Python3 support -- via the './configure --with-pyldns >>>>>> PYTHON_VERSION=3' command. I've made several changes to the supplied >>>>>> autoconf Python detection macros and others to make them work both with >>>>>> Python 2 and 3. >>>>> >>>>> Because we do not maintain these python implementations ourselves, it >>>>> would be good if other users could tell us if these patches work for >>>>> Python 2. ?There are large changes, and we want to support our users. >>>>> >>>>> If that works, the patch is likely very nice to accept. ?Thanks for the >>>>> good work :-) >>>>> >>>>> Best regards, >>>>> ? Wouter >>>>> >>>>>> The Python3 wrapper does now compile. However, the Python3 support is >>>>>> incomplete. In Python3 they have abandoned the old C I/O API in favour >>>>>> of the io module. Therefore SWIG does no longer support FILE* typemaps >>>>>> -- i.e. C functions taking FILE* arguments will generate an error in >>>>>> Python3. >>>>>> >>>>>> This mail contains two patches: >>>>>> 1) python3.diff -- Contains modifications enabling the Python3 module to >>>>>> compile and to run with Python3. It also contains a few working examples >>>>>> for Python3 which do the same as the original Python2 examples. >>>>>> >>>>>> 2)ldns_axfr_start.diff -- As I discovered, the ldns-axf example did not >>>>>> work -- this patch should fix it. >>>>>> >>>>>> The patches are against the 3523 (current) svn revision. >>>>>> >>>>>> Best regard >>>>>> >>>>>> Karel Slany >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> ldns-users mailing list >>>>>> ldns-users at open.nlnetlabs.nl >>>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>>> >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>>>> >>>>> iQIcBAEBAgAGBQJOSj1pAAoJEJ9vHC1+BF+NNz8P/2k8lFECWEWeFnMVHGXzUOMO >>>>> /J5XaaLsKyk+4w5apYk1h+aSroO7S0GIsRQtE7YtCBF47yIY3JNXmiS3t5Pel16x >>>>> UsjTiFhqjfADhX+kxFkww5dbihbw2siqOGJa19xCHxlburPlduDHW25Q6hr0DQAJ >>>>> c4PNtBG6WVRgp1mTO9gbWJJIzWC1sIyKo+BhmKwa3U4WCH0AK5ejQWypFgMFTdsq >>>>> uIfNarnj/jiGi7Pzlm6GRwq/tZb9O0cneMNRmWFZLtYcSHU1q7JV+FmJBd4OF+vf >>>>> dWMgxQyiGGlEweNDXrcuNnpvMJBFE+q3jiJ5x8jnuKFgZH/CvzSbCd8neug0zgNN >>>>> l12aV1Wzb2mr5DltF/eFb9uhgEDPWMmUlCinEz5PbLzBOhKf6Qni5XYu98Rmf5SS >>>>> yBQWvHd5VsLzcYgQevW9uxjrj1BxHRPHHuXCE3zlLsV2Z0LqQrhwS+E/fSUv4D4Y >>>>> 91DluZr4bnvYJn6Ra7d6VHGxhShZXMoyLlfcwxpt6pydN7U8kk3Fug4oEU2xGVMs >>>>> 6vCWnciHalKEjCEtL0LPAivmBoGW9HGn5KoOF6mZofYX2PcJh3UbsJoPBfR85xQ7 >>>>> A6q+PIZ5Yj8SgNe3r/N7eZE0W8F8ZY6N5MICc1qtfBpaPIHmrZTygN8/N4/U0F4t >>>>> SYTL+clUdQebb9+RLJWI >>>>> =yL6p >>>>> -----END PGP SIGNATURE----- >>>>> _______________________________________________ >>>>> ldns-users mailing list >>>>> ldns-users at open.nlnetlabs.nl >>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>>> >>>> >>>> >>>> >>>> -- >>>> ?Ond?ej Sur? >>>> >>> >>> >> >> >> >> -- >> ?Ond?ej Sur? >> > > -- ?Ond?ej Sur? From karel.slany at nic.cz Mon Aug 22 11:42:56 2011 From: karel.slany at nic.cz (Karel Slany) Date: Mon, 22 Aug 2011 13:42:56 +0200 Subject: [ldns-users] adding FILE* support for Python3 Message-ID: <4E5240C0.7090408@nic.cz> Hi Wouter, many thanks for applying the previous patches. Here is another one. As promised it contains a workaround to enable SWIG to generate FILE* wrapper code for Python3. The Python2 wrapper code remains unaffected. Here is a brief explanation why this patch does what it does: The I/O in Python2 relies on C standard library -- it uses FILE* and the Python2/C API contains a straightforward solution how to access these structures from C. Python3 uses the io module containing layers of buffers over the low level I/O which the OS provides. The Python3/C file API was reduced -- no more functions for direct FILE* access. Also the io module C API does not contain support for direct FILE* access. The Python3/C file API provides a way how to obtain a file descriptor. But since the Python3 has their own buffers the documentation warns against mixing access between Python3 and OS-level file descriptors. What this patch does: In order to get a valid FILE* pointer from a Python object it wraps a ldns C function which takes a FILE* argument with C code that: * ensures itself whether the object is a file object * flushes the python buffers using a python method call * gets the file descriptor and flags and creates a copy of the file descriptor * opens a FILE* for the descriptor copy * passes the opened FILE* to the wrapped function * after the execution of the function flushes the FILE* and closes it The buffer flushes in Python and C ensure the correct order of written data but also may slow-down the code. I have not tested the performance impacts very thoroughly. The goal was to make FILE* work in Python3. I also do not know what the code will be behaving like when executed in a multi-threaded application. In order to get rid of the sometimes unnecessary buffer flushes the Python3 wrapper can be extended with function opening a file for ldns only. Such an approach, however, introduces an inconvenience of closing/reopening/closing the file when accessing the files from Python (but giving the user control over unnecessary buffer flushing). The patch contains new files to the SVN repository so please do not forget to make the Python3 example scripts executable and to 'svn add' all the new files: chmod +x trunk/contrib/python/examples/python3/ldns-*.py svn add trunk/contrib/python/file_py3.i svn add trunk/contrib/python/examples/python3 I have tested the new code under the GNU/Linux userland using Python 3.1. I intent to test it also under FreeBSD -- don't know whether it would compile under Windows. Best regards, K. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file_py3.diff URL: From wouter at NLnetLabs.nl Mon Aug 22 12:44:14 2011 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Mon, 22 Aug 2011 14:44:14 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E5240C0.7090408@nic.cz> References: <4E5240C0.7090408@nic.cz> Message-ID: <4E524F1E.9080208@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karel, Your effort is commendable, but there looks to be license trouble with it. This is where the trouble seems to be from: +++ trunk/contrib/python/file_py3.i (revision 0) @@ -0,0 +1,122 @@ +/* + * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See + * the COPYRIGHT file for a list of contributors to SWIG and their copyright + * notices.) + * + * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz) + * + * The redistribution and/or modification terms follow the SWIG licensing + * and distribution terms. + */ That COPYRIGHT file is from swig, lists their 100s of authors. So it looks like that file.i was part of the swig sourcecode. The swig sourcecode has the GPLv3 license (they have a legal stuff webpage). Code generated by swig has very liberal licensing, that is what we have now, we use the output of swig to generate code for us. But it seems that file.i was part of the swig sourcecode ... So, that means, assuming it is created by editing the GPLv3 work, that the patch could be hosted in the contrib/ dir, and we explain the license on that patch in a README. And it does not get applied to the main code. Not exactly sure if we should put GPL code in the contrib of a BSD tarball, perhaps a web url advertising the patch would be neater. Not sure if it may be easier to simply have the FILE I/O with python 3 io lib and feed that into the string parser routines of ldns. The ldns project uses the BSD license. Best regards, Wouter On 08/22/2011 01:42 PM, Karel Slany wrote: > Hi Wouter, > > many thanks for applying the previous patches. Here is another one. As > promised it contains a workaround to enable SWIG to generate FILE* > wrapper code for Python3. The Python2 wrapper code remains unaffected. > > Here is a brief explanation why this patch does what it does: > The I/O in Python2 relies on C standard library -- it uses FILE* and > the Python2/C API contains a straightforward solution how to access > these structures from C. > Python3 uses the io module containing layers of buffers over the low > level I/O which the OS provides. The Python3/C file API was reduced -- > no more functions for direct FILE* access. Also the io module C API does > not contain support for direct FILE* access. > The Python3/C file API provides a way how to obtain a file descriptor. > But since the Python3 has their own buffers the documentation warns > against mixing access between Python3 and OS-level file descriptors. > > What this patch does: > In order to get a valid FILE* pointer from a Python object it wraps a > ldns C function which takes a FILE* argument with C code that: > * ensures itself whether the object is a file object > * flushes the python buffers using a python method call > * gets the file descriptor and flags and creates a copy of the file > descriptor > * opens a FILE* for the descriptor copy > * passes the opened FILE* to the wrapped function > * after the execution of the function flushes the FILE* and closes it > > The buffer flushes in Python and C ensure the correct order of written > data but also may slow-down the code. I have not tested the performance > impacts very thoroughly. The goal was to make FILE* work in Python3. I > also do not know what the code will be behaving like when executed in a > multi-threaded application. > > In order to get rid of the sometimes unnecessary buffer flushes the > Python3 wrapper can be extended with function opening a file for ldns > only. Such an approach, however, introduces an inconvenience of > closing/reopening/closing the file when accessing the files from Python > (but giving the user control over unnecessary buffer flushing). > > The patch contains new files to the SVN repository so please do not > forget to make the Python3 example scripts executable and to 'svn add' > all the new files: > > chmod +x trunk/contrib/python/examples/python3/ldns-*.py > svn add trunk/contrib/python/file_py3.i > svn add trunk/contrib/python/examples/python3 > > I have tested the new code under the GNU/Linux userland using Python > 3.1. I intent to test it also under FreeBSD -- don't know whether it > would compile under Windows. > > Best regards, > K. > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOUk8ZAAoJEJ9vHC1+BF+NC2IP/R4ykLLHmSCvc8Ch+N5Z3bTK brQQqJaNR518974flPMBLiBXZ7VWRek3w7695j5rgOrEHKBf94cTSbpbHyvELNmG 7PmoZDgUTURNLcZ45YptK0/T1Cc9uQ7yQlJBeW45xcidZkuvz4Ne/zPeiPgKfxLT OveG0WURmrsz3XJs+up/IDNcWrVfHx1mZT8BKwXQXuxxwwLJm4KgdXewPNvrUeJw 2HF6IyMhjUnfRUNZvZRTSk8WiDMjskZw7hs6jEfspBvFmbZwAlflgj1wmtOtVrzD wDj18p5zfW0Zq+eHcl6sOgh0VC2hgWgelVwuPvLOC8dq4laS08O+WesvF2w4z8iB ZBXlZAoe7OF/eVtve8j0uJm+i1whnD9B4oW+UHa2cHs0PF/MQtsvK8sBo3PcheqP R8ifs/yXFrzSD/HnoKOWcgE9N8ab872i7kwMlIwLQtfOmaY9w7wHjoGRgcpiji00 YCaIcrss8fvjku4SOoPDnLdg8QzlJEkXp2BAeZSGVVbFjkyoRqRDvxTdk7kJY/Ba m9wOe0CFFjK16VYKeXXJLf9RHZW5z69+miPj8elFhblinSmr16H/gYEMx02Kr2GV e8wdk+kL5LnuJZy04uoN8v2CWbOuNNlTTAtVU5xLgT6VISWrkoYlbvpLcN0y1Jc3 1NkLVip3SDVpvaFLMaTE =FIfP -----END PGP SIGNATURE----- From karel.slany at nic.cz Mon Aug 22 15:33:26 2011 From: karel.slany at nic.cz (Karel Slany) Date: Mon, 22 Aug 2011 17:33:26 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E524F1E.9080208@nlnetlabs.nl> References: <4E5240C0.7090408@nic.cz> <4E524F1E.9080208@nlnetlabs.nl> Message-ID: <4E5276C6.3070203@nic.cz> Hello again, I've modified the patch. The source now contains only those statements which can be found in the SWIG documentation. All undocumented code originating from SWIG source/templates has been removed. The file is now BSD licensed. The patch makes the previous posted patch obsolete. The application procedure remains the same. After patching please run: chmod +x trunk/contrib/python/examples/python3/ldns-*.py svn add trunk/contrib/python/file_py3.i svn add trunk/contrib/python/examples/python3 Best regards, K. Dne 22.8.2011 14:44, W.C.A. Wijngaards napsal(a): > Hi Karel, > > Your effort is commendable, but there looks to be license trouble with > it. This is where the trouble seems to be from: > > +++ trunk/contrib/python/file_py3.i (revision 0) > @@ -0,0 +1,122 @@ > +/* > + * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See > + * the COPYRIGHT file for a list of contributors to SWIG and their > copyright > + * notices.) > + * > + * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz) > + * > + * The redistribution and/or modification terms follow the SWIG licensing > + * and distribution terms. > + */ > > That COPYRIGHT file is from swig, lists their 100s of authors. So it > looks like that file.i was part of the swig sourcecode. The swig > sourcecode has the GPLv3 license (they have a legal stuff webpage). > Code generated by swig has very liberal licensing, that is what we have > now, we use the output of swig to generate code for us. But it seems > that file.i was part of the swig sourcecode ... > > So, that means, assuming it is created by editing the GPLv3 work, that > the patch could be hosted in the contrib/ dir, and we explain the > license on that patch in a README. And it does not get applied to the > main code. Not exactly sure if we should put GPL code in the contrib of > a BSD tarball, perhaps a web url advertising the patch would be neater. > > Not sure if it may be easier to simply have the FILE I/O with python 3 > io lib and feed that into the string parser routines of ldns. > > The ldns project uses the BSD license. > > Best regards, > Wouter > > On 08/22/2011 01:42 PM, Karel Slany wrote: >> Hi Wouter, > >> many thanks for applying the previous patches. Here is another one. As >> promised it contains a workaround to enable SWIG to generate FILE* >> wrapper code for Python3. The Python2 wrapper code remains unaffected. > >> Here is a brief explanation why this patch does what it does: >> The I/O in Python2 relies on C standard library -- it uses FILE* and >> the Python2/C API contains a straightforward solution how to access >> these structures from C. >> Python3 uses the io module containing layers of buffers over the low >> level I/O which the OS provides. The Python3/C file API was reduced -- >> no more functions for direct FILE* access. Also the io module C API does >> not contain support for direct FILE* access. >> The Python3/C file API provides a way how to obtain a file descriptor. >> But since the Python3 has their own buffers the documentation warns >> against mixing access between Python3 and OS-level file descriptors. > >> What this patch does: >> In order to get a valid FILE* pointer from a Python object it wraps a >> ldns C function which takes a FILE* argument with C code that: >> * ensures itself whether the object is a file object >> * flushes the python buffers using a python method call >> * gets the file descriptor and flags and creates a copy of the file >> descriptor >> * opens a FILE* for the descriptor copy >> * passes the opened FILE* to the wrapped function >> * after the execution of the function flushes the FILE* and closes it > >> The buffer flushes in Python and C ensure the correct order of written >> data but also may slow-down the code. I have not tested the performance >> impacts very thoroughly. The goal was to make FILE* work in Python3. I >> also do not know what the code will be behaving like when executed in a >> multi-threaded application. > >> In order to get rid of the sometimes unnecessary buffer flushes the >> Python3 wrapper can be extended with function opening a file for ldns >> only. Such an approach, however, introduces an inconvenience of >> closing/reopening/closing the file when accessing the files from Python >> (but giving the user control over unnecessary buffer flushing). > >> The patch contains new files to the SVN repository so please do not >> forget to make the Python3 example scripts executable and to 'svn add' >> all the new files: > >> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >> svn add trunk/contrib/python/file_py3.i >> svn add trunk/contrib/python/examples/python3 > >> I have tested the new code under the GNU/Linux userland using Python >> 3.1. I intent to test it also under FreeBSD -- don't know whether it >> would compile under Windows. > >> Best regards, >> K. > > > >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file_py3_clean.diff URL: From rsvpte at gmail.com Mon Aug 22 18:36:46 2011 From: rsvpte at gmail.com (Rsvp Te) Date: Mon, 22 Aug 2011 11:36:46 -0700 Subject: [ldns-users] Does ldns support querying multiple nameservers from resolv.conf. Message-ID: I do not see drill/ldns trying to send query to seconds name server from the list if the quesry to first one fails (I mean rcode different from LDNS_RCODE_NOERROR). Also I do not see that query considers different search domain if query to a NS results in LDNS_RCODE_NXDOMAIN (3). Am I missing here something, Thanks, Rsv. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbynek.michl at nic.cz Thu Aug 25 11:40:19 2011 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Thu, 25 Aug 2011 13:40:19 +0200 Subject: [ldns-users] Does ldns support querying multiple nameservers from resolv.conf. In-Reply-To: References: Message-ID: <4E5634A3.2020301@nic.cz> Hi Rsv, please check "How to use _searchlist provided by ldns_struct_resolver?" thread in the mailing list (Sep, Oct 2010), it was discussed there already. I have my own solution for both problems, see ds_init_resolver() and ds_resolver_search() functions in https://git.nic.cz/redmine/projects/dnssec-validator/repository/revisions/master/entry/plugin/projects/DNSSECValidatorPlugin/ds.c file. Regards, Zbynek On 22.8.2011 20:36, Rsvp Te wrote: > I do not see drill/ldns trying to send query to seconds name server from the > list if the quesry to first one fails (I mean rcode different from > LDNS_RCODE_NOERROR). > > Also I do not see that query considers different search domain if query to a NS > results in LDNS_RCODE_NXDOMAIN (3). > > Am I missing here something, > > Thanks, > Rsv. > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From willem at NLnetLabs.nl Thu Aug 25 14:15:08 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Thu, 25 Aug 2011 16:15:08 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E5276C6.3070203@nic.cz> References: <4E5240C0.7090408@nic.cz> <4E524F1E.9080208@nlnetlabs.nl> <4E5276C6.3070203@nic.cz> Message-ID: <4E5658EC.5040807@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Karel, The patch is applied to trunk. Hopefully someone would like (and succeed) to test it out now. I did not get it compiled on Ubuntu 11.04 however. In config.log I see: /usr/bin/ld: cannot find -lpython3.2 I do have /usr/lib/libpython3.2mu.a, this I tried to create a symbolic link from /usr/lib/libpython3.2mu.a to /usr/lib/libpython3.2.a just to see if it would link, but then it produced lots and lots of undefined references errors. Apparently some libraries linked to in libpython3.2.a have to be linked with the test as well. I didn't have those problems with python2. I suppose configure.ac still needs some work :) Good luck with that. In the mean time I will give it a try on FreeBSD. Cheers, Willem PS. In the mean time I did found a bug in ldns_rdf.i. On line 170 the variable status is used, but not available. Bedrich? On 22-08-11 17:33, Karel Slany wrote: > Hello again, > > I've modified the patch. The source now contains only those statements > which can be found in the SWIG documentation. All undocumented code > originating from SWIG source/templates has been removed. The file is now > BSD licensed. > > The patch makes the previous posted patch obsolete. The application > procedure remains the same. After patching please run: > > chmod +x trunk/contrib/python/examples/python3/ldns-*.py > svn add trunk/contrib/python/file_py3.i > svn add trunk/contrib/python/examples/python3 > > Best regards, > K. > > Dne 22.8.2011 14:44, W.C.A. Wijngaards napsal(a): >> Hi Karel, >> >> Your effort is commendable, but there looks to be license trouble with >> it. This is where the trouble seems to be from: >> >> +++ trunk/contrib/python/file_py3.i (revision 0) >> @@ -0,0 +1,122 @@ >> +/* >> + * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See >> + * the COPYRIGHT file for a list of contributors to SWIG and their >> copyright >> + * notices.) >> + * >> + * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz) >> + * >> + * The redistribution and/or modification terms follow the SWIG licensing >> + * and distribution terms. >> + */ >> >> That COPYRIGHT file is from swig, lists their 100s of authors. So it >> looks like that file.i was part of the swig sourcecode. The swig >> sourcecode has the GPLv3 license (they have a legal stuff webpage). >> Code generated by swig has very liberal licensing, that is what we have >> now, we use the output of swig to generate code for us. But it seems >> that file.i was part of the swig sourcecode ... >> >> So, that means, assuming it is created by editing the GPLv3 work, that >> the patch could be hosted in the contrib/ dir, and we explain the >> license on that patch in a README. And it does not get applied to the >> main code. Not exactly sure if we should put GPL code in the contrib of >> a BSD tarball, perhaps a web url advertising the patch would be neater. >> >> Not sure if it may be easier to simply have the FILE I/O with python 3 >> io lib and feed that into the string parser routines of ldns. >> >> The ldns project uses the BSD license. >> >> Best regards, >> Wouter >> >> On 08/22/2011 01:42 PM, Karel Slany wrote: >>> Hi Wouter, >> >>> many thanks for applying the previous patches. Here is another one. As >>> promised it contains a workaround to enable SWIG to generate FILE* >>> wrapper code for Python3. The Python2 wrapper code remains unaffected. >> >>> Here is a brief explanation why this patch does what it does: >>> The I/O in Python2 relies on C standard library -- it uses FILE* and >>> the Python2/C API contains a straightforward solution how to access >>> these structures from C. >>> Python3 uses the io module containing layers of buffers over the low >>> level I/O which the OS provides. The Python3/C file API was reduced -- >>> no more functions for direct FILE* access. Also the io module C API does >>> not contain support for direct FILE* access. >>> The Python3/C file API provides a way how to obtain a file descriptor. >>> But since the Python3 has their own buffers the documentation warns >>> against mixing access between Python3 and OS-level file descriptors. >> >>> What this patch does: >>> In order to get a valid FILE* pointer from a Python object it wraps a >>> ldns C function which takes a FILE* argument with C code that: >>> * ensures itself whether the object is a file object >>> * flushes the python buffers using a python method call >>> * gets the file descriptor and flags and creates a copy of the file >>> descriptor >>> * opens a FILE* for the descriptor copy >>> * passes the opened FILE* to the wrapped function >>> * after the execution of the function flushes the FILE* and closes it >> >>> The buffer flushes in Python and C ensure the correct order of written >>> data but also may slow-down the code. I have not tested the performance >>> impacts very thoroughly. The goal was to make FILE* work in Python3. I >>> also do not know what the code will be behaving like when executed in a >>> multi-threaded application. >> >>> In order to get rid of the sometimes unnecessary buffer flushes the >>> Python3 wrapper can be extended with function opening a file for ldns >>> only. Such an approach, however, introduces an inconvenience of >>> closing/reopening/closing the file when accessing the files from Python >>> (but giving the user control over unnecessary buffer flushing). >> >>> The patch contains new files to the SVN repository so please do not >>> forget to make the Python3 example scripts executable and to 'svn add' >>> all the new files: >> >>> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >>> svn add trunk/contrib/python/file_py3.i >>> svn add trunk/contrib/python/examples/python3 >> >>> I have tested the new code under the GNU/Linux userland using Python >>> 3.1. I intent to test it also under FreeBSD -- don't know whether it >>> would compile under Windows. >> >>> Best regards, >>> K. >> >> >> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVljsAAoJEOX4+CEvd6SYWYAP/in4wkMy2f8auCqHck21O94R auY1NjttZ9evVmRpBkXvxCF9ulf3WtKsZIQ54b+kpQxSQSoCorZnZIbi9BusXf9K NBNVxVRTs9A9dM1Z9iW/cSNqE4gJoQVM0hMGqHTYlPu7JsjciTHUwulcDR9f4FmH w61yTKEITXP3L2m5BQ9IsMuJXyGu+ryN7pcf3l/v1lx5ZUQ8u3clHpQpm7LXO9fN wnJzy3CbFPkaZcD8TYb9oq1w/SZNVw0IgnPOErIjgGbXYkTLrtKKkSXWvyQh/Xjs wXtI0q56TPxWZOF7JcPSiZz4n8tEhkLqj8PspeBvrkkiToz5hsL0UP74B+K9SAn2 KIZqAKBSKmtTG8jh5Wq56jEeBEp1C1MmQ8Vdd/+Nke7yGSTduaz8TXDAfnfY82rq kKZbLohXE4M6G2moXdVQlv7JO6rKQpjs4y//SDUfVcalfIYlpGvBu+6CZbfT1ia7 6GsAcrAAJEAP9kBTyTYaVLA57N+MzirvobFIWcVzNZFe7fPLei7nb7LUTnOxO0hz A9Qc+deXuPXMoB53q7vrxG4yKlH5InCRCilvZk5IGH+hKXf5LKdC3ymxG5QyOZsU 0uEzKWpqHczu/Ju9AiOOjAoKv50Fotq9pM5+Qy6cWVeEiqY7mvE4y8jLxuwpTKeH NAOek19lUWs+YRtN8CsU =Vwdf -----END PGP SIGNATURE----- From willem at NLnetLabs.nl Thu Aug 25 14:33:38 2011 From: willem at NLnetLabs.nl (Willem Toorop) Date: Thu, 25 Aug 2011 16:33:38 +0200 Subject: [ldns-users] Does ldns support querying multiple nameservers from resolv.conf. In-Reply-To: References: Message-ID: <4E565D42.3000101@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rsvp, I would like to look into this. To prevent this from falling of the table, could you make a (maybe a bit more detailed) bug report in our bugzilla system: http://www.nlnetlabs.nl/projects/ldns/bugs Thanks! Willem On 22-08-11 20:36, Rsvp Te wrote: > I do not see drill/ldns trying to send query to seconds name server from > the list if the quesry to first one fails (I mean rcode different from > LDNS_RCODE_NOERROR). > > Also I do not see that query considers different search domain if query > to a NS results in LDNS_RCODE_NXDOMAIN (3). > > Am I missing here something, > > Thanks, > Rsv. > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOVl1BAAoJEOX4+CEvd6SYYOsQAKRiIsczLiP3aSnIAnP51OZl Yx6xpN7/3e77B+LPUpBT5R2B1EXlnO/yRLa8ZkHLqslN3fFQKQ4iIpQ+1xrWd1t4 WXuyX7z606yOzibf+mEhi/UgQ3Yi5Zj9mjkAwZt9wZv/hfJEYvOdXjqeNv7+pt4P V+8CvzKUvtryZyCOS4bObOAwhjSGjUkapJz1GeFzcdyAkv35mJntfhQx+2o/PwM4 VNR/tKpwyko6IJNUizlnuFU60hap9wV7UZewkcXP0JMjmZSSFcm9ebZoZQWxQ68G 4cDJ/aFGDfn5R5jP9Sykm6CqNIU9fRYqqNmxQUtelzE+jOweJy+XqGi9fAgTjKf8 Q5ZNxFTn7Jk5Q6hRPEI/5XjzVLAMso7MCXgDmWqwQkMSH5qnUfYx9yLt8PE/oYLE 0dcDhMoa3/ndlpjv5UVn3BXedh8cpRJcMAqIV8ZkNdTV4rXjgGR7I15Iaw/zvmgI 7EM1itX51pOUWZuyHpLGlOb9UuV3gPLba0Fpoyl3xBuSPlPa28xZCc2lhfy8bTwJ HIX4+Fu0FIgE9JVV/5wnvSZtNsAUjWKT8cRvzgNT8oPJHIByU7YwK/YNKsAPE5mm OGxAkLRjxkHY5XQ8fJ6bPIIC75GvLgmjbYeiv5QLJcm1U80wadvHHFPU5sHWtpJK 17OYajCY/KD1CoB1G2II =YBR9 -----END PGP SIGNATURE----- From karel.slany at nic.cz Thu Aug 25 16:43:11 2011 From: karel.slany at nic.cz (Karel Slany) Date: Thu, 25 Aug 2011 18:43:11 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E5658EC.5040807@nlnetlabs.nl> References: <4E5240C0.7090408@nic.cz> <4E524F1E.9080208@nlnetlabs.nl> <4E5276C6.3070203@nic.cz> <4E5658EC.5040807@nlnetlabs.nl> Message-ID: <4E567B9F.70207@nic.cz> Hello Willem, I've installed python3.2 on my Gentoo to reproduce your problem. However, the compilation succeeded. But I've run into an additional incompatibility problem. The issue is described in the SWIG bug tracker http://sourceforge.net/tracker/index.php?func=detail&aid=3057804&group_id=1645&atid=101645 and appears to be solved in SWIG-2.0.4. I'm going to test it and consequently post another patch. Best regards, K. Dne 25.8.2011 16:15, Willem Toorop napsal(a): > Hi Karel, > > The patch is applied to trunk. Hopefully someone would like (and > succeed) to test it out now. > > I did not get it compiled on Ubuntu 11.04 however. In config.log I see: > > /usr/bin/ld: cannot find -lpython3.2 > > I do have /usr/lib/libpython3.2mu.a, this I tried to create a symbolic > link from /usr/lib/libpython3.2mu.a to /usr/lib/libpython3.2.a just to > see if it would link, but then it produced lots and lots of undefined > references errors. > Apparently some libraries linked to in libpython3.2.a have to be linked > with the test as well. > > I didn't have those problems with python2. I suppose configure.ac still > needs some work :) Good luck with that. In the mean time I will give it > a try on FreeBSD. > > Cheers, Willem > > PS. In the mean time I did found a bug in ldns_rdf.i. On line 170 the > variable status is used, but not available. Bedrich? > > On 22-08-11 17:33, Karel Slany wrote: >> Hello again, > >> I've modified the patch. The source now contains only those statements >> which can be found in the SWIG documentation. All undocumented code >> originating from SWIG source/templates has been removed. The file is now >> BSD licensed. > >> The patch makes the previous posted patch obsolete. The application >> procedure remains the same. After patching please run: > >> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >> svn add trunk/contrib/python/file_py3.i >> svn add trunk/contrib/python/examples/python3 > >> Best regards, >> K. > >> Dne 22.8.2011 14:44, W.C.A. Wijngaards napsal(a): >>> Hi Karel, >>> >>> Your effort is commendable, but there looks to be license trouble with >>> it. This is where the trouble seems to be from: >>> >>> +++ trunk/contrib/python/file_py3.i (revision 0) >>> @@ -0,0 +1,122 @@ >>> +/* >>> + * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See >>> + * the COPYRIGHT file for a list of contributors to SWIG and their >>> copyright >>> + * notices.) >>> + * >>> + * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz) >>> + * >>> + * The redistribution and/or modification terms follow the SWIG licensing >>> + * and distribution terms. >>> + */ >>> >>> That COPYRIGHT file is from swig, lists their 100s of authors. So it >>> looks like that file.i was part of the swig sourcecode. The swig >>> sourcecode has the GPLv3 license (they have a legal stuff webpage). >>> Code generated by swig has very liberal licensing, that is what we have >>> now, we use the output of swig to generate code for us. But it seems >>> that file.i was part of the swig sourcecode ... >>> >>> So, that means, assuming it is created by editing the GPLv3 work, that >>> the patch could be hosted in the contrib/ dir, and we explain the >>> license on that patch in a README. And it does not get applied to the >>> main code. Not exactly sure if we should put GPL code in the contrib of >>> a BSD tarball, perhaps a web url advertising the patch would be neater. >>> >>> Not sure if it may be easier to simply have the FILE I/O with python 3 >>> io lib and feed that into the string parser routines of ldns. >>> >>> The ldns project uses the BSD license. >>> >>> Best regards, >>> Wouter >>> >>> On 08/22/2011 01:42 PM, Karel Slany wrote: >>>> Hi Wouter, >>> >>>> many thanks for applying the previous patches. Here is another one. As >>>> promised it contains a workaround to enable SWIG to generate FILE* >>>> wrapper code for Python3. The Python2 wrapper code remains unaffected. >>> >>>> Here is a brief explanation why this patch does what it does: >>>> The I/O in Python2 relies on C standard library -- it uses FILE* and >>>> the Python2/C API contains a straightforward solution how to access >>>> these structures from C. >>>> Python3 uses the io module containing layers of buffers over the low >>>> level I/O which the OS provides. The Python3/C file API was reduced -- >>>> no more functions for direct FILE* access. Also the io module C API does >>>> not contain support for direct FILE* access. >>>> The Python3/C file API provides a way how to obtain a file descriptor. >>>> But since the Python3 has their own buffers the documentation warns >>>> against mixing access between Python3 and OS-level file descriptors. >>> >>>> What this patch does: >>>> In order to get a valid FILE* pointer from a Python object it wraps a >>>> ldns C function which takes a FILE* argument with C code that: >>>> * ensures itself whether the object is a file object >>>> * flushes the python buffers using a python method call >>>> * gets the file descriptor and flags and creates a copy of the file >>>> descriptor >>>> * opens a FILE* for the descriptor copy >>>> * passes the opened FILE* to the wrapped function >>>> * after the execution of the function flushes the FILE* and closes it >>> >>>> The buffer flushes in Python and C ensure the correct order of written >>>> data but also may slow-down the code. I have not tested the performance >>>> impacts very thoroughly. The goal was to make FILE* work in Python3. I >>>> also do not know what the code will be behaving like when executed in a >>>> multi-threaded application. >>> >>>> In order to get rid of the sometimes unnecessary buffer flushes the >>>> Python3 wrapper can be extended with function opening a file for ldns >>>> only. Such an approach, however, introduces an inconvenience of >>>> closing/reopening/closing the file when accessing the files from Python >>>> (but giving the user control over unnecessary buffer flushing). >>> >>>> The patch contains new files to the SVN repository so please do not >>>> forget to make the Python3 example scripts executable and to 'svn add' >>>> all the new files: >>> >>>> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >>>> svn add trunk/contrib/python/file_py3.i >>>> svn add trunk/contrib/python/examples/python3 >>> >>>> I have tested the new code under the GNU/Linux userland using Python >>>> 3.1. I intent to test it also under FreeBSD -- don't know whether it >>>> would compile under Windows. >>> >>>> Best regards, >>>> K. >>> >>> >>> >>>> _______________________________________________ >>>> ldns-users mailing list >>>> ldns-users at open.nlnetlabs.nl >>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>> >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > > > >> _______________________________________________ >> ldns-users mailing list >> ldns-users at open.nlnetlabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > _______________________________________________ ldns-users mailing list ldns-users at open.nlnetlabs.nl http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From paul at xelerance.com Thu Aug 25 20:32:55 2011 From: paul at xelerance.com (Paul Wouters) Date: Thu, 25 Aug 2011 16:32:55 -0400 (EDT) Subject: [ldns-users] pyLDNS Problems Message-ID: Forwarding on behalve of Chris, ---------- Forwarded message ---------- From:?Christopher Olah To:?ldns-users at open.nlnetlabs.nl Date:?Thu, 25 Aug 2011 15:15:52 -0400 Subject:?pyLDNS Problems Hey all, Over the last few months I've made extensive use of pyLDNS and even written a wrapper over it, ldnsx (http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=summary). I've ran a number of bugs, many of which you seem to have resolved in the latest release. Still, there remain some that are deeply problematic for me: (1) ldns_resolver stops responding Creating reproducible errors here is tricky, because things are so dependent on the state of things outside my control. However, the following code has been demonstrating it quite reliability on centos6 with pyLDNS 1.3.40 import ldns ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf") #Drop nameservers while self._ldns_resolver.pop_nameserver(): ? ?pass #Set nameserver to xelerance's to aid repropducability address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65") ldns_resolver.push_nameserver(address) #Make queries. The first will work OK, but the next two will break. print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN ) It just returns Nones. Contrast this with dig ANY xelerance.com @76.10.157.65 Some observations: This bug seems to be associated with truncated packets. Using ldns_resolver.set_usevc(True) will make the above code run smoothly. On the other hand, it doesn't seem to be the only thing going on here. I've had the exact same code run fine on the past (though there was a server change since this particular example started failing consistently) and I've had other examples that weren't truncated fail in the past. Another observation: If you run with ldns_resolver._debug = True, it will print: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; xelerance.com. ? ? ? IN ? ? ?ANY ;; ANSWER SECTION: ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 0 msec ;; WHEN: Thu Aug 25 14:25:13 2011 ;; MSG SIZE ?rcvd: 0 My experience with this bug is that it will stop occurring seemingly at random... (2) Random segfaults I don't have any reproducible instances of this bug in the latest version of pyLDNS, though calls to ldnsx.get_rrs will consistently cause it to segfault in older versions. Translating it into ldns code would be somewhat tedious and long, so I'll leave it out. This isn't an overly big issue, since it has become quite infrequent in the latest release. Christopher Olah From bedrich.kosata at nic.cz Fri Aug 26 06:25:36 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Fri, 26 Aug 2011 08:25:36 +0200 Subject: [ldns-users] pyLDNS Problems In-Reply-To: References: Message-ID: <4E573C60.7070200@nic.cz> Dear Chris, regarding the segfaults you mentioned, the whole process of extracting RRs from a packet, RDFs from a RR, etc. was reworked, which should have fixed related segfaults. If you find any such problems still occurring, even though less often, it would be great if you could pinpoint the problem to some specific part of code, because it could mean some bug in the current solution (or some unrelated, not yet discovered issue). Best regards Beda On 08/25/2011 10:32 PM, Paul Wouters wrote: > > Forwarding on behalve of Chris, > > ---------- Forwarded message ---------- > From: Christopher Olah > To: ldns-users at open.nlnetlabs.nl > Date: Thu, 25 Aug 2011 15:15:52 -0400 > Subject: pyLDNS Problems > > Hey all, > > Over the last few months I've made extensive use of pyLDNS and even > written a wrapper over it, ldnsx > (http://git.xelerance.com/cgi-bin/gitweb.cgi?p=ldnsx.git;a=summary). > I've ran a number of bugs, many of which you seem to have resolved in > the latest release. Still, there remain some that are deeply > problematic for me: > > (1) ldns_resolver stops responding > > Creating reproducible errors here is tricky, because things are so > dependent on the state of things outside my control. However, the > following code has been demonstrating it quite reliability on centos6 > with pyLDNS 1.3.40 > > import ldns > > ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf") > #Drop nameservers > while self._ldns_resolver.pop_nameserver(): > pass > #Set nameserver to xelerance's to aid repropducability > address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65") > ldns_resolver.push_nameserver(address) > #Make queries. The first will work OK, but the next two will break. > print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) > print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) > print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, > ldns.LDNS_RR_CLASS_IN ) > > It just returns Nones. Contrast this with dig ANY xelerance.com > @76.10.157.65 > > Some observations: This bug seems to be associated with truncated > packets. Using > > ldns_resolver.set_usevc(True) > > will make the above code run smoothly. On the other hand, it doesn't > seem to be the only thing going on here. I've had the exact same code > run fine on the past (though there was a server change since this > particular example started failing consistently) and I've had other > examples that weren't truncated fail in the past. > > Another observation: If you run with ldns_resolver._debug = True, it > will print: > > ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 > ;; flags: rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;; xelerance.com. IN ANY > > ;; ANSWER SECTION: > > ;; AUTHORITY SECTION: > > ;; ADDITIONAL SECTION: > > ;; Query time: 0 msec > ;; WHEN: Thu Aug 25 14:25:13 2011 > ;; MSG SIZE rcvd: 0 > > My experience with this bug is that it will stop occurring seemingly > at random... > > (2) Random segfaults > > I don't have any reproducible instances of this bug in the latest > version of pyLDNS, though calls to ldnsx.get_rrs will consistently > cause it to segfault in older versions. Translating it into ldns code > would be somewhat tedious and long, so I'll leave it out. > > This isn't an overly big issue, since it has become quite infrequent > in the latest release. > > Christopher Olah > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -- Bedrich Kosata CZ.NIC Labs From bedrich.kosata at nic.cz Fri Aug 26 06:37:34 2011 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Fri, 26 Aug 2011 08:37:34 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E5658EC.5040807@nlnetlabs.nl> References: <4E5240C0.7090408@nic.cz> <4E524F1E.9080208@nlnetlabs.nl> <4E5276C6.3070203@nic.cz> <4E5658EC.5040807@nlnetlabs.nl> Message-ID: <4E573F2E.2080301@nic.cz> Hi Willem, On 08/25/2011 04:15 PM, Willem Toorop wrote: > > PS. In the mean time I did found a bug in ldns_rdf.i. On line 170 the > variable status is used, but not available. Bedrich? > This is indeed a bug. It seems like a copy-paste error. The line should something like: if (raiseException): raise Exception("Can't create RDF of type '%s' from '%s'." % (rr_type, str)) Cheers Beda -- Bedrich Kosata CZ.NIC Labs From karel.slany at nic.cz Fri Aug 26 11:36:44 2011 From: karel.slany at nic.cz (Karel Slany) Date: Fri, 26 Aug 2011 13:36:44 +0200 Subject: [ldns-users] adding FILE* support for Python3 In-Reply-To: <4E567B9F.70207@nic.cz> References: <4E5240C0.7090408@nic.cz> <4E524F1E.9080208@nlnetlabs.nl> <4E5276C6.3070203@nic.cz> <4E5658EC.5040807@nlnetlabs.nl> <4E567B9F.70207@nic.cz> Message-ID: <4E57854C.5030001@nic.cz> Hi Willem, I've modified the configure.ac to perform an additional test for the presence of >=SWIG-2.0.4 when compiling with Python >=3.2 support. The usage of SWIG-2.0.4 is, in this case, necessary. However according to the autoconf-archive the so far used SWIG m4 macros have some version checking and Ubuntu specific issues. http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_pkg_swig.m4 Therefore I've also added the current version of autoconf SWIG macros which is making the old SWIG m4 file obsolete. After applying the patch please run: svn rm --force trunk/ac_pkg_swig.m4 svn add trunk/ax_pkg_swig.m4 Best regards, K. Dne 25.8.2011 18:43, Karel Slany napsal(a): > Hello Willem, > > I've installed python3.2 on my Gentoo to reproduce your problem. > However, the compilation succeeded. > > But I've run into an additional incompatibility problem. The issue is > described in the SWIG bug tracker > http://sourceforge.net/tracker/index.php?func=detail&aid=3057804&group_id=1645&atid=101645 > and appears to be solved in SWIG-2.0.4. I'm going to test it and > consequently post another patch. > > Best regards, > K. > > > Dne 25.8.2011 16:15, Willem Toorop napsal(a): >> Hi Karel, >> >> The patch is applied to trunk. Hopefully someone would like (and >> succeed) to test it out now. >> >> I did not get it compiled on Ubuntu 11.04 however. In config.log I see: >> >> /usr/bin/ld: cannot find -lpython3.2 >> >> I do have /usr/lib/libpython3.2mu.a, this I tried to create a symbolic >> link from /usr/lib/libpython3.2mu.a to /usr/lib/libpython3.2.a just to >> see if it would link, but then it produced lots and lots of undefined >> references errors. >> Apparently some libraries linked to in libpython3.2.a have to be linked >> with the test as well. >> >> I didn't have those problems with python2. I suppose configure.ac still >> needs some work :) Good luck with that. In the mean time I will give it >> a try on FreeBSD. >> >> Cheers, Willem >> >> PS. In the mean time I did found a bug in ldns_rdf.i. On line 170 the >> variable status is used, but not available. Bedrich? >> >> On 22-08-11 17:33, Karel Slany wrote: >>> Hello again, >> >>> I've modified the patch. The source now contains only those statements >>> which can be found in the SWIG documentation. All undocumented code >>> originating from SWIG source/templates has been removed. The file is now >>> BSD licensed. >> >>> The patch makes the previous posted patch obsolete. The application >>> procedure remains the same. After patching please run: >> >>> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >>> svn add trunk/contrib/python/file_py3.i >>> svn add trunk/contrib/python/examples/python3 >> >>> Best regards, >>> K. >> >>> Dne 22.8.2011 14:44, W.C.A. Wijngaards napsal(a): >>>> Hi Karel, >>>> >>>> Your effort is commendable, but there looks to be license trouble with >>>> it. This is where the trouble seems to be from: >>>> >>>> +++ trunk/contrib/python/file_py3.i (revision 0) >>>> @@ -0,0 +1,122 @@ >>>> +/* >>>> + * file_py3.i: Typemaps for FILE* for Python 3. Based on SWIG's file.i (See >>>> + * the COPYRIGHT file for a list of contributors to SWIG and their >>>> copyright >>>> + * notices.) >>>> + * >>>> + * Copyright (c) 2011, Karel Slany (karel.slany AT nic.cz) >>>> + * >>>> + * The redistribution and/or modification terms follow the SWIG licensing >>>> + * and distribution terms. >>>> + */ >>>> >>>> That COPYRIGHT file is from swig, lists their 100s of authors. So it >>>> looks like that file.i was part of the swig sourcecode. The swig >>>> sourcecode has the GPLv3 license (they have a legal stuff webpage). >>>> Code generated by swig has very liberal licensing, that is what we have >>>> now, we use the output of swig to generate code for us. But it seems >>>> that file.i was part of the swig sourcecode ... >>>> >>>> So, that means, assuming it is created by editing the GPLv3 work, that >>>> the patch could be hosted in the contrib/ dir, and we explain the >>>> license on that patch in a README. And it does not get applied to the >>>> main code. Not exactly sure if we should put GPL code in the contrib of >>>> a BSD tarball, perhaps a web url advertising the patch would be neater. >>>> >>>> Not sure if it may be easier to simply have the FILE I/O with python 3 >>>> io lib and feed that into the string parser routines of ldns. >>>> >>>> The ldns project uses the BSD license. >>>> >>>> Best regards, >>>> Wouter >>>> >>>> On 08/22/2011 01:42 PM, Karel Slany wrote: >>>>> Hi Wouter, >>>> >>>>> many thanks for applying the previous patches. Here is another one. As >>>>> promised it contains a workaround to enable SWIG to generate FILE* >>>>> wrapper code for Python3. The Python2 wrapper code remains unaffected. >>>> >>>>> Here is a brief explanation why this patch does what it does: >>>>> The I/O in Python2 relies on C standard library -- it uses FILE* and >>>>> the Python2/C API contains a straightforward solution how to access >>>>> these structures from C. >>>>> Python3 uses the io module containing layers of buffers over the low >>>>> level I/O which the OS provides. The Python3/C file API was reduced -- >>>>> no more functions for direct FILE* access. Also the io module C API does >>>>> not contain support for direct FILE* access. >>>>> The Python3/C file API provides a way how to obtain a file descriptor. >>>>> But since the Python3 has their own buffers the documentation warns >>>>> against mixing access between Python3 and OS-level file descriptors. >>>> >>>>> What this patch does: >>>>> In order to get a valid FILE* pointer from a Python object it wraps a >>>>> ldns C function which takes a FILE* argument with C code that: >>>>> * ensures itself whether the object is a file object >>>>> * flushes the python buffers using a python method call >>>>> * gets the file descriptor and flags and creates a copy of the file >>>>> descriptor >>>>> * opens a FILE* for the descriptor copy >>>>> * passes the opened FILE* to the wrapped function >>>>> * after the execution of the function flushes the FILE* and closes it >>>> >>>>> The buffer flushes in Python and C ensure the correct order of written >>>>> data but also may slow-down the code. I have not tested the performance >>>>> impacts very thoroughly. The goal was to make FILE* work in Python3. I >>>>> also do not know what the code will be behaving like when executed in a >>>>> multi-threaded application. >>>> >>>>> In order to get rid of the sometimes unnecessary buffer flushes the >>>>> Python3 wrapper can be extended with function opening a file for ldns >>>>> only. Such an approach, however, introduces an inconvenience of >>>>> closing/reopening/closing the file when accessing the files from Python >>>>> (but giving the user control over unnecessary buffer flushing). >>>> >>>>> The patch contains new files to the SVN repository so please do not >>>>> forget to make the Python3 example scripts executable and to 'svn add' >>>>> all the new files: >>>> >>>>> chmod +x trunk/contrib/python/examples/python3/ldns-*.py >>>>> svn add trunk/contrib/python/file_py3.i >>>>> svn add trunk/contrib/python/examples/python3 >>>> >>>>> I have tested the new code under the GNU/Linux userland using Python >>>>> 3.1. I intent to test it also under FreeBSD -- don't know whether it >>>>> would compile under Windows. >>>> >>>>> Best regards, >>>>> K. >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> ldns-users mailing list >>>>> ldns-users at open.nlnetlabs.nl >>>>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >>>> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> >> >> >> >>> _______________________________________________ >>> ldns-users mailing list >>> ldns-users at open.nlnetlabs.nl >>> http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >> > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: py3.2_swig_dependency.diff URL: