I'm working on adding a python 3 stack to Fedora 13, parallel-installable with
the main python 2 stack:
There are two approaches I'm experimenting with to packaging modules for python
(a) create an separate specfile/srpm for the python 3 version
(b) extend an existing specfile so that it emits a python3- subpackage as
part of the build.
I've done some work towards getting dbus-python working with Python 3.
I've written semantic patches using Coccinelle that do some of the grunt work of the port; one of them can be seen here:
Do you know if upstream is looking at python3 at all?
Would you be willing to carry a patch to dbus-python.spec that builds both dbus-python and python3-dbus subpackages from one build, or does it make more sense to have a totally separate specfile?
Adding johnp to CC: John, we talked about this face-to-face today and I had assumed this was assigned to you, rather than to davidz; could you please comment on this bug. Thanks!
For more information, including an autogenerated patch for dbus-python see:
Get Python3 into rawhide and I will play with it to see what happens. I haven't seen any movement upstream. I'm not sure how much time Simon has to work on it, if any.
As for the spec file I am guessing one spec file will be fine via conditionals. It would make it easier to maintain and I am guessing it will only be a few extra lines such as sending in a flag to the compiler.
> Get Python3 into rawhide and I will play with it to see what happens.
Done: see: http://lists.fedoraproject.org/pipermail/devel/2010-January/129185.html
The SRPM is recompiled on F-12 as well, if that helps.
s/ recompiled / recompilable /
Got pretty far today. Majority of fixes are of the PyString_* verity. Fixed the macros issue by hand for now. Got it to compile but the compiler missed a bunch of PyString_ issues (or really I'm not compiling with break on warnings). Fixing that up now. It is evident that I need to go over the code once more and figure out what really needs to be a PyUnicode and what needs to be a PyType. As of now I am doing a lot of inefficient conversions but as I read through the code I am getting a better sense of how Simon has it structured.
One issue is the use of the TP flag Py_TPFLAGS_HAVE_WEAKREFS which is not in Py3k when creating new PyObjects in C. I just removed it for now. Even reading the documentation I am not sure how this effects the module.
Do you have a patch visible somewhere?
FWIW I've updated 2to3c somewhat , but I think that the old version of that patch probably already contains all that's automatable, and that the remaining work will require involve a human expert going through it, figuring out what should be a PyBytesObject and what should be a PyUnicodeObject, as you're doing.
Created attachment 388579 [details]
Patch to make dbus-python compile and work in python 3
It works in the brief testing I did. I now need to go back over and reevaluate the Unicode vs. Bytes decisions I made. The Unicode code needs to convert to UTF8 whenever sending over the wire. Right now it uses the user's local which is wrong.
I also need to ifdef the code so it compiles and works in both Python 2 and 3.
Also, I couldn't build via RPM. When installing the files RPM runs code to bytecompile the scripts. Because of the change to print becoming a function instead of a statement I get this error:
SyntaxError: invalid syntax
/usr/bin/install -c -m 644 dbus_bindings.py '/home/quinticent/rpmbuild/BUILDROOT/dbus-python-0.83.0-7.fc13.i386/usr/lib/python3.1/site-packages/.'
File "<string>", line 6
print 'Byte-compiling python modules...'
That needs to be changed to print('Byte-compiling python modules...') and should be pushed to F11 and greater unless this is fixed in newer versions of the distro and we don't care about people tinkering with Python 3 on F11. (I don't really care either way, I just can't upgrade right now on this machine).
Created attachment 388671 [details]
Patch to make the module compile in Python 3 as well as 2.6
New patch fixes up some problem areas and also works under Python 2.6. Not sure if it will work with Python < 2.6 but do we care?
Moved patch work upstream
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.
More information and reason for this action is here:
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
closeing this. python 3 requires using gdbus through introspection. python dbus will not be ported to python 3
dbus-python was ported to Python3 in 1.0.0 and the python3-dbus subpkg was created in dbus-python-1.1.1-3 on Fedora 18+