https://bugzilla.redhat.com/show_bug.cgi?id=1474033
--- Comment #7 from Andrey Maslennikov <andreyma(a)mellanox.com> ---
Spec URL:
https://gist.github.com/amaslenn/3c847e0bdc063bcbb4b6507b5efbf6b9/raw/9c7...
SRPM URL:
https://gist.github.com/amaslenn/3c847e0bdc063bcbb4b6507b5efbf6b9/raw/9c7...
Koji build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21125023
Please see details on what was done regarding your first review (sorry for not
posting it with prev comment):
> %global rel 1
> %global version 1.3.3274
Completely pointless definition and redefinition of macros for various reasons:
1) You define %rel only to use it once in the spec file.
2) You also use %release and not only %rel.
3) The "Release" tag implicitly defines %release, so both macros would be the
same.
4) The "Version" tag implicitly defines %version. You redefine %version.
Further, the dist tag is missing:
https://fedoraproject.org/wiki/Packaging:Versioning#Simple_versioning Removed extra
assignments, new code looks following:
Name: ucx
Version: 1.2.0
Release: 1%{?dist}
> %global __check_files %{nil}
Comment/rationale missing!
Removed.
> %bcond_with valgrind
No-op due to nothing related within the spec file.
Removed.
> Summary: Unified Communication X
That's only what the UCX acronym stands for. The %description could explain that and
expand on the > summary, while the %summary could tell a bit more:>
Summary: Communication framework for data centric and high-performance applications
Summary/Description for both packages were updated.
> Group: Development/Libraries
No. The group for system runtime library packages is "System
Environment/Libraries" for decades. On the contrary,
"Development/Libraries" is for -devel packages, for example.
Fixed.
Fixed, new
value is
https://github.com/openucx/%{name}/archive/v1.2.0.tar.gz.
Added
comment: "UCX currently supports only the following architectures".
> Requires(post): /sbin/ldconfig
> Requires(postun): /sbin/ldconfig
Implicit and automatic with /sbin/ldconfig scriptlets for a *very* long time.
Removed.
> %description
> %description devel
Odd that the -devel package contains the more detailed description. The base package also
contains more than libraries, lacking an explanation.
Updated. Now -devel package
contains only additional info.
> %build
> ./contrib/configure-release \
That's a configure script for which you really want to use the %configure macro. See
"rpm -E %configure" on what it does.
Updated to use %configure.
> mkdir -p %{buildroot}%{_sysconfdir}/ld.so.conf.d/
> echo %{_libdir} > %{buildroot}%{_sysconfdir}/ld.so.conf.d/ucx.conf
No, %_libdir is in the default search path list for runtime libs.
Removed.
Removed.
> %files
> %{_libdir}/lib*.so.*
> %{_bindir}/uc*
> %{_datadir}/ucx/perftest/*
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ow...
Extra files are now removed in %install, fixed issue with file pattern. Is
there anything else to fix here? Please also see below.
> %{_sysconfdir}/ld.so.conf.d/ucx.conf
Superfluous.
Removed.
-devel package now has 'Provides: %{name}-static = %{version}-%{release}'.
> %changelog
> * Mon Jul 3 2017 Andrey Maslennikov <andreyma(a)mellanox.com> 1.3
> - Fedora package created
Not matching %version.
Fixed.
>
https://kojipkgs.fedoraproject.org//work/tasks/8693/20688693/build.log
Please look for ways to make build output verbose, so more of the compiler/linker calls
and options can be seen in the build.log. You may need to disable .silent rules or execute
Make with V=1, or enable other settings in the build framework.
Added V=1 to make
command.
Regarding fedora-review tool.
It reports "[!]: Package should not use obsolete m4 macros" complaining on
AC_PROG_LIBTOOL. Is it critical and has to fixed?
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?
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.
Other checks look good.
--
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