https://bugzilla.redhat.com/show_bug.cgi?id=1474033
--- Comment #9 from Andrey Maslennikov <andre...@mellanox.com> --- Spec URL: https://gist.github.com/amaslenn/3c847e0bdc063bcbb4b6507b5efbf6b9/raw/5be459ccf60ee116cc56296f72ecd38560961dee/ucx.spec SRPM URL: https://gist.github.com/amaslenn/3c847e0bdc063bcbb4b6507b5efbf6b9/raw/5be459ccf60ee116cc56296f72ecd38560961dee/ucx-1.2.0-1.fc25.src.rpm Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=21147884 Details: > > %files > > %{_libdir}/lib*.so* > > https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages Unversioned .so moved to -devel. > > %{_datadir}/ucx/perftest/* > > > > https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership > > Extra files are now removed in %install, fixed issue with file pattern. > > Is there anything else to fix here? Please also see below. > > The issue here is that the directories /usr/share/ucx and > /usr/share/ucs/perftest are not included in your packages. That's why I've > linked the directory ownership guidelines. Fixed. > > -devel package now has 'Provides: %{name}-static = %{version}-%{release}'. > > It is as if you deliberately misread > > > https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries > > because even if a "compelling reason" where given as why to include the > static libs, they don't belong into the -devel package, if there are also > shared libs. Static libs moved to separate -static package. -devel depends on it. > > It reports "[!]: Package should not use obsolete m4 macros" complaining > > on AC_PROG_LIBTOOL. Is it critical and has to fixed? > > That's not part of the review guidelines or packaging guidelines. The tool is > trying to be helpful. In case it became necessary to regenerate the configure > script during the build process, such as for a fix, obsolete macros would be > problematic. It's something to fix upstream. Make sure you can autoreconf the > source tarball on a recent installation of Fedora. OK, thanks. autoreconf works on f25. > > Another error it reports is from rpmlint: binary-or-shlib-defines-rpath. > > Is there any other way to correctly specify the path for .so/executable > > files? > > If check-rpaths during an official build complained about it, proceed as > described at: > https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath Couldn't reproduce it with fedora-review ran locally on spec/srpm. Added --disable-rpath to %configure anyway. > > It also reports mismatch in sizes/checksums of the tarball, which is > > expected: current link is for prev release, we will create a new one > > (v1.2.1) once pass this review. > > That is completely *unexpected*. The SourceURL *must* link exactly the source > archive that is included in the src.rpm. > > https://fedoraproject.org/wiki/Packaging:ReviewGuidelines > > MUST: The sources used to build the package must match the upstream source, > as provided in the spec URL. Reviewers should use sha256sum for this task as > it is used by the sources file once imported into git. If no upstream URL can > be specified for this package, please see the Source URL Guidelines for how > to deal with this. Just want to have issues in spec fixed before creating actual release. Can we ignore this one for a while? Once others are resolved I'll fix it ASAP (will required creating a release). -- 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@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org