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 Description: 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 calculations. - Implements a broad range of both pure and hybrid Kohn-Sham density functionals. - 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 utilization. - 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.
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.
Hi, 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).
(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.
Nice work! Could you please create a FAS account and provide link to koji scratch build too? Some help here: http://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds
Hi, 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?
Very nice, F16 build not needed, thanks!
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 http://theory.physics.helsinki.fi/~jzlehtol/rpms/ergo.spec Fabien: do you use ErgoSCF yourself?
Also, I might be interested in sponsoring you. It'd be nice to have some help in managing scientific software in Fedora.
Hello, 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...
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?
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.
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 http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines 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: http://fedoraproject.org/wiki/Packaging_tricks http://fedoraproject.org/wiki/Packaging/ScriptletSnippets http://fedoraproject.org/wiki/Common_Rpmlint_issues 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.
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.
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.
Did anything ever happen here?
No. If no-one disagrees, I'll close this bug and open one with my own spec file.
Don't see why know. Fabien can always co-maintain if he wishes.
Closing as duplicate. *** This bug has been marked as a duplicate of bug 837816 ***