https://bugzilla.redhat.com/show_bug.cgi?id=1290922 --- Comment #14 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to Antonio Trande from comment #13) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > > (In reply to Antonio Trande from comment #8) > > > > > > [!]: If (and only if) the source package includes the text of the > > > license(s) in its own file, then that file, containing the text of the > > > license(s) for the package is included in %license. > > > > > > --> See above. > > The way I understand this point, if the license is missing, it is not > > supposed > > to be included from other sources. > > Any license file must be tagged with '%license' macro. In this package there > is not any license file but i think you can add a GPLv3 text file as long as > upstream includes an own one. "If the source package does not include the text of the license(s), the packager should contact upstream and encourage them to correct this mistake. [...] It is important to reiterate that in situations where the indicated license does not imply a requirement that the license be distributed along with the source/binaries, Fedora packagers are NOT required to manually include the full license text when it is absent from the source code. but are still encouraged to point out this issue to upstream and encourage them to remedy it." I submitted a pull request with the license text. Once upstream either merges it or resolves this in some other way, I'll include the license in the package. > > > [-]: Package requires other packages for directories it uses. > > > [-]: Package does not own files or directories owned by other packages. > > > [!]: All build dependencies are listed in BuildRequires, except for any > > > that are listed in the exceptions section of Packaging Guidelines. > > > > > > --> gcc-c++ make can be removed as BR. > > That's an error in fedora-review. gcc-g++ might be removed from the default > > build root, and this dependency future-proofs against that. > > > > > [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. > > > [-]: Package contains desktop file if it is a GUI application. > > > [-]: Package installs a %{name}.desktop using desktop-file-install or > > > desktop-file-validate if there is such a file. > > > [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 > > > > > > ===== SHOULD items ===== > > > > > > Generic: > > > [x]: Sources can be downloaded from URI in Source: tag > > > [-]: If the source package does not include license text(s) as a separate > > > file from upstream, the packager SHOULD query upstream to include it. > > > [x]: Final provides and requires are sane (see attachments). > > > [x]: Fully versioned dependency in subpackages if applicable. > > > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in freedv- > > > debuginfo > > > [ ]: Package functions as described. > > > [x]: 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. > > > > > > --> Please, leave comments about patches. I forgot to address this comment. Most patches are not really upstreamable, they should be replaced with proper fixes to the build system. I added some comments to the spec file. > > > [-]: SourceX tarball generation or download is documented. > > > [-]: Description and summary sections in the package spec file contains > > > translations for supported Non-English languages, if available. > > > [x]: Package should compile and build into binary rpms on all supported > > > architectures. > > > [-]: %check is present and all tests pass. > > > [x]: Packages should try to preserve timestamps of original installed > > > files. > > > [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file > > > [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]: Uses parallel make %{?_smp_mflags} macro. > > > [x]: SourceX is a working URL. > > > [x]: Spec use %global instead of %define unless justified. > > > > > > ===== EXTRA items ===== > > > > > > $ checksec --file ./moose > > > RELRO STACK CANARY NX PIE RPATH RUNPATH FILE > > > Full Canary found enabled enabled No No RUNPATH ./moose > > > > > > I suggest to control whith 'checksec' in F22 if it's necessary. > > I don't understand: this checksec output looks OK, no? > > 'checksec' output of 'moose' bin file compiled in F24/F23 is good but > hardened builds are not automatically activated on F22, so maybe you will > have need to add compiler/linker flags manually. I added checksec output to the build process. The output is not checked, but it will show up in the logs. It turns out that the python subpackage was incomplete, and it was missing proper Requires. It seems that the rpm dependency generator ignores so files if they are not executable. Should be fixed now. I also added a simple check that imports the module to verify that at least it loads correctly. Spec URL: https://in.waw.pl/~zbyszek/fedora/moose.spec SRPM URL: https://in.waw.pl/~zbyszek/fedora/moose-3.0.2-0.4.fc24.beta.2.src.rpm -- 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