Bug 983608 (gpaw) - Review Request: gpaw - A density-functional theory code based on the PAW method
Summary: Review Request: gpaw - A density-functional theory code based on the PAW method
Keywords:
Status: CLOSED DUPLICATE of bug 1087812
Alias: gpaw
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: gpaw-setups 1090070
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-11 14:35 UTC by Susi Lehtola
Modified: 2014-04-22 13:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-22 11:52:23 UTC
Type: ---


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.