Bug 760645

Summary: Review Request: ergo - A quantum chemistry program for large-scale self-consistent field calculations
Product: [Fedora] Fedora Reporter: Fabien Archambault <marbolangos>
Component: Package ReviewAssignee: 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: unspecified    
Version: rawhideCC: alpha, notting, package-review, pikachu.2014, susi.lehtola, terjeros, tibbs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-05 07:56:51 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Fabien Archambault 2011-12-06 12:20:36 EST
Spec URL: ftp://dedimarbo.ath.cx/pub/repo/specs/ergo.spec
SRPM URL (F16): ftp://dedimarbo.ath.cx/pub/repo/srpms/ergo-3.1-1.fc16.src.rpm
SRPM URL (EL6): ftp://dedimarbo.ath.cx/pub/repo/srpms/ergo-3.1-1.el6.src.rpm

Key features of the Ergo program:
Performs electronic structure calculations using Hartree-Fock and Kohn-Sham
density functional theory.
- Written in C++.
- Uses Gaussian basis sets.
- Both core and valence electrons are included in the calculations.
- Both restricted and unrestricted models are implemented for energy
- Implements a broad range of both pure and hybrid Kohn-Sham density
- Employs modern linear scaling techniques like fast multipole methods,
hierarchic sparse matrix algebra, density matrix purification, and efficient
integral screening.
- Linear scaling is achieved not only in terms of CPU usage but also memory
- The time consuming parts of the code are currently parallelized using the
shared-memory paradigm.

Here are the different rpmlint:
$ rpmlint ergo-3.1-1.fc16.x86_64.rpm
ergo.x86_64: W: spelling-error %description -l en_US functionals -> functional, functional s, functionary
ergo.x86_64: W: spelling-error %description -l en_US multipole -> multiple
ergo.x86_64: W: spelling-error %description -l en_US parallelized -> paralleled, palatalized, pluralized
ergo.x86_64: W: no-manual-page-for-binary bin2m
ergo.x86_64: W: no-manual-page-for-binary ergo
1 packages and 0 specfiles checked; 0 errors, 5 warnings.
$ rpmlint ergo-debuginfo-3.1-1.fc16.x86_64.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint ergo-3.1-1.fc16.src.rpm 
ergo.src: W: spelling-error %description -l en_US functionals -> functional, functional s, functionary
ergo.src: W: spelling-error %description -l en_US multipole -> multiple
ergo.src: W: spelling-error %description -l en_US parallelized -> paralleled, palatalized, pluralized
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

Concerning the man-pages, I am in touch with the developers and they planned to add it in the next version of the software.
All spelling given are wrong. This is the vocabulary in quantum chemistry.
Comment 1 Aleksandra Bookwar 2011-12-06 18:25:27 EST
Hi, I am not a packager yet, so this is just informal review.

+ rpmlint must be run on the source rpm and all binary rpms the build produces. 
Except false spelling alarm no errors:
$ rpmlint ergo
   ergo.x86_64: W: no-manual-page-for-binary bin2m
   ergo.x86_64: W: no-manual-page-for-binary ergo
1 packages and 0 specfiles checked; 0 errors, 5 warnings.
$ rpmlint ergo-debuginfo
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
$ rpmlint ergo-3.1-1.fc16.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

+ The package must be named according to the Package Naming Guidelines .

There is "alt-ergo" package in Fedora repositories, but there are no conflicts in filenames or libs.

+ The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
+ The package must meet the Packaging Guidelines .
+ The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
+ The License field in the package spec file must match the actual license.

Are you sure that this is the GPLv3+ version? The project site states only GPL without proper versioning, so you probably need to clarify it.

+ 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 must be included in %doc.
+ The spec file must be written in American English.
+ The spec file for the package MUST be legible.
+ The sources used to build the package must match the upstream source, as provided in the spec URL.
+ The package MUST successfully compile and build into binary rpms on at least one primary architecture.
+ All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional.
* The spec file MUST handle locales properly.
* Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
+ Packages must NOT bundle copies of system libraries.
* If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package.
+ A package must own all directories that it creates.
+ A Fedora package must not list a file more than once in the spec file's %files listings.
+ Permissions on files must be set properly. Executables should be set with executable permissions, for example.
+ Each package must consistently use macros.
+ The package must contain code, or permissable content.
* Large documentation files must go in a -doc subpackage.
+ If a package includes something as %doc, it must not affect the runtime of the application.
* Header files must be in a -devel package.
* Static libraries must be in a -static package.
* If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
* In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
+ Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
* Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section.
+ Packages must not own files or directories already owned by other packages.
+ All filenames in rpm packages must be valid UTF-8.

* If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
* The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
+ package builds in mock.
+ The package should compile and build into binary rpms on all supported architectures.
+ functions as described in tutorial
+ If scriptlets are used, those scriptlets must be sane.
* Usually, subpackages other than devel should require the base package using a fully versioned dependency.
* The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg.
* If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself.
- your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.

And it seems that except man-pages and small license question, the package fits all the guidelines. Hope to see it soon in the repos.
Comment 2 Fabien Archambault 2011-12-07 11:48:22 EST

Thank you for this informal review.

> Are you sure that this is the GPLv3+ version?
I know within the website it is only GPL but the COPYING file is GPLv3+. I was helped by someone who is already an approved Fedora packager to pinpoint the right license.

Concerning the man-pages as I stated in my initial message, I am already in touch with the developers and they are going to build one for the next version (due in a short amount of time).
Comment 3 Mohamed El Morabity 2011-12-07 12:05:03 EST
(In reply to comment #1)
> Are you sure that this is the GPLv3+ version? The project site states only GPL
> without proper versioning, so you probably need to clarify it.
Each source file refer to the GPLv3 or more in its comments.

> And it seems that except man-pages and small license question, the package fits
> all the guidelines. Hope to see it soon in the repos.
Man pages are not mandatory, it's up to upstream developers, it's not a blocker for a review.
Comment 4 Terje Røsten 2011-12-07 12:43:48 EST
Nice work! 

Could you please create a FAS account and provide link to koji scratch build too?

Some help here: 

Comment 5 Fabien Archambault 2011-12-07 13:43:17 EST

I have build against F17 the rpms in koji:
- http://koji.fedoraproject.org/koji/taskinfo?taskID=3572928

Also for Epel6:
- http://koji.fedoraproject.org/koji/taskinfo?taskID=3572936

Do I need to build it against F16?
Comment 6 Terje Røsten 2011-12-07 16:03:34 EST
Very nice, F16 build not needed, thanks!
Comment 7 Susi Lehtola 2011-12-08 15:42:11 EST
FYI, I did some work on this package in the summer, and got upstream to fix a bunch of review blockers in the package (IIRC including license boilerplates that were missing).

However I did not submit it into review as I was not sure if it would have any use, since the program quite specialized. Anyway, the spec file I created (should comply to all Fedora standards) is available at

Fabien: do you use ErgoSCF yourself?
Comment 8 Susi Lehtola 2011-12-08 15:49:06 EST
Also, I might be interested in sponsoring you. It'd be nice to have some help in managing scientific software in Fedora.
Comment 9 Fabien Archambault 2011-12-13 04:02:17 EST

Sorry for the delay to answer.

@Jussi Lehtola: I will take a look at your spec version to see if there are some things I can add or modify.
Concerning my use of ergo, I was asked to compile it on a cluster where users will have to use it so I will have to follow updates and improvements in the package. If your question was about following the package.
Using it on the computer is not yet an objective for me but I have some colleagues who should be interested to install it on there computer to run some small single points before going to cluster or smp calculations.
I know this is a very specific package but it is at the same level as mpqc or cp2k which are already within the repositories. I believe adding it to Fedora and CentOS is a way for such a package to be found and used.

For the sponsoring, I made one informal review (see: https://bugzilla.redhat.com/show_bug.cgi?id=760897). It was an easy, I will make another one soon.
I am also working on another package (psicode also named psi3) still related to quantum chemistry but I have an issue with upstream not replying to my emails...
Comment 10 Susi Lehtola 2011-12-13 05:13:49 EST
I wouldn't bother with psi3, since it isn't really maintained by upstream, and needs *lots* of work to get rid of all of the bundled libraries. Psi4 should be out in a couple of months, so I'm waiting for that. [And the name of the package is just "psi"; although rather unfortunately there is already a package in Fedora with that name].

Do you have any other submissions at the moment?
Comment 11 Fabien Archambault 2011-12-15 03:11:06 EST
About psi3 I do not believe there is s much to do. You can see at ftp://dedimarbo.ath.cx/pub/repo/srpms/psicode-3.4.0-1.fc16.src.rpm that the src.rpm is nearly optimal. I just have problems with manpages and you have to consider that I made other updates that are not yet pushed in my ftp.
I did not find bundled libraries, perhaps will I have to look further into it.
I know psi4 will be released soon but it is nearly 4 months they say it...

I have yet no other submissions but I have some ideas on other software that could probably be added. I did not try to make the SRPM yet.
Comment 12 Susi Lehtola 2012-01-09 05:08:35 EST
Ping Fabien? Any progress on the incorporation?


I am willing to sponsor you if you show me your knowing of the Fedora guidelines, most importantly
In addition to the Packaging Guidelines, there are a bunch of language / application specific guidelines that are linked to in the Packaging Guidelines.

Here are some tricks of the trade:

I will sponsor you if you have at least one other submission and perform a couple of informal reviews of packages of other people.

Please review only packages *not* marked with FE-NEEDSPONSOR. I will have to do the full formal review after you to check that you have got everything correctly. Once I have sponsored you you will be able to do formal reviews of your own.
Comment 13 Fabien Archambault 2012-01-09 05:42:24 EST
Hi Jussi,

I replied by email to your proposition to integrate your spec and I believe it should be faster to do it with your spec. If needed I can close this bug and you can open yours.
Comment 14 Susi Lehtola 2012-01-09 06:59:33 EST
You can use my spec. But someone else will then have to review this bug.

I can sponsor you in any case, provided you make another submission and perform some informal reviews.
Comment 15 Jason Tibbitts 2012-07-03 17:04:05 EDT
Did anything ever happen here?
Comment 16 Susi Lehtola 2012-07-04 02:35:11 EDT
No. If no-one disagrees, I'll close this bug and open one with my own spec file.
Comment 17 Jason Tibbitts 2012-07-04 02:41:01 EDT
Don't see why know.  Fabien can always co-maintain if he wishes.
Comment 18 Susi Lehtola 2012-07-05 07:56:51 EDT
Closing as duplicate.

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