I started working on getting unbound work with Python 3.x and here are the first results. With the attached patches, the unbound source code still builds with Python 2.x but also builds with Python 3.x.
To test it, you need to configure the sources to build all the python stuff:
./configure --with-pythonmodule --with-pyunbound
So far I tested on Gentoo with the exact command above, as /usr/bin/python is Python 3.x by default. I also tested it using a live Gentoo ebuild[1] and I'm going to build it for Fedora[2] as part of the feature to use Python 3.x as the default implementation on Fedora[3].
Note that the two patches represent the minimal changes needed to *build* unbound with Python 3.x, that doesn't say whether the successful build will also *work* properly, it is just the first step for it. Next step will be to identify the issues that arise.
Plus it clears out some parts that are not needed and are buggy
anyway.
Please update generated files accordingly (or remove them from
source control).
Cheers,
Pavel
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl> To: "Pavel
Simerda" <psimerda@redhat.com> Sent: Thursday, September 18, 2014
3:33:12 PM Subject: Re: [Unbound-users] patches to also build
with Python 3.x
Hi Pavel,
Thanks! I have committed the two patches. The aclocal.m4 that my
aclocal produces is not changed, but I took the configure.ac and
acx_python updates. (and the .i file updates, of course).
Best regards, Wouter
Hi,
I started working on getting unbound work with Python 3.x and
here are the first results. With the attached patches, the
unbound source code still builds with Python 2.x but also
builds with Python 3.x.
To test it, you need to configure the sources to build all
the python stuff:
./configure --with-pythonmodule --with-pyunbound
So far I tested on Gentoo with the exact command above, as
/usr/bin/python is Python 3.x by default. I also tested it
using a live Gentoo ebuild[1] and I'm going to build it for
Fedora[2] as part of the feature to use Python 3.x as the
default implementation on Fedora[3].
Not everyone has autoconf ready, thus the generated files in the
repository; this makes the repository as easy to use as a tarball from
the download page.
Best regards,
Wouter
Thanks! Did you consider removing the generated files?
Pavel
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl> To: "Pavel
Simerda" <psimerda@redhat.com> Cc: unbound-users@unbound.net
Sent: Friday, September 19, 2014 11:57:57 AM Subject: Re:
[Unbound-users] patches to also build with Python 3.x
Hi Pavel,
Thanks, applied with the previous patches.
Best regards, Wouter
Hi,
I'm posting another patch to fix searching of
/usr/lib64/libpython3.4m.so
Plus it clears out some parts that are not needed and are
buggy anyway.
Please update generated files accordingly (or remove them
from source control).
Cheers,
Pavel
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl> To: "Pavel
Simerda" <psimerda@redhat.com> Sent: Thursday, September
18, 2014 3:33:12 PM Subject: Re: [Unbound-users] patches to
also build with Python 3.x
Hi Pavel,
Thanks! I have committed the two patches. The aclocal.m4
that my aclocal produces is not changed, but I took the
configure.ac and acx_python updates. (and the .i file
updates, of course).
Best regards, Wouter
Hi,
I started working on getting unbound work with Python
3.x and here are the first results. With the attached
patches, the unbound source code still builds with
Python 2.x but also builds with Python 3.x.
To test it, you need to configure the sources to build
all the python stuff:
./configure --with-pythonmodule --with-pyunbound
So far I tested on Gentoo with the exact command above,
as /usr/bin/python is Python 3.x by default. I also
tested it using a live Gentoo ebuild[1] and I'm going
to build it for Fedora[2] as part of the feature to use
Python 3.x as the default implementation on Fedora[3].
I have more python 3.x related patches, that seem to be safe for python 2.x as well, please push.
I also found out that the 2.x version is working with byte strings which is not ideal as we're working with internationalized DNS data as well. It might be useful to include internationalization in the tests and we'll probably find out that we also need to use unicode strings with python 2.x and thus introduce not entirely compatible changes. Any thoughts on this?