Bug 498246

It's only 'pre-review' since I can't be a sponsor.

- You package doesn't build. It seems that a BuildRequire is missing (I suppose openmpi-devel )

- Instead of using command for adding shebang, you should better use a patch in the spec, and give it at upstream !

- I think that "%doc license.gpl Examples/" is not a good thing. Because Examples/ contains some executable. Install it with the doc flags modify the rights.

- In the file /usr/share/towhee/Forcefields, you remove Makefile but not Makefile.am and Makefile.in

- Some macros are available in rpm like %{_cat}, %{_cp} ... for coherence you should consider to use them.

- Extract from guidelines " Use %global instead of %define, unless you really need only locally defined submacros within other macro definitions (a very rare case)."

(In reply to comment #1)
> It's only 'pre-review' since I can't be a sponsor.

But you don't need to be a sponsor to do reviews, just an approved packager (you need to be sponsorED).

> - You package doesn't build. It seems that a BuildRequire is missing (I suppose
> openmpi-devel )

I copypasted the MPI stuff from another spec file and didn't see that the openmpi requirement was elsewhere. Forgot to try mock build. Fixed.

> - Instead of using command for adding shebang, you should better use a patch in
> the spec, and give it at upstream !

True. Emailed upstream.
 
> - I think that "%doc license.gpl Examples/" is not a good thing. Because
> Examples/ contains some executable. Install it with the doc flags modify the
> rights.

No, it is quite standard to ship executable scripts in %doc, as the program works without them; they're just examples of use.
 
> - In the file /usr/share/towhee/Forcefields, you remove Makefile but not
> Makefile.am and Makefile.in

Nope,
 find Examples/ -name "Makefile*" -exec rm {} \;
also removes Makefile.*


> - Some macros are available in rpm like %{_cat}, %{_cp} ... for coherence you
> should consider to use them.

On the contrary, it is not considered clean to use macros for these sorts of things. Macros should only be used when absolutely necessary, not for standard unix commands as cp, mv, rm, mkdir and so on.
 
> - Extract from guidelines " Use %global instead of %define, unless you really
> need only locally defined submacros within other macro definitions (a very rare
> case)."  

Good catch, this was also because of cut'n'paste. Fixed.


http://theory.physics.helsinki.fi/~jzlehtol/rpms/towhee.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/towhee-6.2.2-2.fc10.src.rpm

(In reply to comment #2)

> But you don't need to be a sponsor to do reviews, just an approved packager
> (you need to be sponsorED).
It was that I meant, I am not an approved packager. Sorry.


> > - I think that "%doc license.gpl Examples/" is not a good thing. Because
> > Examples/ contains some executable. Install it with the doc flags modify the rights.
> 
> No, it is quite standard to ship executable scripts in %doc, as the program
> works without them; they're just examples of use.
> 

If you think people don't have to run them, I think it is good.


> - In the file /usr/share/towhee/Forcefields, you remove Makefile but not
> > Makefile.am and Makefile.in
> 
> Nope,
>  find Examples/ -name "Makefile*" -exec rm {} \;
> also removes Makefile.*

I don't talk about Examples, but about /usr/share/towhee/Forcefields.

(16:21:58)-[manawy@teatime ~]$ ls /usr/share/towhee/ForceFields
Makefile.am          Makefile.in  ...

I mix the two files it's right sorry. You don't remove nothing from this file. Anyway, Makefile.am and Makefile.in are installed but useless without the configure script.


> 
> > - Some macros are available in rpm like %{_cat}, %{_cp} ... for coherence you  should consider to use them.
> 
> On the contrary, it is not considered clean to use macros for these sorts of
> things. Macros should only be used when absolutely necessary, not for standard unix commands as cp, mv, rm, mkdir and so on.

That's surprising ... defined but useless macros. But of course, it is not mandatory. (And I read a new time the packaging guidelines, nothing are mentionned about this (except for directory). It is not in this document I read it is better to use macros. So like you want :)

(In reply to comment #3)
> (In reply to comment #2)
> 
> > But you don't need to be a sponsor to do reviews, just an approved packager
> > (you need to be sponsorED).
> It was that I meant, I am not an approved packager. Sorry.

No problem. I see Mamoru is your sponsor.

Reviewing packages is really important, even more so with the very long review queue we have at the moment.

> > > - I think that "%doc license.gpl Examples/" is not a good thing. Because
> > > Examples/ contains some executable. Install it with the doc flags modify the rights.
> > 
> > No, it is quite standard to ship executable scripts in %doc, as the program
> > works without them; they're just examples of use.
> 
> If you think people don't have to run them, I think it is good.

Yes, this is the way %doc is supposed to work: extra stuff that is not mandatory for the program to run, such as manuals and examples.

> > - In the file /usr/share/towhee/Forcefields, you remove Makefile but not
> > > Makefile.am and Makefile.in
> > 
> > Nope,
> >  find Examples/ -name "Makefile*" -exec rm {} \;
> > also removes Makefile.*
> 
> I don't talk about Examples, but about /usr/share/towhee/Forcefields.

Duh, sorry, I must have misread you the first time. Removed.


http://theory.physics.helsinki.fi/~jzlehtol/rpms/towhee.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/towhee-6.2.2-3.fc10.src.rpm

ping?

Sorry it took so long.

(In reply to comment #2)
> No, it is quite standard to ship executable scripts in %doc, as the program
> works without them; they're just examples of use.

You can ship scripts in %doc if they are not executable, so no problem here. But IMO you should consider packaging the Examples separately, it's 9 MB one the disk and as you said people don't necessarily need the files.


REVIEW FOR towhee-6.2.2-3.fc10.src.rpm

OK - MUST: rpmlint must be run on every package. The output should be posted in the review.
$ rpmlint /var/lib/mock/fedora-rawhide-i386/result/towhee-*
5 packages and 0 specfiles checked; 0 errors, 0 warnings.
OK - MUST: The package is named according to the Package Naming Guidelines.
OK - MUST: The spec file name matches the base package %{name}, in the format %{name}.spec.
OK - MUST: The package meets the Packaging Guidelines.
OK - MUST: The package is licensed with a Fedora approved license and meets the Licensing Guidelines: GPLv2+
OK - MUST: The License field in the package spec file matches the actual license.
OK - MUST: The license file from the source package is included in %doc.
OK - MUST: The spec file is in American English.
OK - MUST: The spec file for the package is legible.
OK - MUST: The sources used to build the package match the upstream source by MD5 f911980711593a07b6e80e147eb03339
OK - MUST: The package successfully compiles and builds into binary rpms on i386
N/A - MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch.
OK - MUST: All build dependencies are listed in BuildRequires.
N/A - MUST: The spec file handles locales properly with the %find_lang macro.
N/A - MUST: 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.
N/A - MUST: 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.
OK - MUST: The package owns all directories that it creates.
OK - MUST: The package does not contain any duplicate files in the %files listing.
OK - MUST: Permissions on files are set properly. Every %files section includes a %defattr(...) line.
OK - MUST: The package has a %clean section, which contains rm -rf %{buildroot}.
OK - MUST: The package consistently uses macros, as described in the macros section of Packaging Guidelines.
OK - MUST: The package contains code, or permissable content.
FIX? - MUST: Large documentation files should go in a -doc subpackage.
OK - MUST: Files included as %doc do not affect the runtime of the application.
N/A - MUST: Header files must be in a -devel package.
N/A - MUST: Static libraries must be in a -static package.
N/A - MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'.
N/A - MUST: 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.
N/A - MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}
OK - MUST: The package does not contain any .la libtool archives.
N/A - MUST: 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.
OK - MUST: The package does not own files or directories already owned by other packages.
OK - MUST: At the beginning of %install, the package runs rm -rf %{buildroot}.
OK - MUST: All filenames in rpm packages are valid UTF-8.


SHOULD Items:
N/A - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it.
N/A - SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available.
OK - SHOULD: The the package builds in mock.
OK - SHOULD: The package should compile and build into binary rpms on all supported architectures.
OK - SHOULD: The package functions as described.
N/A - SHOULD: If scriptlets are used, those scriptlets must be sane.
OK - SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency.
N/A - SHOULD: 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.
N/A - SHOULD: 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.


OTHER Items:
OK - timestamps are preserved
OK - optflags are honored


Issues:
- does not build in rawhide, because there is no openmpi-devel anymore, see
  http://koji.fedoraproject.org/koji/buildinfo?buildID=99188
- I suggest to make the common package noarch.
- separate doc package?
- use pushd/popd instead cd/cd ..

Add a conditional openmpi on F-12. The rest is minor, the package is APPROVED by cwickert

(In reply to comment #6)
> Sorry it took so long.
> 
> (In reply to comment #2)
> > No, it is quite standard to ship executable scripts in %doc, as the program
> > works without them; they're just examples of use.
> 
> You can ship scripts in %doc if they are not executable, so no problem here.
> But IMO you should consider packaging the Examples separately, it's 9 MB one
> the disk and as you said people don't necessarily need the files.

Done.

> Add a conditional openmpi on F-12. The rest is minor, the package is APPROVED
> by cwickert 

Ugh. I'll wait for the openmpi maintainers to add Provides: openmpi-devel (or provide a good excuse not to). Thanks for the review!


New Package CVS Request
=======================
Package Name: towhee
Short Description: A Monte Carlo molecular simulation code
Owners: jussilehtola
Branches: F-10 F-11 EL-5
InitialCC:

CVS done.

towhee-6.2.3-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/towhee-6.2.3-5.fc10

towhee-6.2.3-5.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/towhee-6.2.3-5.fc11

towhee-6.2.3-5.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update towhee'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5540

towhee-6.2.3-5.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update towhee'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5624

towhee-6.2.3-5.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

towhee-6.2.3-5.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.