This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 983608 - (gpaw) Review Request: gpaw - A density-functional theory code based on the PAW method
Review Request: gpaw - A density-functional theory code based on the PAW method
Status: CLOSED DUPLICATE of bug 1087812
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On: gpaw-setups 1090070
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 10:35 EDT by Susi Lehtola
Modified: 2014-04-22 09:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-22 07:52:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Susi Lehtola 2013-07-11 10:35:30 EDT
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 11:27:08 EDT
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 12:50:50 EDT
(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 07:26:20 EST
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 12:01:17 EST
(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 05:30:07 EDT
*** Bug 1087812 has been marked as a duplicate of this bug. ***
Comment 6 marcindulak 2014-04-22 05:34:25 EDT
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 07:52:23 EDT
(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.