Created attachment 295199 [details] feedparser-5.1.ebuild BUMP! This is an adaption of Arfrever's work in his overlay, so a big up to him! Other fixes are mainly related to tests. See src_prepare for moar info (and upstream bugs). Additionally, use the built python path over pwd when running tests. Finally, I've seen sporadic freezes when the test suite completes (the http server still persists). Haven't been able to track this down yet, but I recall not seeing the same issue in latest svn. Please test!
Created attachment 295201 [details, diff] feedparser-5.1-sgmllib.patch
Created attachment 295215 [details] feedparser-5.1.ebuild OK, new take. postinst/postrm was just broken (hat tip arfrever), src_install is redundant (hat tip arfrever) and added die's where needed.
ok; this gentoo64 feedparser # emerge =dev-python/feedparser-5.1 yields >>> Emerging (1 of 1) dev-python/feedparser-5.1 >>> Jobs: 0 of 1 complete, 1 running Load avg: 1.50, 1.42, 1.30r >>> Installing (1 of 1) dev-python/feedparser-5.1 success. It's almost the same as emerge =dev-python/feedparser-5.1::progress. It requires the ebuild in comment 2 and the patch from comment 1 by Johan. Curiously gentoo64 feedparser # ebuild feedparser-5.1.ebuild clean test draws error, but it's not the full 'monty' anyway. emerge as above is. The kicker; here's the hard part. gentoo64 feedparser # mv ../../eclass/python.eclass ../../eclass/python.eclass-mv gentoo64 feedparser # ln -s /var/lib/layman/progress/eclass/python.eclass ../../eclass/ gentoo64 feedparser # ls -ld ../../eclass/python.eclass lrwxrwxrwx 1 root root 45 Dec 9 17:20 ../../eclass/python.eclass -> /var/lib/layman/progress/eclass/python.eclass Without this, it fails, big time. The python eclass again, and the mere mention of the history behind that makes any python dev 'blink', or is it squirm. This holds the whole version bump to ransom
I'm not sure i fully understood what you said, but the ebuild should work fine without the python eclass from progress. On the other hand, checking for PYTHON_ABI from postinst/postrm _does not_. I am yet to find a better solution. Anyone?
currently the choice of either python eclass doesn't effect a pass of test phase. I can't figure what is different in my system to cause this setup to not pass the test phase, but I persistently get ERROR: test_unicode_2 (__main__.TestOpenResource) Traceback (most recent call last): File "feedparsertest.py", line 289, in test_unicode_2 r = feedparser._open_resource(s, '', '', '', '', [], {}) File "../build/lib/feedparser.py", line 2940, in _open_resource return open(url_file_stream_or_string, 'rb') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 20: ordinal not in range(128)
Created attachment 295399 [details, diff] ebuild -5.1(-r1) patch and files/feedparser-test.patch combo here is a more detailed description File "feedparsertest.py", line 289, in test_unicode_2 ------------------------------------------------------ return open(url_file_stream_or_string, 'rb') UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 20: ordinal not in range(128) Here is the test def def test_unicode_2(self): s = u'<feed><item><title>t\u00e9xt</title></item></feed>' r = feedparser._open_resource(s, '', '', '', '', [], {}) self.assertEqual(s.encode('utf-8'), r.read()) s is u'<feed><item><title>t\u00e9xt</title></item></feed>' put this into a bpython or python >>> s = u'<feed><item><title>t\u00e9xt</title></item></feed>' >>> s u'<feed><item><title>t\xe9xt</title></item></feed>' >>> print(s) Traceback (most recent call last): File "<input>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/bpython/cli.py", line 1133, in write t = t.encode(getpreferredencoding()) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 20: ordinal not in range(128) The test is invalid. It give it data that can't be handles by a python interpreter. It has to go. Note it is test_unicode_2, there is already a test_unicode_1. Note the ebuild patch does not obsolete the previous, but is a patch to the previous patch, simply adding 1 line of epatch the new files/feedparser-test.patch
cancel most of that. Turns out it is valid My locale that's been set for months was in a state that confused python. Resetting it to one it liked saw the build become effective. His patch is good to go
I will submit a new ebuild as soon as the next version of feedparser is out.
Created attachment 297557 [details, diff] feedparser-5.1-sgmllib.patch alternative It seems that the error from 2to3 is not critical. I would like to propose the attached patch for a more minimalistic alternative. Does anyone know how to fix the test suite, at least for Python 2.x?
(In reply to comment #9) > Created attachment 297557 [details, diff] [details, diff] > feedparser-5.1-sgmllib.patch alternative > > It seems that the error from 2to3 is not critical. > I would like to propose the attached patch for a more minimalistic alternative. > > Does anyone know how to fix the test suite, at least for Python 2.x? Yep. I've submitted multiple patches upstream. I would suggest waiting for the next release, but if we're in a hurry my patches are available in the upstream repo.
I went ahead with this since net-misc/flexget insists on using >= 5.1. I did not include any of Johan's patches; you can ping me in IRC if you want me to add them. +*feedparser-5.1 (03 Jan 2012) + + 03 Jan 2012; Mike Gilbert <floppym@gentoo.org> +feedparser-5.1.ebuild, + +files/feedparser-5.1-sgmllib.patch: + Version bump for bug 393639. Thanks to Johan Bergström and Arfrever. Includes + patch by sping. Fails tests. +
