Created attachment 314207 [details, diff] ebuild patch Acquired a different & complete tarball. For python 2.6 2.7 archtester xhtml2pdf # USE=doc ebuild xhtml2pdf-0.0.4.ebuild test or archtester xhtml2pdf # USE=doc ebuild xhtml2pdf-0.0.4.ebuild test yield ---------------------------------------------------------------------------------- TOTAL 34159 32737 12584 115 29.72% ---------------------------------------------------------------------- Ran 35 tests in 0.111s OK python2.5 doesn't work archtester xhtml2pdf # ebuild xhtml2pdf-0.0.4.ebuild merge on python 2.6 or 2.7 install only /usr/lib64/python2.7/site-packages/ seems the setup.py is dictating only python2.7. There are in fact 2 test suites. The second is in a folder testrender. It seems it requires a version of media-gfx/imagemagick already dropped from portage so it's unusable. Only need 1 anyway. If ever this gets bumped, requires test? ( dev-python/cookbook which itself requires a dev-python/bunch. PIL is apparently == imaging. cookbook is a package of various 'recipes', and the test for this testsuite requires a module HTLM2PDF which is such a recipe that needed be added to cookbook. Both are sitting in improvise
Your patch lacks in a few paces: - there's official tarball: http://pypi.python.org/pypi/xhtml2pdf/0.0.4 - deps are versioned despite that there are no earlier versions - html5lib is duplicated (once with >=, the second time with =) - invalid use of src_install, you should read up on p-d-ng.eclass if you want to use it I'll look into it later.
Created attachment 314313 [details, diff] ebuild patch frankly I don't want to use it (the eclass), the prior version comes with it and is empty of any phases to serve as a model. I did unfortunately duplicate html5lib. If you want to stay with the pypy tarball then your call. pypy.org tarballs have a habit of leaving out files and this is a classic example. Then the versioning cited by the alternate tarball becomes invalid anyway, and likely everything else I put in the patch. As for the install, attempting use of python_install instead from reading the eclass doesn't work anyway, resulting in a hang where the 'invalid' src_install actually installed, so that wasn't enough to clarify. I'm sure you can straighten it out anyway, the dev that you are.
Comment on attachment 314313 [details, diff] ebuild patch Marking irrelevant diff fragment obsolete.
Created attachment 314315 [details, diff] ebuild patch ugh, I selected the wrong patch entirely. silly. 2nd time lucky, looks right from here. sorry.
Comment on attachment 314315 [details, diff] ebuild patch >+#python_install() { >+# python-distutils-ng_src_install > /dev/null >+# if use doc; then >+# docinto html >+# dodoc doc/* >+# fi >+# docinto "" && dodoc "README.rst" >+#} Just remove the python-distutil-ng_src_install call here. You're causing the same function to call itself over and over (infinite recursion). Also, rename python_install to python_install_all; this will run just once rather than for each python target.
Created attachment 314319 [details, diff] revised ebuild patch "Just remove the python-distutil-ng_src_install call here. You're causing the same function to call itself over and over (infinite recursion). Also, rename python_install to python_install_all; this will run just once rather than for each python target." ah good, thanks. archtester xhtml2pdf # USE=doc ebuild xhtml2pdf-0.0.4.ebuild clean install * Running python_install_all in /mnt/gen2/TmpDir/portage/dev-python/xhtml2pdf-0.0.4/work/chrisglass-xhtml2pdf-bf1213b/ for all * Installing /mnt/gen2/TmpDir/portage/dev-python/xhtml2pdf-0.0.4/temp/_pisa/pisa for single implementation (python2_7) in /usr/bin * Installing /mnt/gen2/TmpDir/portage/dev-python/xhtml2pdf-0.0.4/temp/_xhtml2pdf/xhtml2pdf for single implementation (python2_7) in /usr/bin yes, perfect. This is clearly my 1st real bump with this eclass.
28 Jun 2012; Patrick Lauer <patrick@gentoo.org> +xhtml2pdf-0.0.4.ebuild:
