Bug 579567 - Add python 3 subpackage to python-docutils
Add python 3 subpackage to python-docutils
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: python-docutils (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Toshio Ernie Kuratomi
Fedora Extras Quality Assurance
:
Depends On:
Blocks: Python3F13
  Show dependency treegraph
 
Reported: 2010-04-05 16:57 EDT by Dave Malcolm
Modified: 2011-05-24 23:07 EDT (History)
1 user (show)

See Also:
Fixed In Version: python-docutils-0.8-0.1.20110517svn7036.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-24 23:07:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to add python3 subpackage (4.91 KB, patch)
2010-04-05 16:57 EDT, Dave Malcolm
no flags Details | Diff
koji build.log with next set of errors -- Elementtree changes (72 bytes, text/plain)
2011-04-04 13:05 EDT, Toshio Ernie Kuratomi
no flags Details

  None (edit)
Description Dave Malcolm 2010-04-05 16:57:58 EDT
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'
Comment 1 Toshio Ernie Kuratomi 2010-04-05 19:33:22 EDT
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.
Comment 2 Dave Malcolm 2010-04-06 12:31:30 EDT
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.
Comment 3 Dave Malcolm 2010-04-06 12:36:19 EDT
> 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).
Comment 4 Toshio Ernie Kuratomi 2010-04-06 14:52:44 EDT
* 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.
Comment 5 Toshio Ernie Kuratomi 2010-12-01 00:13:27 EST
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.
Comment 6 Toshio Ernie Kuratomi 2010-12-31 00:28:56 EST
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
Comment 7 Dave Malcolm 2011-01-03 19:29:28 EST
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
Comment 8 Toshio Ernie Kuratomi 2011-01-03 20:32:35 EST
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
Comment 9 Toshio Ernie Kuratomi 2011-04-04 13:04:22 EDT
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.
Comment 10 Toshio Ernie Kuratomi 2011-04-04 13:05:14 EDT
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.
Comment 11 Toshio Ernie Kuratomi 2011-04-28 11:52:22 EDT
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).
Comment 12 Toshio Ernie Kuratomi 2011-05-16 19:00:24 EDT
https://koji.fedoraproject.org/koji/taskinfo?taskID=3075765
Comment 13 Fedora Update System 2011-05-18 17:32:43 EDT
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
Comment 14 Fedora Update System 2011-05-19 17:59:08 EDT
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).
Comment 15 Fedora Update System 2011-05-24 23:05:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.