Bug 983608 (gpaw)

Summary:	Review Request: gpaw - A density-functional theory code based on the PAW method
Product:	[Fedora] Fedora	Reporter:	Susi Lehtola <susi.lehtola>
Component:	Package Review	Assignee:	Nobody's working on this, feel free to take it <nobody>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	i, Marcin.Dulak, package-review
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-04-22 11:52:23 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	983614, 1090070
Bug Blocks:

Description Susi Lehtola 2013-07-11 14:35:30 UTC

Spec URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/gpaw.spec

SRPM URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/gpaw-0.9.1.10509-1.fc19.src.rpm

Description:
GPAW is a density-functional theory (DFT) Python code based on the
projector-augmented wave (PAW) method and the atomic simulation
environment (ASE). It uses real-space uniform grids and multigrid
methods or atom-centered basis functions.

Fedora Account System Username: jussilehtola

rpmlint output:
gpaw.x86_64: W: spelling-error %description -l en_US multigrid -> multitude
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-mapfile-cray
gpaw.x86_64: W: no-manual-page-for-binary gpaw-test
gpaw.x86_64: W: no-manual-page-for-binary gpaw-basis
gpaw.x86_64: W: no-manual-page-for-binary gpaw-mapfile-bgp
gpaw.x86_64: W: no-manual-page-for-binary gpaw
gpaw.x86_64: W: no-manual-page-for-binary analyse-basis
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: spelling-error %description -l en_US multigrid -> multitude
gpaw-openmpi.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 13 warnings.

Comment 1 Christopher Meng 2013-07-11 15:27:08 UTC

Hi,

Please remove python_sitearch define, BuildRoot tag, rm -rf %{buildroot} in %install section, whole %clean section and %defattr(-,root,root,-) from your spec.

As SRPM needs all BRs to build main and sub pkgs, no matter how many subpackages are existed, please move all BuildRequires in subpackages, like:

BuildRequires:  python2-devel
BuildRequires:	numpy
BuildRequires:	python-ase
BuildRequires:	atlas-devel
BuildRequires:	hdf5-devel
BuildRequires:	libxc-devel
BuildRequires:  scalapack-openmpi-devel
BuildRequires:  blacs-openmpi-devel
BuildRequires:  hdf5-openmpi-devel
BuildRequires:  openmpi-devel
BuildRequires:  scalapack-mpich2-devel
BuildRequires:  blacs-mpich2-devel
BuildRequires:  hdf5-mpich2-devel
BuildRequires:  mpich2-devel

Comment 2 Susi Lehtola 2013-07-11 16:50:50 UTC

(In reply to Christopher Meng from comment #1)
> Hi,
> 
> Please remove python_sitearch define, BuildRoot tag, rm -rf %{buildroot} in
> %install section, whole %clean section and %defattr(-,root,root,-) from your
> spec.

Although these are defaulted on current versions of Fedora, having them doesn't hurt and is in fact necessary to be able to build on EPEL.

> As SRPM needs all BRs to build main and sub pkgs, no matter how many
> subpackages are existed, please move all BuildRequires in subpackages, like:

Non sequitur. The SRPM will get all the BRs from the subpackages. The separate BRs for the subpackages are because the BRs are only for those subpackages. If there is yet another MPI runtime, it will get its own subpackage and own buildrequires.

Comment 3 Christopher Meng 2013-11-18 12:26:20 UTC

Would you like to use daily snapshot for instance:

https://wiki.fysik.dtu.dk/gpaw/gpaw-0.9.1.10814.tar.gz

as source0?

And can you check the patchs if they've been merged into upstream?

Comment 4 Susi Lehtola 2013-11-18 17:01:17 UTC

(In reply to Christopher Meng from comment #3)
> Would you like to use daily snapshot for instance:
> 
> https://wiki.fysik.dtu.dk/gpaw/gpaw-0.9.1.10814.tar.gz
> 
> as source0?

No, because the daily snapshots vanish from the mirror (and possibly also can change checksums).
 
> And can you check the patchs if they've been merged into upstream?

This is not really relevant for anything, these are Fedora specific patches.

Besides, had they been merged, applying the patches to a newer snapshot will fail.

Comment 5 marcindulak 2014-04-22 09:30:07 UTC

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

Comment 6 marcindulak 2014-04-22 09:34:25 UTC

Hi Susi,

are you still willing to maintain GPAW?
You find a complete up-to-date spec i created without being aware of your review request. Note the %check section that runs a subset of gpaw-test and that some tests need to be disabled (problems known in the gpaw trunk or old scalapck/numpy issues).

Comment 7 Susi Lehtola 2014-04-22 11:52:23 UTC

(In reply to marcindulak from comment #6)
> Hi Susi,
> 
> are you still willing to maintain GPAW?
> You find a complete up-to-date spec i created without being aware of your
> review request. Note the %check section that runs a subset of gpaw-test and
> that some tests need to be disabled (problems known in the gpaw trunk or old
> scalapck/numpy issues).

Actually, I think it's probably better to let someone else handle this, as I don't use gpaw myself and am pretty much always busy with other stuff!

So please, go ahead.

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