rst2pdf seems to exist in two versions. The one from the linked website in the ebuild leads to this repository: https://github.com/ralsina/rst2pdf But the main repo seems to be this here: https://github.com/rst2pdf/rst2pdf together with this website: https://rst2pdf.org/ This version supports Python 3, is actively developed and has a bunch of newer releases, than the Gentoo version. Reproducible: Always The Python 2.7 version is actually a problem, since rst2pdf needs dev-python/reportlab, which needs dev-python/pillow and the stable pillow version is Python 3 only, so rst2pdf cannot be installed on a stable system anymore (at least without downgrading something).
I'm working on the ebuild for v0.96 but I'm waiting for some feedback from the upstream devs because I have problems running the test suite.
Sadly, it's not just a simple version bump. You'd need to also package dev-python/smartypants and dev-python/svglib since the dependencies changed (and add dev-python/jinja and dev-python/six; but at least those are readily available.)
Yeah, I've already packaged dev-python/smartypants and I'm testing rst2pdf ebuild without svg support. Going to add dev-python/svglib after I finish my testing.
Created attachment 633644 [details] smartypants-2.0.1.ebuild
Created attachment 633646 [details] svglib-1.0.0.ebuild
Created attachment 633650 [details] rst2pdf-0.96.ebuild
I've attached what I've done so far, it still requires some testing. Notes: * it will be a python3.x only ebuild because dev-python/svglib needs dev-python/tinycss2 which is python3.x only * tests use coverage and the new version use sqlite by default, so python3.x needs to be compiled with sqlite enabled * the test suite is quite problematic, because the tests generate md5 checksums and compare them against a known database. Had a chat with an upstream dev and basically the checksums might be different depending on different dependencies versions. If the result looks correct then it is safe to skip the test. Unfortunately unless we freeze the dependencies versions the list of skipped checksums might change in the future. * there are additional functionalities (wordaxe, aafigure, xhtml2pdf) which depend on libraries not in the Portage yet. I kept the approach of the old ebuild and just mentioning them in logs but ideally they should be added in the system.
For smartypants: - license should be "BSD BSD-2" I figure (the original SmartyPants plugin uses BSD and is explicitly mentioned in the python port's license file, the python port uses a 2-clause BSD license) - PYTHON_COMPAT can be simplified to "python{2_7,3_{6,7,8}}", or, maybe better, to "python2_7 python3_{6,7,8}" to split up python 2 and 3 variants. - I'd use setuptools instead of distutils (i.e., remove DISTUTILS_USE_SETUPTOOLS=no and add a dependency upon dev-python/setuptools[${PYTHON_USEDEP}] or just assume that the eclass will do that automatically, though I'm getting warning messages) - missing top-level dependency on dev-python/unittest2[${PYTHON_USEDEP}] (uses it unconditionally, unfortunately) - tests don't require specific dependencies, so the test USE flag can be removed (I haven't seen any reference to docutils?) - update copyright header to 2020 Everything else looks fine, as far as I can tell. You might be able to update the keywords to something like KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sparc ~x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris", but I have to admit that I don't know if that's policy-conformant or whether arches should add testing keywords at their discretion.
Thanks Mihai, I'll do the changes, some more testing and then I'll create the PR.
(In reply to Mihai Moldovan from comment #8) > Everything else looks fine, as far as I can tell. Err, well, that was meant for smartypants. I still need to review the other packages. :)
For svglib: - copyright - license is LGPL-3 as far as I can tell - drop version from dependencies (the in-tree packages are new enough, no incompatible packages exist) - urgh... modifying tests/test_samples.py via sed and explicit line numbers. The modifications as such look sane, but wouldn't it be better to use a patch for that sort of thing? Several reasons: it will apply fuzzily if the context changes a bit (which is not unlikely), it will apply correctly if the offset changes (which is VERY likely) and lastly, by using a patch, the whole python_test() function will be obsolete and can be removed, so less code, yay! ( - maybe KEYWORDS? I'd need a Gentoo Developer to chime in on this. )
(In reply to Mihai Moldovan from comment #11) > For svglib: Ah, and the usual "python3_{6,7,8}" simplification of course.
For rst2pdf: - unnecessary additional whitespace after media-gfx/inkscape - don't drop the dependency upon dev-python/pillow. Yes, the package will work without it, but be castrated, even if it's not formally a dependency any longer. Check https://github.com/rst2pdf/rst2pdf/compare/0.93...0.96 to that effect. - json is part of the standard distribution since Python 2.6, I don't see any reason to depend upon simplejson? - missing 'dev-python/PyPDF2' dependency in test? Making the optional features sphinx, inkscape and matplotlib USE flags makes sense to me (since, otherwise, disabling tests wouldn't be possible in the first place), but might be seen critical by Gentoo Developers, since Python packages typically do not add proper dependencies upon optional features. The reason is probably proliferation of USE flags. If you add non-standard USE flags, you'd also need to add use.local.desc entries. It's easy to see how the already big file would grow even more if every package did that. I *think* that the standard way is to just add the dependencies unconditionally in the "test?" block and not to disable any optional feature tests. I don't particularly like that, but I also see the benefit of doing so.
(In reply to Mihai Moldovan from comment #11) > For svglib: > [...] > - urgh... modifying tests/test_samples.py via sed and explicit line > numbers. The modifications as such look sane, but wouldn't it be better to > use a patch for that sort of thing? Several reasons: it will apply fuzzily > if the context changes a bit (which is not unlikely), it will apply > correctly if the offset changes (which is VERY likely) and lastly, by using > a patch, the whole python_test() function will be obsolete and can be > removed, so less code, yay! If you do that, don't forget to add "distutils_enable_tests pytest" for the test stuff to work correctly.
We are removing it instead.
Regarding removal: This is a dependency of media-video/mpv[doc]. This is also because I made this bug report.
Sorry, I meant: This is also the reason why I made this bug report.
I guess they'll just remove the doc USE flag and call it a day. I've noticed a trend to remove packages more aggressively during the past few years...
(In reply to gerion from comment #16) > Regarding removal: This is a dependency of media-video/mpv[doc]. This is > also because I made this bug report. I suspected as much. Hence, it seems to make more sense to kill that 'feature' (why would you need fancy PDF when you can read the original rst instead?) instead of wasting our time on tools requiring dead and broken dev-python/pdfrw.
removing.
