Created attachment 404570 [details] Patch to add python3 subpackage I'm attaching a patch to python-docutils.spec (F-13 and devel) which adds a python3-docutils subpackage to the build. I've tried to follow https://fedoraproject.org/wiki/Packaging:Python The logic in %install is complex, so I introduce a function to managed doing it twice (or only once if with_python3 is turned off). I chose to install "python3-" versions of the various executables, which makes it fairly easy to test.. However, on testing these I run into issues: [david@f13 F-13]$ python3-rst2html --traceback docutils-0.6/docs/dev/rst/alternatives.txt foo.html Traceback (most recent call last): File "/usr/bin/python3-rst2html", line 23, in <module> publish_cmdline(writer_name='html', description=description) File "/usr/lib/python3.1/site-packages/docutils/core.py", line 336, in publish_cmdline config_section=config_section, enable_exit_status=enable_exit_status) File "/usr/lib/python3.1/site-packages/docutils/core.py", line 203, in publish self.settings) File "/usr/lib/python3.1/site-packages/docutils/readers/__init__.py", line 69, in read self.parse() File "/usr/lib/python3.1/site-packages/docutils/readers/__init__.py", line 74, in parse self.document = document = self.new_document() File "/usr/lib/python3.1/site-packages/docutils/readers/__init__.py", line 80, in new_document document = utils.new_document(self.source.source_path, self.settings) File "/usr/lib/python3.1/site-packages/docutils/utils.py", line 424, in new_document source_path = decode_path(source_path) File "/usr/lib/python3.1/site-packages/docutils/utils.py", line 340, in decode_path path = path.decode(sys.getfilesystemencoding(), 'strict') AttributeError: 'str' object has no attribute 'decode'
Okay -- seems like something that we need to fix before pushing this into the package. It seems like 2to3 is getting confused about whether it needs to be dealing with bytes or strings there. If path is coming from the filesystem, the code probably needs to be adapted to import path as a byte string earlier. If the path is going out to the filesystem, then we need to change that .decode() to a .encode(). I'm a bit handwavey on using shell functions within a spec file. The spec isn't very difficult to read either way so I lean a bit towards simplicity.
Running under pdb: [david@f13 docutils-0.6]$ python3 -m pdb tools/rst2html.py --traceback docs/dev/rst/alternatives.txt foo.html (Pdb) up > /usr/lib/python3.1/site-packages/docutils/utils.py(424)new_document() -> source_path = decode_path(source_path) (Pdb) list 419 Runtime settings. If none provided, a default set will be used. 420 """ 421 from docutils import frontend 422 if settings is None: 423 settings = frontend.OptionParser().get_default_values() 424 -> source_path = decode_path(source_path) 425 reporter = new_reporter(source_path, settings) 426 document = nodes.document(settings, reporter, source=source_path) 427 document.note_source(source_path, -1) 428 return document 429 (Pdb) p source_path 'docs/dev/rst/alternatives.txt' so it's getting the path as unicode, but expecting it as bytes This seems to be http://permalink.gmane.org/gmane.text.docutils.devel/4981 and a followup here http://permalink.gmane.org/gmane.text.docutils.devel/5058 reports it as fixed in SVN. There have been a number of recent py3k fixes in upstream SVN: http://svn.berlios.de/viewcvs/docutils?view=rev&revision=6266 http://svn.berlios.de/viewcvs/docutils?view=rev&revision=6267 http://svn.berlios.de/viewcvs/docutils?view=rev&revision=6269 http://svn.berlios.de/viewcvs/docutils?view=rev&revision=6270 http://svn.berlios.de/viewcvs/docutils?view=rev&revision=6271 but AFAIK upstream haven't released a tarball containing these changes yet.
> I'm a bit handwavey on using shell functions within > a spec file. The spec isn't very difficult to read either way so I lean a bit > towards simplicity. It's not clear to me which option you mean by "lean a bit towards simplicity" :) I tried writing it as a loop at first, but upon introducing a shell function the code got a lot simpler, especially when considering the possibility that you might want to turn off the "with_python3". Shell conditionals have surprising (to me) semantics, and have bitten me in the past. So I have a preference for the shell function. (a third option would be to use a specfile macro, but I think that's definitely a more obscure syntax).
* If it's in upstream's svn we can rebase onto the snapshot tarballs. * Just do it explicitly twice. We're only going to make two packages. It's not until you have to repeat yourself three times that it becomes a clear readability win to abstract. * We need to check what happens to documentation that has images in it without python-imaging installed. If it generates documentation without the images I think we need to document in a few places that limitation.
Update on this since I did some work on it before the Thanksgiving break -- there's one docutils module that's not python3-ready as it depends on the python2 ast module. mako has a similar module and they had to basically implement a python2 and python3 version.
dmalcolm: When you get back from vacation -- I know you care about this and python3-nose as part of a good python3 development stack. But we have a problem -- both of these packages now build on F14 or less but they don't build on f15 right now. Here's the failed build for this one to look at: http://koji.fedoraproject.org/koji/taskinfo?taskID=2694663
For reference, Toshio filed the bugs upstream as follows: docutils failure: http://sourceforge.net/tracker/?func=detail&aid=3149845&group_id=38414&atid=422030 nose failure: http://code.google.com/p/python-nose/issues/detail?id=389
Also btw, I've built this into f13 and f14. I'd like to wait until rawhide is building again to close this but we're close to finishing this one off. F13 and F14 updates are: https://admin.fedoraproject.org/updates/python-docutils-0.7-3.fc14 https://admin.fedoraproject.org/updates/python-docutils-0.7-3.fc13
Currently in git master, I've applied an icky patch that ports from using ConfigParser to using RawConfigParser. I've sent it upstream but it isn't the right fix. The right fix is porting docutils to only store string values in the ConfigParser() object. This brings us to another error though. I'll attach the build.log here.
Created attachment 489814 [details] koji build.log with next set of errors -- Elementtree changes Elementtree seems to have changed and that's causing another set of build errors.
Hey Dave, did you make any progress with this while I was on vacation? It's going to end up causing problems with F15 really soon now :-( (There's no current docutils package built for F15 yet).
https://koji.fedoraproject.org/koji/taskinfo?taskID=3075765
python-docutils-0.8-0.1.20110517svn7036.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/python-docutils-0.8-0.1.20110517svn7036.fc15
Package python-docutils-0.8-0.1.20110517svn7036.fc15: * should fix your issue, * was pushed to the Fedora 15 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.8-0.1.20110517svn7036.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/python-docutils-0.8-0.1.20110517svn7036.fc15 then log in and leave karma (feedback).
python-docutils-0.8-0.1.20110517svn7036.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.