https://bugzilla.redhat.com/show_bug.cgi?id=1256100 --- Comment #7 from Jerry James <loganjerry@xxxxxxxxx> --- (In reply to gil cattaneo from comment #4) > [!]: License field in the package spec file matches the actual license. > Note: Checking patched sources after %prep for licenses. Licenses > found: "LGPL", "GPL (v3 or later)", "Unknown or generated", "MIT/X11 > (BSD like)", "BSD (2 clause)", "GPL (v2)", "*No copyright* MIT/X11 > (BSD like)". 44 files have unknown license. Detailed output of > licensecheck in /home/gil/1256100-cryptominisat4/licensecheck.txt https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License:_field says that the license field applies to the binary RPM, so some of these licenses don't matter, as they are files that do not contribute to the contents of the binary RPM. The MIT python test file, and the GPL scripts are not packaged in any of the binary RPMs, so their licenses don't matter. The files that are compiled into the binary RPMs have the following licenses: BSD (2 clause), LGPL v2, and MIT/X11 (BSD like). In that case, the effective license (see https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F) is LGPLv2, since its terms are stricter than BSD and MIT. So the License field is still wrong. I'm not sure where I got LGPLv3+ from. The license should be LGPLv2. Fixed. > [!]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: /usr/lib/cmake(cmake, > qt5-qtlocation, qt5-qtbase) > > Please, use: %{_libdir}/cmake/cryptominisat4 No, the spec file is correct. %{_libdir}/cmake is owned by the cmake package, which is not required by cryptominisat4-devel. If I made this change, then somebody who does not have cmake installed and does not have %{_libdir}/cmake present on her system could install cryptominisat4-devel, then remove it, and now has an empty, unowned %{_libdir}/cmake directory on her system. This case is covered here: https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function (In reply to gil cattaneo from comment #5) > Suggestion: > cryptominisat4.src:87: E: hardcoded-library-path in > %{_prefix}/lib/lib%{name}* > cryptominisat4.src:88: E: hardcoded-library-path in %{_prefix}/lib/cmake > cryptominisat4.src:89: E: hardcoded-library-path in > %{_prefix}/lib/|%{_libdir}/|' > can you patch cmake file, chaging the hardcoded ${dir}/lib with > ${LIB_INSTALL_DIR} > e.g. %{__cmake} -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} > -DLIB_INSTALL_DIR:PATH=%{_libdir} -DALSO_BUILD_STATIC_LIB=OFF . No, it's not so simple, I'm afraid. Following that path has, so far, led me to make these changes, but they aren't enough. The build is still failing: # Fix installation on systems with lib64 if [ "%{_libdir}" = "%{_prefix}/lib64" ]; then sed -e 's,${CMAKE_CURRENT_BINARY_DIR}/lib,&64,' \ -e 's,DEF_INSTALL_CMAKE_DIR lib,&64,' \ -i CMakeLists.txt sed -i 's,${dir}/lib,${LIB_INSTALL_DIR},g' cmake/FindPkgMacros.cmake sed -i 's,${CMAKE_INSTALL_PREFIX}/lib,&64,' src/CMakeLists.txt sed -i 's,'${PROJECT_BINARY_DIR}/lib',&64,' python/setup.py.in sed -i 's,--rpath ../lib,&64,' python/CMakeLists.txt fi Can we stick with the scheme I already have working? This approach looks to be at least as complicated and more fragile. (In reply to gil cattaneo from comment #6) > make install DESTDIR=%{buildroot} I have made this change. New URLs: Spec URL: https://jjames.fedorapeople.org/cryptominisat4/cryptominisat4.spec SRPM URL: https://jjames.fedorapeople.org/cryptominisat4/cryptominisat4-4.5.3-2.fc24.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