Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=464424 Dominik 'Rathann' Mierzejewski <rpm@xxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Alias|GROMACS | --- Comment #9 from Dominik 'Rathann' Mierzejewski <rpm@xxxxxxxxxxxxxx> 2008-09-30 19:09:24 EDT --- (In reply to comment #8) > (In reply to comment #7) > > Full review below. OK'd items omitted. > > > > - MUST: rpmlint must be run on every package. The output should be posted in > > the review. > > NEEDSFIX > > Fixed. Now rpmlint output is: > > gromacs.x86_64: W: no-documentation > gromacs-bash.x86_64: W: no-documentation > gromacs-bash.x86_64: W: non-conffile-in-etc /etc/bash_completion.d/gromacs Mark as %config, please, and use %{_sysconfdir} instead of /etc. > gromacs-devel.x86_64: W: no-documentation > gromacs-libs.x86_64: W: no-documentation > gromacs-mpi.x86_64: W: no-documentation > gromacs-mpi-devel.x86_64: W: no-documentation > gromacs-mpi-libs.x86_64: W: no-documentation > gromacs-mpi-libs.x86_64: E: postun-without-ldconfig > /usr/lib64/libmd_mpi_d.so.4.0.0 > gromacs-mpi-libs.x86_64: E: postun-without-ldconfig > /usr/lib64/libmd_mpi.so.4.0.0 > gromacs-mpi-libs.x86_64: E: postun-without-ldconfig > /usr/lib64/libgmx_mpi.so.4.0.0 > gromacs-mpi-libs.x86_64: E: postun-without-ldconfig > /usr/lib64/libgmx_mpi_d.so.4.0.0 > gromacs-mpi-libs.x86_64: E: non-empty-%postun /sbin/ldconfig > gromacs-zsh.x86_64: W: no-documentation > 11 packages and 1 specfiles checked; 5 errors, 9 warnings. > > gromacs-mpi-libs *does* run ldconfig in post and postun. > Is this a bug in rpmbuild / rpmlint?? Could be, but if you separate them with an empty line it stops complaining. Also please remove all ####################################### such # Files section and such lines. Do they serve any useful purpose? There's still some trailing whitespace, please get rid of it. > > - MUST: The package must meet the Packaging Guidelines. > > NEEDSFIX [...] > > autoreconf > > > > Is it necessary? Calling autoreconf makes the build fail on rawhide/i386. > > If you remove that, remove BR: autoconf/automake, too. > > Yes, since the configure script distributed with GROMACS is so old that it > uses rpath. Works fine on F9 and RHEL5. You still need to make it build on F-10. There are other ways of avoiding rpaths that don't involve re-running autoconf. See https://fedoraproject.org/wiki/Packaging/Guidelines#Removing_Rpath. In fact, adding those two sed lines mentioned there before each make call in %build seems to solve the problem without rebuilding configure. If you insist on rebuilding it, then at least add BR: libtool and run "autoreconf -f -i -I .". That solves the problem as well. Of course, I prefer the solution which doesn't involve running autoreconf. One more thing: error: %patch without corresponding "Patch:" tag Use %patch0. New rpm is more picky. [...] > Made packages gromacs-bash, -zsh and -csh. I still think bash-completion-gromacs is a better name for the package, but I won't insist on it. There is another problem, however, with the -common package. %{_bindir}/GMXRC.csh %{_bindir}/GMXRC.zsh These scripts drag /bin/csh and /bin/zsh dependencies into -common. If (t)csh/zsh are not necessary to run gromacs, then please put the scripts in -csh and -zsh packages and update their summaries/descriptions. %{_datadir}/gromacs/tutor/gmxdemo/demo %{_datadir}/gromacs/tutor/gmxdemo/demo_d These two scripts drag /bin/csh dependency into -common as well. If they aren't necessary to run gromacs, the please remove the #!/bin/csh lines from them. [...] > > Please ask upstream to add appropriate license headers to these files. > > Filed upstream bug, http://bugzilla.gromacs.org/show_bug.cgi?id=217 . Thanks. > Disabling assembly hurt the speed of GROMACS *a lot*. People would probably > still end up compiling locally GROMACS if the instructions were disabled. > > Also, I think GROMACS handles this automatically: when I run it on an x86_64 > it reports > > Configuring nonbonded kernels... > Testing x86_64 SSE support... present. > > so I think there should be no problems. OK. If you say there's runtime CPU capabilities detection and that it will run on a machine without SSE and 3DNow! then I'll take your word for it. I can't find any information on that on GROMACS website though, so I'd feel more comfortable if you could confirm it with upstream. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review