https://bugzilla.redhat.com/show_bug.cgi?id=997780 --- Comment #4 from Ralf Corsepius <rc040203@xxxxxxxxxx> --- (In reply to Remi Collet from comment #2) > Kohi scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6061098 > > MUST > > [!]: Package meets the Packaging Guidelines::Python > From recent Guidelines change: > Package don't contains BR: python2-devel or python3-devel > The unversioned macro, %{__python} is deprecated. > use {__python2} %{python2_sitelib} macros to be consistent Well, as you know, I consider this FPC decision to be a non-helpful mistake, exactly because of cases like these. - The python bindings of this package are optional. - The package's python bindings are not tied to any particular version of python. - The package is supposed to be build against the distribution's "default python". => Enforcing to use python2|3 means unnecessarily tying the package against a specific version of python. That said, thanks to the churn this all causes, I am quite strongly leaning towards not packaging the python bindings at all. For now, I have decided to unconditionally switch to python3, because I do not see much sense in adding support for an discontinued version of python in a new package. > Notice, I will prefer the python BR in python sub-package. I don't understand. > [!]: Package is named according to the Package Naming Guidelines. > Version 1.0 is not released, so this is a pre-release > => Release: 0.1.... Well, upstream is quite inconsistent on this. Internally, they consistently use version 1.0. In README.md, they are talking about 0.9. As the Release-tag is not of much importance (and doesn't make any difference to users) I an switching to using Release: 0.x.y > [!]: If the source package does not include license text(s) as a separate > file > from upstream, the packager SHOULD query upstream to include it. > [!]: If (and only if) the source package includes the text of the license(s) > > "Common licenses that require including their texts with all > derivative works include ASL 2.0..." > > => COPYING is now present on github Yes. Wasn't present at the time, I pulled the tarball. > SHOULD > > [!]: Package consistently uses macros (instead of hard-coded directory > names). > => Could use %{name} in URL, python description, ... Done. > COULD > > [!]: Too large wildcard, because I dislike them ;) > %{_libdir}/libgumbo.so.1* > %{python_sitelib}/gumbo* My personal preference differs. (In reply to Remi Collet from comment #3) > Can you please check why _GumboNode.3 instead of GumboNode.3 ? Upstream bug. They fixed it. Updated package with a couple of more issues fixed: Spec URL: http://corsepiu.fedorapeople.org/packages/gumbo-parser.spec SRPM URL: http://corsepiu.fedorapeople.org/packages/gumbo-parser-1.0-0.2.20131001gitd90ea2b.fc21.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review