Please python3 support. The source code is available from: http://www.dnspython.org/kits3/
The way they're doing this is just way annoying.
Well, it seems that they release in sync, so we could possibly set up a single ebuild with two tarballs.
net-im/err-2.1.0 bump would benefit from this.
Hello, I've spend a bit of time, borrowing code from dev-python/unittest2 and I've got this package : http://cgit.thetys-retz.net/overlay/tree/dev-python/dnspython If any of you want to review this code, I may also attach to the bug report. Happy GNU Year ;-)
Created attachment 392324 [details] dev-python/dnspython-1.11.1-r1 ebuild proposal
Created attachment 392326 [details] dev-python/dnspython-1.12.0-r1 ebuild proposal
(In reply to Leho Kraav (:macmaN @lkraav) from comment #3) > net-im/err-2.1.0 bump would benefit from this. app-text/calibre may also benefit from this improvement !!!
Hmm, well, ebuild dnspython-1.11.1-r1.ebuild test fails, so this need a bit of work on the test part.
*dnspython-1.12.0-r1 (06 Mar 2015) 06 Mar 2015; Ian Delaney <idella4@gentoo.org> +dnspython-1.12.0-r1.ebuild: revbump; add py3 support by addition of dnspython3 tarball, SRC_URI updated, virtual re-write, assistance from NP-Hardass in achieving final form of the ebuild
Unfortunately, I just tested this ebuild and it installs the python 2 source for python 3 breaking use of dnspython in python 3. The problem appears during the prepare step where the python 2 version is copied into the python 3 WORKDIR. Also, the python 2 sources are still fetched and unpacked even when PYTHON_TARGETS does not include python2_7. This combination means even without a python 2 target the install is broken.
I'm not very familiar with the distutils-r1 eclass but as far as I can tell the prepare_all fires first, performing the copy that causes the problem. Then the version-specific prepare phases are run which are essentially nops.
(In reply to Daniel M. Weeks from comment #11) > I'm not very familiar with the distutils-r1 eclass but as far as I can tell > the prepare_all fires first, performing the copy that causes the problem. > Then the version-specific prepare phases are run which are essentially nops. The way it was implemented simply doesn't work. Should be working now. commit 455634fa7080a3aa5437871558552d722efbfe70 Author: Justin Lecher <jlec@gentoo.org> Date: Fri Oct 30 11:05:55 2015 +0100 dev-python/dnspython: Conver to py ABI slotted ebuilds Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=484954 Package-Manager: portage-2.2.23 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=455634fa7080a3aa5437871558552d722efbfe70
(In reply to Justin Lecher from comment #12) > The way it was implemented simply doesn't work. Should be working now. the usual dev-python/dnspython[${PYTHON_USEDEP}] is broken now. Is it possible to normalize it to that format? I was thinking about creating a virtual ebuild, but it might be an overkill
fyi, I came up with the following workaround for now: - dev-python/dnspython[${PYTHON_USEDEP}] + !dev-python/dnspython:0 + $(python_gen_useflags 'python2*')? ( dev-python/dnspython:py2 ) + $(python_gen_useflags 'python3*')? ( dev-python/dnspython:py3 )
(In reply to Anton Bolshakov from comment #13) > (In reply to Justin Lecher from comment #12) > > The way it was implemented simply doesn't work. Should be working now. > > the usual dev-python/dnspython[${PYTHON_USEDEP}] is broken now. > > Is it possible to normalize it to that format? I was thinking about creating > a virtual ebuild, but it might be an overkill You need to use the virtual now. I anything broken with it?
oh, there is a new "virtual/dnspython" ebuild. Ok, that will do it. It is not listed in your commit. Thanks!
