Bug 1087812

*** This bug has been marked as a duplicate of bug 983608 ***

*** Bug 983608 has been marked as a duplicate of this bug. ***

gpaw-setups needs to be a wholly separate package, as you mention in comment #0.

OK: gpaw is waiting for review here, and gpaw-setups coming shortly.

Spec URL: http://marcindulak.fedorapeople.org/packages/gpaw/r01/gpaw.spec
SRPM URL: http://marcindulak.fedorapeople.org/packages/gpaw/r01/gpaw-0.10.0.11364-1.fc21.src.rpm

You still need to get rid of the gpaw-setups stuff here.

Every gpaw release is bound for the specific gpaw-setups for the gpaw-test to pass, and therefore gpaw must have access to gpaw-setups during the rpmbuild.
gpaw-setups is an independent package.

Oh. Then please make a note of this in the spec file.

Or, you could just stop bundling gpaw-setups, and either BuildRequire the wanted version of gpaw-setups, or run the tests only if the existing gpaw-setups package is of the matching version.

In any case, I think bundling the sources for gpaw-setups is not allowed...

You can achieve the latter by e.g. implementing a _gpaw_setups_version rpm macro in gpaw-setups, i.e. in gpaw-setups

%global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] || d=%{_sysconfdir}/rpm; echo $d)

%install
mkdir -p %{buildroot}%{macrosdir}
cat > %{buildroot}%{macrosdir}/macros.libint << EOF
# Current version of gpaw-setups is
%_gpaw_setups_version %{version}
EOF

I can't BuildRequires the specific version of the setups because there will be only one version of gpaw-setups available in the Fedora repos at a time.

If i modify gpaw.spec to run gpaw-test only if specific version of gpaw-setups is present in the repositories, then after new gpaw-setups are released but still no new gpaw i won't be able to run gpaw-test during rebuild of gpaw (e.g. due to mass rebuild, or update of some other BuildRequires).

I'm not sure how clearly the concept of bundling is defined but what happens here
is using static data (gpaw-setups) for tests. I guess gpaw-setups is not a library. Is there a specific forum/mailing-list where we could clarify this - or do we need to go directly for bundling exception?

I think it'd be good to ask the FPC for an exception here. There are no security issues I can think of. The main thing is maybe that the sources and the SRPM are 5000% bigger if the setups are included.

Asked the question here first: https://lists.fedoraproject.org/pipermail/packaging/2014-April/010145.html

gpaw.spec has been updated and it does not bundle gpaw-setups anymore.

Please change the revision and changelog accordingly.

Also, I suggest you use ATLAS on architectures that don't have OpenBLAS.  The link should then be made against
 -L%{_libdir} -llapack -lf77blas -latlas
on older Fedoras / RHEL, and
 -L%{_libdir} -lsatlas
on newer ones. I think all the other requirements are available on arm and ppc.

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable

===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: 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 %doc.
[x]: License field in the package spec file matches the actual license.
[-]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: 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.
- I'm not sure about the openssh-clients buildrequire.
- You can drop BR: gcc, it's always included. https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Exceptions_2

[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: 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.
[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]: Package does not contain duplicates in %files.

[!]: Permissions on files are set properly.
- The .so library needs 755 permissions.

[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[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]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[!]: 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.
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: 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.
[x]: %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]: 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]: Dist tag is present (not strictly required in GL).
[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.

Rpmlint
-------
gpaw.src: W: spelling-error %description -l en_US multigrid -> multitude
gpaw.x86_64: W: spelling-error %description -l en_US multigrid -> multitude
gpaw.x86_64: W: unstripped-binary-or-object /usr/lib64/python2.7/site-packages/_gpaw.so
gpaw.x86_64: W: no-documentation
gpaw.x86_64: W: no-manual-page-for-binary gpaw-setup
gpaw.x86_64: W: no-manual-page-for-binary gpaw-mpisim
gpaw.x86_64: W: no-manual-page-for-binary gpaw-run
gpaw.x86_64: W: no-manual-page-for-binary gpaw-mapfile-cray
gpaw.x86_64: W: no-manual-page-for-binary gpaw-basis
gpaw.x86_64: W: no-manual-page-for-binary gpaw-test
gpaw.x86_64: W: no-manual-page-for-binary gpaw-runscript
gpaw.x86_64: W: no-manual-page-for-binary gpaw-mapfile-bgp
gpaw.x86_64: W: no-manual-page-for-binary gpaw-install-setups
gpaw-common.noarch: W: summary-not-capitalized C gpaw - common files
gpaw-common.noarch: W: spelling-error %description -l en_US multigrid -> multitude
gpaw-mpich.x86_64: W: summary-not-capitalized C gpaw - mpich version
gpaw-mpich.x86_64: W: spelling-error %description -l en_US multigrid -> multitude
gpaw-mpich.x86_64: W: no-documentation
gpaw-openmpi.x86_64: W: summary-not-capitalized C gpaw - openmpi version
gpaw-openmpi.x86_64: W: spelling-error %description -l en_US multigrid -> multitude
gpaw-openmpi.x86_64: W: no-documentation
6 packages and 0 specfiles checked; 0 errors, 21 warnings.

These are OK, except for the unstripped-binary-or-object caused by the wrong permissions of the .so file.

The MPI stuff is OK as well.

I'd ask you to be a little bit more verbose in %files, since free usage of wildcards can have devastating results. I suggest

%files
%{_bindir}/%{name}*
%{python_sitearch}/%{name}/
%{python_sitearch}/%{name}-%{version}-py*.egg-info

This will also catch if the egg-info isn't produced.

I start addressing the problems. Can you make libxc available on el7.ppc64?
It also looks to me that *mpich2, scipy are not available on el6.ppc64, is there an easy %if macro to say (not el6.ppc64)?

What's your opinion about getting openblas on el7.x86_64?

(In reply to marcindulak from comment #17)
> I start addressing the problems. Can you make libxc available on el7.ppc64?

I haven't bothered with epel7 yet, since rhel7 isn't out yet and so it'd be difficult to debug the builds if necessary.

Same for openblas.

> It also looks to me that *mpich2, scipy are not available on el6.ppc64, is
> there an easy %if macro to say (not el6.ppc64)?

Uhm, I think not.
%ifarch ppc64
%if 0%{?rhel} == 6
foo
%endif
%endif

I prefer to wait with epel7 until openblas/libxc are in epel7.x86_64.
I also exclude el6.ppc64 from the spec.
Fedora %arm builds (with atlas).

Other problems fixed:
- openssh-clients BR is needed for mpiexec to run (see http://koji.fedoraproject.org/koji/taskinfo?taskID=6817438 - this is an epel6 build where there is no openssh-clients dependency pulled in and mpiexec fails with "ORTE_ERROR_LOG: Not found in file ess_hnp_module.c at line 194").
I experienced the same issue on the opensuse build system.
- gcc BR removed
- _gpaw.so permissions fixed
- COPYING will be included in the gpaw tarball (from the next release) https://trac.fysik.dtu.dk/projects/gpaw/changeset/11439
- %files glob more explicit

Spec URL: http://marcindulak.fedorapeople.org/packages/gpaw/r02/gpaw.spec
SRPM URL: http://marcindulak.fedorapeople.org/packages/gpaw/r02/gpaw-0.10.0.11364-2.fc21.src.rpm

Are you sure gpaw doesn't need scipy to run?

**

I believe hdf5 (and its MPI flavors) should be added as BuildRequirements, so that gpaw gets built support for these.

**

If you can, you should modify the upstream setup.py so that the libraries are always installed as 755. It's standard for *nix shared libraries.

**

Actually,
MUST: Each package must consistently use macros.

is not OK. You are mixing %{buildroot} (1 occurrence) and %{optflags} (2 occurrences) vs $RPM_BUILD_ROOT (4 occurrences) and $RPM_OPT_FLAGS (0 occurrences).

http://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS

To fix this, replace the 3 occurrences of $RPM_BUILD_ROOT with %{buildroot}. If you like, you can also replace %{buildroot} and %{optflags} with $RPM_BUILD_ROOT and $RPM_OPT_FLAGS.

The only blocker is the last one, which I trust you'll fix before git import. This package has been

APPROVED

New Package SCM Request
=======================
Package Name: gpaw
Short Description: A grid-based real-space PAW method DFT code
Owners: marcindulak
Branches: f19 f20 el6 epel7
InitialCC:

Git done (by process-git-requests).

gpaw-0.10.0.11364-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-3.el6

gpaw-0.10.0.11364-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-3.fc19

gpaw-0.10.0.11364-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-3.fc20

gpaw-0.10.0.11364-3.el6 has been pushed to the Fedora EPEL 6 testing repository.

gpaw-0.10.0.11364-5.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-5.el6

gpaw-0.10.0.11364-5.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-5.fc19

gpaw-0.10.0.11364-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/gpaw-0.10.0.11364-5.fc20

gpaw-0.10.0.11364-5.el6 has been pushed to the Fedora EPEL 6 stable repository.

gpaw-0.10.0.11364-5.fc19 has been pushed to the Fedora 19 stable repository.

gpaw-0.10.0.11364-5.fc20 has been pushed to the Fedora 20 stable repository.