https://bugzilla.redhat.com/show_bug.cgi?id=1292209 --- Comment #8 from Paul Belanger <pabelanger@xxxxxxxxxx> --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > (In reply to Paul Belanger from comment #6) > > Had a chance to run fedora-review on your spec. > Thanks! > > > In general good, but it > > founds some issues below. The biggest seems to be related to licensing, a > > lot of files were missing that. I'm not an expert on LICENCE issue so it > > would be good to get another person to comment on my review. > > > > Package Review > > ============== > > > > Legend: > > [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated > > [ ] = Manual review needed > Usually you'd fill all boxes in (one way or another), and then remove this > line. > > > [!]: License field in the package spec file matches the actual license. > > Note: Checking patched sources after %prep for licenses. Licenses > > found: "*No copyright* GPL (v3 or later)", "GPL (v3 or later)", > > "Unknown or generated". 117 files have unknown license. Detailed > > output of licensecheck in /tmp/1292244/review-python- > > nsdf/licensecheck.txt > The license is specified as GPLv3+ in the spec file, and those > headers that specify the license match that. > It is quite normal for many individual files not to have licensing > information or copyright statements, and this is not treated as an error. > The main guidelines [1,2] don't address this case specifically, but in the > FAQ > there are similar considerations (see point 3 in > https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/ > FAQ#How_do_I_figure_out_what_version_of_the_GPL.2FLGPL_my_package_is_under. > 3F) > It seems common sense to assume that if the README or setup.py or some > headers specify > a license, and there is no disagreement between them, that this is the > license. > > [1] https://fedoraproject.org/wiki/Licensing:Main > [2] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines > > > [!]: License file installed when any subpackage combination is installed. > > devel and tools are missing the LICENSE > Different package? This one only has python2-nsdf and python-nsdf-doc > subpackages, > and both have the README, although they don't have a LICENSE file, because > on is missing from the upstream repo and tarball. > > You could (and should) say instead, that I'm supposed to contact upstream > about > adding a license file. Indeed, I haven't done this. > Right, I had noticed the LICENSE was not installed in the files sections. I should have been more detailed about notifying you about that. > > [ ]: Package contains no bundled libraries without FPC exception. > > [x]: Changelog in prescribed format. > > [ ]: Sources contain only permissible code or content. > > [-]: Package contains desktop file if it is a GUI application. > > [x]: Development files must be in a -devel package > > [x]: Package uses nothing in %doc for runtime. > > [!]: Package consistently uses macros (instead of hard-coded directory > > names). > Can you be more specific here? > Doh, I missed my comment at the top. For this, I was looking at other reviews an noticed the nsdf name seemed copied over the entire spec file, vs setting up a macro for %{pypi_name} or %{srcname}. > > [ ]: Package is named according to the Package Naming Guidelines. > > [x]: Package does not generate any conflict. > > [ ]: Package obeys FHS, except libexecdir and /usr/target. > > [-]: If the package is a rename of another package, proper Obsoletes and > > Provides are present. > > [-]: Requires correct, justified where necessary. > > [x]: Spec file is legible and written in American English. > > [-]: Package contains systemd file(s) if in need. > > [ ]: Package is not known to require an ExcludeArch tag. > > [x]: Large documentation must go in a -doc subpackage. Large could be size > > (~1MB) or number of files. > > Note: Documentation size is 10240 bytes in 1 files. > > [ ]: Package complies to the Packaging Guidelines > > [x]: Package successfully compiles and builds into binary rpms on at least > > one supported primary architecture. > > [x]: Package installs properly. > > [x]: Rpmlint is run on all rpms the build produces. > > Note: No rpmlint messages. > > [x]: Package requires other packages for directories it uses. > > [x]: Package must own all directories that it creates. > > [x]: Package does not own files or directories owned by other packages. > > [x]: All build dependencies are listed in BuildRequires, except for any > > that are listed in the exceptions section of Packaging Guidelines. > > [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT > > [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the > > beginning of %install. > > [x]: Macros in Summary, %description expandable at SRPM build time. > > [x]: Dist tag is present. > > [x]: Package does not contain duplicates in %files. > > [x]: Permissions on files are set properly. > > [x]: Package use %makeinstall only when make install DESTDIR=... doesn't > > work. > > [x]: Package is named using only allowed ASCII characters. > > [x]: Package does not use a name that already exists. > > [x]: Package is not relocatable. > > [x]: Sources used to build the package match the upstream source, as > > provided in the spec URL. > > [x]: Spec file name must match the spec package %{name}, in the format > > %{name}.spec. > > [x]: File names are valid UTF-8. > > [x]: Packages must not store files under /srv, /opt or /usr/local > > > > Python: > > [x]: Python eggs must not download any dependencies during the build > > process. > > [ ]: A package which is used by another package via an egg interface should > > provide egg info. > > [ ]: Package meets the Packaging Guidelines::Python > > [x]: Package contains BR: python2-devel or python3-devel > > [x]: Binary eggs must be removed in %prep > > > > ===== SHOULD items ===== > > > > Generic: > > [!]: Uses parallel make %{?_smp_mflags} macro. > It uses the standard %py2_build macro. If this is not paralellized, and > could be, than this might be a bug in python2-devel. > > In this case "build" is really copying a few files to build/lib, so it > doesn't > really matter either way. > This left by fedora-review. Since this was one of the first reviews I did, I really depended on the automated tool to catch a lot of stuff. > > [ ]: If the source package does not include license text(s) as a separate > > file from upstream, the packager SHOULD query upstream to include it. > > [ ]: Final provides and requires are sane (see attachments). > > [ ]: Fully versioned dependency in subpackages if applicable. > > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in > > python2-nsdf , python-nsdf-doc > > [ ]: Package functions as described. > > [ ]: Latest version is packaged. > > [ ]: Package does not include license text files separate from upstream. > > [ ]: Patches link to upstream bugs/comments/lists or are otherwise > > justified. > > [ ]: Description and summary sections in the package spec file contains > > translations for supported Non-English languages, if available. > > [ ]: Package should compile and build into binary rpms on all supported > > architectures. > > [ ]: %check is present and all tests pass. > > [ ]: Packages should try to preserve timestamps of original installed > > files. > > [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file > > [x]: Sources can be downloaded from URI in Source: tag > > [x]: Reviewer should test that the package builds in mock. > > [x]: Buildroot is not present > > [x]: Package has no %clean section with rm -rf %{buildroot} (or > > $RPM_BUILD_ROOT) > > [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. > > [x]: SourceX is a working URL. > > [x]: Spec use %global instead of %define unless justified. > > > > ===== EXTRA items ===== > > > > Generic: > > [x]: Rpmlint is run on all installed packages. > > Note: No rpmlint messages. > > [x]: Spec file according to URL is the same as in SRPM. > > What about all the open boxes [ ]? Thanks for the feedback, I admit I should have likely removed the open boxes lines. I wasn't comfortable filling some of them in. Moving forward, I'll do my best to leave more detail, then less for reviews. -- 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 https://admin.fedoraproject.org/mailman/listinfo/package-review