Mercurial fails to build with python-docutils-0.10-0.2.20120730svn7490.fc18.noarch : make -C doc make[1]: Entering directory `/home/dev/rpmbuild/BUILD/mercurial-2.2.3/doc' python runrst hgmanpage --halt warning \ --strip-elements-with-class htmlonly hgrc.5.txt hgrc.5 Traceback (most recent call last): File "runrst", line 50, in <module> publish_cmdline(writer_name=writer) File "/usr/lib/python2.7/site-packages/docutils/core.py", line 349, in publish_cmdline pub.set_components(reader_name, parser_name, writer_name) File "/usr/lib/python2.7/site-packages/docutils/core.py", line 99, in set_components self.set_writer(writer_name) File "/usr/lib/python2.7/site-packages/docutils/core.py", line 88, in set_writer writer_class = writers.get_writer_class(writer_name) File "/usr/lib/python2.7/site-packages/docutils/writers/__init__.py", line 136, in get_writer_class module = __import__(writer_name, globals(), locals(), level=1) ImportError: No module named hgmanpage It builds without problems when downgrading to python-docutils-0.8.1-3.fc17.noarch .
First look seems like a change in behaviour in docutils that would need a change in mercurial. the hgmanpage module is located in mercurial's doc directory. I bet that docutils used to somehow pick up on its presence there but now we need to set the PYTHONPATH or something to find it.
I notice that the master branch in git has mercurial-2.3. Is it fine to look at that one? (The issue is still occurring there and if I fix it there it'll be generalizable back to 2.2.3?)
(In reply to comment #1) > I bet that docutils used to somehow pick up on its presence > there but now we need to set the PYTHONPATH or something to find it. Hacking docutils so prints sys.path before the import shows that the doc folder is in the import path. An explicit 'import hgmanpage' works. __import__ with level=-1 also works (for this import but fails for other imports). (In reply to comment #2) I don't think anything relevant changed in Mercurial, but testing with the version that worked in f17 takes one variable out of the equation. I would expect that the docutils library was stable and didn't require changes in the code that use docutils. Using an unreleased svn snapshot will of course increase the risk of introducing a regression ... but also make it possible to fix it before the real release.
Here's the change in docutils that's causing this: http://docutils.svn.sourceforge.net/viewvc/docutils/trunk/docutils/docutils/writers/__init__.py?r1=7317&r2=7486 and the referenced bug report: https://sourceforge.net/tracker/?func=detail&aid=3541369&group_id=38414&atid=422030 Unfortunately, docutils doesn't guarantee a stable API between releases. I'm going to open this issue on the upstream bug tracker to see if it's intended behaviour or if they'd be willing to work out a different fix but I think this might be an intended change in behaviour as it brings the python2 and python3 behaviour in line with each other.
Note that Fedora 18 is going to ship with python3-3.3 so we'll have to pick up some change along these lines from upstream to support that python3 version.
I thought the idea of py3 was to introduce non-backward compatible changes that couldn't be introduced in py2. If level=1 is needed for py3.3 then it should be used where it is necessary or do no harm. But to introduce a py2 regression when making it py3.3 compatible seems strange.
That's up to each individual upstream that's porting their library to python3. python3 itself allowed the python upstream to introduce a large number of incompatible changes but that doesn't affect what individual libraries built on top of python do. Testing the code a bit more, this isn't just a behaviour change, though. The new code doesn't seem to have any way to load user-created writers (and probably readers and other things as well). Fortunately, there's a simple fix for this if that is the case.
https://sourceforge.net/tracker/?func=detail&aid=3559988&group_id=38414&atid=422030 We're also waiting on dmalcolm or upstream to port this package to python3.3 before it will pass its own ftbfs. I'll check with him to see if he has an update on that.
python-docutils-0.10-0.5.20120824svn7502.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/python-docutils-0.10-0.5.20120824svn7502.fc18
This should fix it for you. On Rawhide, you should just be able to build. On F18 you'll need to create a buildroot override in bodhi until the update goes to stable. I'll probably make another package update later today because there's other places in the docutils code besides writers() that's affected by this change to __import__(). It shouldn't affect you unless you're also using a custom reader, parser, directives, or languages modules, though. Let me know if there's any difficulties.
Package python-docutils-0.10-0.5.20120824svn7502.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-docutils-0.10-0.5.20120824svn7502.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12655/python-docutils-0.10-0.5.20120824svn7502.fc18 then log in and leave karma (feedback).
python-docutils-0.10-0.6.20120824svn7502.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/python-docutils-0.10-0.6.20120824svn7502.fc18
python-docutils-0.10-0.6.20120824svn7502.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.