https://bugzilla.redhat.com/show_bug.cgi?id=1441843 --- Comment #33 from greg.hellings@xxxxxxxxx --- > The issues that still need to be resolved: > > [!]: License field in the package spec file matches the actual license. > License should be GPLv3+ and BSD I'm not sure why you're flagging it as needing BSD license. I don't see any reference to the BSD license in the code, am I missing it somewhere? > > [!]: Requires correct, justified where necessary. > The comment below indicates that these requirements might belong to > the linchpin-doc subpackage? If so, they need to be listed as > requirements for the subpackage, not the primary package > # Extra sub-package includes > Requires: beaker-client > Requires: python3-libvirt > Requires: python3-lxml > The Requires listed are from the optional extras python packages. In pip these would be installed with `pip install linhcpin[beaker]` or `pip install linchpin[libvirt]`. They could be listed as "Recommends" or such, but the product would be completely non-functional without them so I opted to add them directly. > > [!]: Avoid bundling fonts in non-fonts packages. > Note: linchpin-doc contains font files. If it's possible to add them > as dependencies instead, we really should The docs are intended to be opened from a browser and/or served from a static website pointing to the root of the docs folder. I don't know how easily those files can be made to depend on each other. It might require me to post-process the HTML to point it at the files in the python3-sphinx_rtd_theme package (which is the Sphix theme used to build these docs). I'll give that some thought and experimentation. > > [!]: If you build a python module you should use the %python_provide macro > I'm not completely clear if this is meant to be imported by other > programs, but, if so, we should be using %python_provide We are not building a Python module that is intended to be importable by another Python package. This is really just providing the executable in a Python wrapper is that all of its dependencies can easily be managed. I can still add the python provides if it should be there.(In reply to Jonathan Dieter from comment #32) > > [!]: Package functions as described. > When I run linchpin, the following happens: > $ linchpin > Traceback (most recent call last): > File "/usr/bin/linchpin", line 11, in <module> > load_entry_point('linchpin==1.6.4', 'console_scripts', > 'linchpin')() > File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", > line 484, in load_entry_point > return get_distribution(dist).load_entry_point(group, name) > File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", > line 2714, in load_entry_point > return ep.load() > File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", > line 2332, in load > return self.resolve() > File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", > line 2338, in resolve > module = __import__(self.module_name, fromlist=['__name__'], > level=0) > File "/usr/lib/python3.7/site-packages/linchpin/shell/__init__.py", > line 12, in <module> > from linchpin.cli import LinchpinCli > File "/usr/lib/python3.7/site-packages/linchpin/cli/__init__.py", > line 16, in <module> > from linchpin.fetch import FETCH_CLASS > File "/usr/lib/python3.7/site-packages/linchpin/fetch/__init__.py", > line 1, in <module> > from fetch_local import FetchLocal > ModuleNotFoundError: No module named 'fetch_local' Well that's disturbing. The upstream package seems to suffer from the same issue when installed directly with pip to a virtualenv, and the problem persists in the latest bugfix. I've reported this upstream as https://github.com/CentOS-PaaS-SIG/linchpin/issues/853 and am looking into a fix. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
