Spec URL: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec SRPM URL: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.rc2.el5.src.rpm Description: GROMACS is a versatile and extremely well optimized package to perform molecular dynamics computer simulations and subsequent trajectory analysis. It is developed for biomolecules like proteins, but the extremely high performance means it is used also in several other field like polymer chemistry and solid state physics. This is my first package for Fedora, and I need a sponsor. I have done packaging of scientific software for RH/Fedora for some years now at the University of Helsinki, and would like to contribute to Fedora.
Oh, nice to see someone pick up what I didn't finish. I see you haven't used my specfile (see bug 249831), but that's OK. A few comments after a cursory look: BuildRequires: fftw, fftw-devel, gsl, gsl-devel, libX11, libX11-devel, automake, autoconf, openmpi, openmpi-devel, libxml2, libxml2-devel, prelink I'd prefer it if you put each buildrequire in a separate line and sort them alphabetically. It makes it easier to read and it makes diffs smaller when you change BRs. And I think about half of these are redundant, so that leaves us with: BuildRequires: autoconf BuildRequires: automake BuildRequires: fftw-devel BuildRequires: gsl-devel BuildRequires: libX11-devel BuildRequires: libxml2-devel BuildRequires: openmpi-devel Why did you put prelink here? %package share Summary: GROMACS shared data and documentation I think that should be named -common, not -share, but it's a matter of preference. #BuildArch: noarch #BuildArch: %_target_cpu Please drop these. That feature of rpm is present only in rawhide and it hasn't been decided if we're going to allow using it, because koji can't handle it yet. aclocal autoheader automake autoconf Try replacing that with a simple autoreconf Also, all ./configure and make (but not make install) calls in %install should be moved to %build. Could you explain why you put them in %install? I'll write up a full review after you've addressed the above. Don't forget to post the output of rpmlint run on your packages. I can sponsor you, but you'll have to do at least two package reviews (apart from making this package pass my review, of course).
Oh, I had just looked in the requests and old packages, I hadn't noticed that you had tried making an RPM before. I cleaned up the BuildRequires; it's true that they were a bit redundant. Prelink is needed since I have to remove executable stacks from libraries. I changed -share to -common as suggested. As I wrote now in the spec file the configures are done in the %install phase, since in order to get the {single,double}{,mpi} binaries you need to redo the configure and install phase 4 times. The beginning of the %install phase erases %buildroot. rpmlint output at http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.lint The zero-length makefile is the only "real" problem; maybe we need to find a workaround. The makefile for compiling user-made analysis software is generated on the fly by the build process. The other warnings are about missing documentation (which is in gromacs-share) and about devel-files in non-devel packages, which are runtime libraries needed anyway in the programs. Also, you might want to have a look at https://bugzilla.redhat.com/show_bug.cgi?id=464432 a package of Octopus which I also just made.
(In reply to comment #2) > Oh, I had just looked in the requests and old packages, I hadn't noticed that > you had tried making an RPM before. > > I cleaned up the BuildRequires; it's true that they were a bit redundant. > > Prelink is needed since I have to remove executable stacks from libraries. That's a major hack. Does it even work after you do that? It's better to fix the sources instead. I'd prefer it if you identified the problem at its source instead of papering over it. It's probably in some assembly code that doesn't define the .note.GNU-stack section. There are a lot of patches on the web to remove executable stack requirements for various software (xvidcore, for example). You might want to consult those. > I changed -share to -common as suggested. > > As I wrote now in the spec file the configures are done in the %install phase, > since in order to get the {single,double}{,mpi} binaries you need to redo the > configure and install phase 4 times. The beginning of the %install phase erases > %buildroot. No, you must keep the build process in %build. If you need several different configurations, you can create subdirs in builddir and run configure with different options and make there (it's called out-of-tree builds if you're not familiar). > rpmlint output at http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.lint > > The zero-length makefile is the only "real" problem; maybe we need to find a > workaround. The makefile for compiling user-made analysis software is generated > on the fly by the build process. The other warnings are about missing > documentation (which is in gromacs-share) and about devel-files in non-devel > packages, which are runtime libraries needed anyway in the programs. You are supposed to paste the rpmlint output in bugzilla, not just link to it. Why are the .so files needed in the main package? This can be easily fixed (run chmod in %prep on that file): romacs-debuginfo.x86_64: W: spurious-executable-perm /usr/src/debug/gromacs-4.0_rc2/src/tools/gmx_xpm2ps.c Please post the current specfile (with the fixes you mentioned already applied and with release increased by one). Also, please mention these fixes in the changelog of the package.
(In reply to comment #3) > > Prelink is needed since I have to remove executable stacks from libraries. > > That's a major hack. Does it even work after you do that? It's better to fix > the sources instead. I'd prefer it if you identified the problem at its source > instead of papering over it. It's probably in some assembly code that doesn't > define the .note.GNU-stack section. There are a lot of patches on the web to > remove executable stack requirements for various software (xvidcore, for > example). You might want to consult those. Yes, gromacs works after the execstack hack. Anyway, I changed the spec file to use the -Wa,--noexecstack option instead of using execstack, and filed a bug upstream. My hunch is that the .note.GNU-stack hasn't been added since the developers have had trouble putting in comments that work with GNU, Intel and Microsoft assembler. (There are a couple of hundred assembler core files that would need to be patched, better let upstream handle it.) > No, you must keep the build process in %build. If you need several different > configurations, you can create subdirs in builddir and run configure with > different options and make there (it's called out-of-tree builds if you're not > familiar). Right, thanks for the tip. Fixed. > You are supposed to paste the rpmlint output in bugzilla, not just link to it. OK, here it is: gromacs.x86_64: W: no-documentation gromacs.x86_64: E: no-binary gromacs-common.x86_64: E: zero-length /usr/share/gromacs/template/Makefile.x86_64-redhat-linux-gnu_double gromacs-common.x86_64: E: zero-length /usr/share/gromacs/template/Makefile.x86_64-redhat-linux-gnu gromacs-common.x86_64: W: devel-file-in-non-devel-package /usr/share/gromacs/template/template.c gromacs-devel.x86_64: W: no-documentation gromacs-double.x86_64: W: no-documentation gromacs-double.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmx_d.so gromacs-double.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmxana_d.so gromacs-double.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libmd_d.so gromacs-mpi.x86_64: W: no-documentation gromacs-mpi-double.x86_64: W: no-documentation gromacs-mpi-double.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmx_mpi_d.so gromacs-mpi-double.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libmd_mpi_d.so gromacs-mpi-single.x86_64: W: no-documentation gromacs-mpi-single.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libmd_mpi.so gromacs-mpi-single.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmx_mpi.so gromacs-single.x86_64: W: no-documentation gromacs-single.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libmd.so gromacs-single.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmxana.so gromacs-single.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libgmx.so SPECS/gromacs.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: line 1) 9 packages and 1 specfiles checked; 3 errors, 19 warnings. > Why are the .so files needed in the main package? Well, they *could* be separated to their own packages. However there are four sets of libraries, which go hand in hand with the executables: single precision, double precision, single precision w/ MPI and double precision w/ MPI. The MPI packages contain 1 binary and 2 libraries (.so and .la w/ 4 symlinks), and the "normal" packages 88 binaries and 3 libraries (.so and .la w/ 6 symlinks). If the libraries are separated, we'd end up with four more packages which would be installed as requirements for the correspondent binaries in any case, which I don't find very logical. > Please post the current specfile (with the fixes you mentioned already applied > and with release increased by one). Also, please mention these fixes in the > changelog of the package. Done. Current release is 2. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-2.rc2.el5.src.rpm
Created attachment 317904 [details] Gromacs spec 4.0-2.rc2
New release: * Mon Sep 29 2008 Jussi Lehtola - 4.0-3.rc2 - Move .so files to -devel package. - Remove .la files. rpmlint output: gromacs.x86_64: W: no-documentation gromacs.x86_64: E: no-binary gromacs-common.x86_64: E: zero-length /usr/share/gromacs/template/Makefile.x86_64-redhat-linux-gnu_double gromacs-common.x86_64: E: zero-length /usr/share/gromacs/template/Makefile.x86_64-redhat-linux-gnu gromacs-common.x86_64: W: devel-file-in-non-devel-package /usr/share/gromacs/template/template.c gromacs-devel.x86_64: W: no-documentation gromacs-double.x86_64: W: no-documentation gromacs-mpi.x86_64: W: no-documentation gromacs-mpi-double.x86_64: W: no-documentation gromacs-mpi-single.x86_64: W: no-documentation gromacs-single.x86_64: W: no-documentation SPECS/gromacs.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: line 1) 9 packages and 1 specfiles checked; 3 errors, 9 warnings. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-3.rc2.el5.src.rpm
Full review below. OK'd items omitted. - MUST: rpmlint must be run on every package. The output should be posted in the review. NEEDSFIX $ rpmlint /var/lib/mock//fedora-rawhide-i386/result gromacs-mpi.i386: W: no-documentation gromacs.src: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: line 1) gromacs.i386: W: no-documentation gromacs.i386: E: no-binary gromacs-double.i386: W: no-documentation gromacs-mpi-double.i386: W: no-documentation gromacs-common.i386: E: zero-length /usr/share/gromacs/template/Makefile.i386-redhat-linux-gnu_double gromacs-common.i386: W: devel-file-in-non-devel-package /usr/share/gromacs/template/template.c gromacs-common.i386: E: zero-length /usr/share/gromacs/template/Makefile.i386-redhat-linux-gnu gromacs-single.i386: W: no-documentation gromacs-devel.i386: W: no-documentation gromacs-mpi-single.i386: W: no-documentation 10 packages and 0 specfiles checked; 3 errors, 9 warnings. Please fix the spaces-and-tabs warning and the zero-length files. - MUST: The package must meet the Packaging Guidelines. NEEDSFIX Please rename the specfile to have the same name as the main package, i.e. gromacs.spec. Either make four devel subpackages, one for each set of libraries or group them together, for example single+double -> gromacs mpi single+double -> gromacs-mpi and then only two -devel packages You should also put libraries into a separate package to allow for multilib installs. autoreconf Is it necessary? Calling autoreconf makes the build fail on rawhide/i386. If you remove that, remove BR: autoconf/automake, too. ../configure --host=%{_host} --build=%{_build} \ --target=%{_target_platform} \ --program-prefix=%{?_program_prefix} \ --prefix=%{_prefix} \ --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} \ --sbindir=%{_sbindir} \ --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} \ --includedir=%{_includedir} \ --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} \ --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} \ --mandir=%{_mandir} \ --infodir=%{_infodir} \ --disable-rpath --enable-shared \ --disable-static --enable-float \ --with-gsl --with-x Maybe add --enable-pthreads? Or a separate pthread-enabled version? Not a blocker, just FYI. You must (if possible) make gromacs use existing Fedora packages (lapack, blas) instead of internal copies. It has --with-external-blas and --with-external-lapack options in configure. See http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries # Compress manpages cd %{buildroot}/%{_mandir}/man1 for i in *.1; do gzip $i done No need, this is done automatically by rpmbuild. # Remove .la files \rm %{buildroot}/%{_libdir}/*.la Stray backslash? %_includedir/gromacs -> %{_includedir}/gromacs %files common ... %doc AUTHORS COPYING INSTALL README gromacs-4.0.pdf completion.bash completion.zsh completion.csh. Trailing whitespace, please remove. Also, please put %doc files right after %defattr. It is rather pointless to include the INSTALL file. completion.bash could be put in %{_sysconfdir}/bash_completion.d/ (needs Requires: bash-completion then, maybe a separate package bash-completion-gromacs?). Check for similar possibilities for other shells. This would help loosen the dependencies on various shells. As it is, -common depends on all of them: Requires: /bin/bash /bin/csh /bin/sh /bin/zsh /usr/bin/perl This is not reasonable. At least the csh and zsh dependencies must be removed. %files mpi Empty? - MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . NEEDSFIX Some files (especially src/gmxlib/gmx_{lapack,blas}/*) have no licensing information, although they look like private copies of lapack and blas, so please verify that. If so, their license is BSD, which is GPLv2+ compatible. Other files with no licensing information: ./src/kernel/gmxcpp.h: *No copyright* UNKNOWN ./src/mdlib/._ebin.c: *No copyright* UNKNOWN ./src/mdlib/perf_est.c: *No copyright* UNKNOWN ./src/mdlib/wall.c: *No copyright* UNKNOWN ./src/mdlib/shellfc.c: *No copyright* UNKNOWN ./src/mdlib/gmx_wallcycle.c: *No copyright* UNKNOWN ./src/gmxlib/nonbonded/nb_free_energy.h: *No copyright* UNKNOWN ./src/gmxlib/nonbonded/nb_kernel_ia64_single/ia64_cpuid.h: *No copyright* UNKNOWN ./src/gmxlib/nonbonded/nb_generic.h: *No copyright* UNKNOWN ./src/gmxlib/nonbonded/nb_kernel_ia64_double/ia64_cpuid.h: *No copyright* UNKNOWN ./src/gmxlib/topsort.c: *No copyright* UNKNOWN ./src/tools/correl.c: *No copyright* UNKNOWN ./src/tools/correl.h: *No copyright* UNKNOWN ./include/mpelogging.h: *No copyright* UNKNOWN ./include/gmx_ana.h: *No copyright* UNKNOWN ./include/gmx_arpack.h: UNKNOWN ./include/shellfc.h: *No copyright* UNKNOWN ./include/perf_est.h: *No copyright* UNKNOWN ./include/types/qmmmrec.h: *No copyright* UNKNOWN ./include/types/ns.h: *No copyright* UNKNOWN ./include/topsort.h: *No copyright* UNKNOWN ./include/gmx_wallcycle.h: *No copyright* UNKNOWN ./include/qmmm.h: *No copyright* UNKNOWN ./include/gmx_lapack.h: *No copyright* UNKNOWN ./include/gmx_blas.h: *No copyright* UNKNOWN ./include/gmx_random.h: *No copyright* UNKNOWN Please ask upstream to add appropriate license headers to these files. - MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. NEEDSFIX Bad source URL: Source0:<------>ftp://ftp.gromacs.org/pub/gromacs/source/gromacs-4.0_rc2.tar.gz gromacs/source -> beta - 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. This is described in detail in the desktop files section of the Packaging Guidelines . If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. NEEDSFIX(?) I see libX11 in rpm-generated Requires:. Does this package display a GUI? If so, it needs an appropriate desktop file and desktop-file-install call (BR: desktop-file-utils). SHOULD Items: - SHOULD: The reviewer should test that the package builds in mock. See MockTricks for details on how to do this. Doesn't build in mock/devel/i386 due to autoreconf failure. Builds fine in koji/dist-f10 (with autoreconf invocation removed). http://koji.fedoraproject.org/koji/taskinfo?taskID=851228 - SHOULD: The package should compile and build into binary rpms on all supported architectures. - SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. I haven't actually tested it, but I think you must use --disable-ia32-* for i386 builds, otherwise gromacs will crash with SIGILL when run on a CPU without 3dnow or sse instructions. You can also build separate versions of gromacs libraries with these enabled and put them in %{_libdir}/3dnow and %{_libdir}/sse, respectively. The linker will then select the best version automatically (see atlas package for inspiration). Similarly --disable-ppc-altivec for ppc builds (not all ppc have altivec), but you can build separate altivec-enabled libraries and put them in %{_libdir}/altivec/
(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 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?? > - MUST: The package must meet the Packaging Guidelines. > NEEDSFIX > > Please rename the specfile to have the same name as the main package, i.e. > gromacs.spec. > > Either make four devel subpackages, one for each set of libraries > or group them together, for example > single+double -> gromacs > mpi single+double -> gromacs-mpi > and then only two -devel packages > You should also put libraries into a separate package to allow for multilib > installs. OK, done. > 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. > Maybe add --enable-pthreads? Or a separate pthread-enabled version? Not a > blocker, just FYI. GROMACS doesn't have thread support yet, since the performance is so bad on NUMA systems, the speedup is about 75%. MPI results in far better results: the speedups are >99%. > completion.bash could be put in %{_sysconfdir}/bash_completion.d/ (needs > Requires: bash-completion then, maybe a separate package > bash-completion-gromacs?). > Check for similar possibilities for other shells. This would help loosen the > dependencies on various shells. As it is, -common depends on all of them: > Requires: /bin/bash /bin/csh /bin/sh /bin/zsh /usr/bin/perl > This is not reasonable. At least the csh and zsh dependencies must be removed. Made packages gromacs-bash, -zsh and -csh. > - MUST: The package must be licensed with a Fedora approved license and meet > the Licensing Guidelines . > NEEDSFIX > > Some files (especially src/gmxlib/gmx_{lapack,blas}/*) have no licensing > information, > although they look like private copies of lapack and blas, so please verify > that. > If so, their license is BSD, which is GPLv2+ compatible. (clip) > Please ask upstream to add appropriate license headers to these files. Filed upstream bug, http://bugzilla.gromacs.org/show_bug.cgi?id=217 . The files are C-versions of BLAS & LAPACK made with f2c. RPMs are now built with distribution libraries instead of the ones distributed with GROMACS. > - 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. This is described in detail in the desktop files section of > the Packaging Guidelines . If you feel that your packaged GUI application does > not need a .desktop file, you must put a comment in the spec file with your > explanation. > NEEDSFIX(?) > I see libX11 in rpm-generated Requires:. Does this package display a GUI? If > so, it needs an appropriate desktop file and desktop-file-install call (BR: > desktop-file-utils). The only program which requires X is ngmx, which has no desktop interface - it must be run from the command line with file parameters. > SHOULD Items: > > - SHOULD: The reviewer should test that the package builds in mock. See > MockTricks for details on how to do this. > > Doesn't build in mock/devel/i386 due to autoreconf failure. > Builds fine in koji/dist-f10 (with autoreconf invocation removed). > http://koji.fedoraproject.org/koji/taskinfo?taskID=851228 If you run rpmlint on these you'll fine rpaths in the libraries. > - SHOULD: The package should compile and build into binary rpms on all > supported architectures. > - SHOULD: The reviewer should test that the package functions as described. A > package should not segfault instead of running, for example. > > I haven't actually tested it, but I think you must use --disable-ia32-* for > i386 builds, otherwise gromacs will crash with SIGILL when run on a CPU without > 3dnow or sse instructions. You can also build separate versions of gromacs > libraries with these enabled and put them in %{_libdir}/3dnow and > %{_libdir}/sse, respectively. The linker will then select the best version > automatically (see atlas package for inspiration). > Similarly --disable-ppc-altivec for ppc builds (not all ppc have altivec), but > you can build separate altivec-enabled libraries and put them in > %{_libdir}/altivec/ 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. SPEC: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec SRPM: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-4.rc2.fc9.src.rpm
(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.
(In reply to comment #9) > > 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. I tried this before, but it didn't work. Seems to work now. Good. Still couldn't get rid of the ldconfig errors. gromacs.x86_64: W: no-documentation gromacs-bash.x86_64: W: no-documentation gromacs-bash.x86_64: W: conffile-without-noreplace-flag /etc/bash_completion.d/gromacs 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-tutor.x86_64: W: no-documentation gromacs-zsh.x86_64: W: no-documentation 12 packages and 1 specfiles checked; 5 errors, 10 warnings. > > 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. I can't find any packages beginning with bash-completion in Fedora 9 repos. IMHO it's better to keep the same base name. > %{_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. Branched to -tutor package. > 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. Made a question about it to the mailing list. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-5.rc2.fc9.src.rpm
Got a reply on the runtime CPU capabilities detection: "Yes it does. It should work, but e.g. debuggers tend to dislike illegal instructions (when e.g. testing for 3DNow on a pentium)." Should I make additional debug packages that have all assembly instructions disabled? This would mean 6 additional packages: gromacs-debug, gromacs-debug-libs, gromacs-debug-devel, gromacs-debug-mpi, gromacs-debug-mpi-libs, gromacs-debug-mpi-devel ...
(In reply to comment #11) > Got a reply on the runtime CPU capabilities detection: > > "Yes it does. It should work, but e.g. debuggers tend to dislike illegal > instructions (when e.g. testing for 3DNow on a pentium)." > > Should I make additional debug packages that have all assembly instructions > disabled? This would mean 6 additional packages: gromacs-debug, > gromacs-debug-libs, gromacs-debug-devel, gromacs-debug-mpi, > gromacs-debug-mpi-libs, gromacs-debug-mpi-devel ... Well, that's up to you. If you think most users of your package will be using it on machines with 3DNow and/or SSE, then I wouldn't bother.
Some final nitpicking: rpmlint: gromacs-mpi-libs.x86_64: E: non-empty-%postun /sbin/ldconfig Please remove the following line # Clean buildroot because it is between %postun mpi-libs -p /sbin/ldconfig and %clean which makes rpmbuild treat it as part of the %postun scriptlet. BuildRequires: openmpi-devel FYI: Alternatives support in openmpi will probably be gone in next release (it's already gone from lam), so you might need something like this in the future: BuildRequires: environment-modules and . /etc/profile.d/modules.sh module load %{_libdir}/openmpi/*/openmpi.module before ./configure with mpi %package zsh Summary: Zsh completion for GROMACS It's not just completion now, is it? :) Same for %package csh. %package devel Requires: gromacs = %{version}-%{release} %package mpi-devel Requires: gromacs-mpi = %{version}-%{release} Do the -devel packages really require the binaries? Or would it be sufficient to require the -libs subpackages. export CFLAGS="%optflags -Wa,--noexecstack" Could this CFLAGS addition be limited only to files that need it? That'd require some Makefile.in patching, of course. However, none of the above are blockers, so feel free to fix them after the package is imported. Good work. APPROVED Based on this package and your reviews of other packages, I'm sponsoring you. Please request "packager" group membership in the Fedora Account System and I'll approve your request. Welcome aboard!
I tried to compile the latest gromacs-4.0-5.rc2.fc9.src.rpm on my i686 machine but it failed although compiling of the source code (gromacs-4.0-5.rc2) by ./comfigure and make was succesful. Could you also provide a working src.rpm for ia32?
(In reply to comment #14) > I tried to compile the latest gromacs-4.0-5.rc2.fc9.src.rpm on my i686 machine > but it failed although compiling of the source code (gromacs-4.0-5.rc2) by > ./comfigure and make was succesful. The error messages, please. What distribution are you running? > Could you also provide a working src.rpm for ia32? I'll have to wait until I can use the Fedora build system to see which architectures the SRPM builds under and make the necessary fixes to the spec file. (Including ExcludeArch for those architectures I can't get GROMACS to compile on.)
(In reply to comment #13) > BuildRequires: openmpi-devel > > FYI: Alternatives support in openmpi will probably be gone in next release > (it's already gone from lam), so you might need something like this in the > future: > > BuildRequires: environment-modules > and > . /etc/profile.d/modules.sh > module load %{_libdir}/openmpi/*/openmpi.module > before ./configure with mpi OK. Do you have any idea how this works in RHEL5? The newest update includes the mpi-selector tool, which puts the MPI bin dir into the path. > export CFLAGS="%optflags -Wa,--noexecstack" > > Could this CFLAGS addition be limited only to files that need it? That'd > require some Makefile.in patching, of course. Well, that would be of course nicer, but the flag only operates on assembly files anyways :) > However, none of the above are blockers, so feel free to fix them after the > package is imported. Good work. > > APPROVED Thanks for bearing with me. > Based on this package and your reviews of other packages, I'm sponsoring you. > Please request "packager" group membership in the Fedora Account System and > I'll approve your request. Welcome aboard! Done. (Spec and SRPMS still in the same place.)
Some notes: * EVR - At least EVR (Epoch-Version-Release) needs fixing: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages * configure - Doesn't the following work? ----------------------------------------------------------- # Single precision mkdir single cd single ln -sf ../configure %configure \ --disable-rpath --enable-shared \ --disable-static --enable-float \ ....... ----------------------------------------------------------- * Namespace in %_bindir, generic names - Your srpm installs many exectables under %_bindir, which is not desired. Also some files has too generic names (like luck, wheel, highway, and so on), which is rather a blocker. Please move (almost all) executables under %_bindir to %_libexecdir/%name, for example and add executables under %_bindir which are _really_ needed. * Duplicate files ----------------------------------------------------------- $ rpm -qlp *rpm | sort | uniq -d /usr/bin/GMXRC /usr/bin/GMXRC.bash /usr/bin/GMXRC.csh /usr/bin/GMXRC.zsh /usr/bin/demux.pl ------------------------------------------------------------ - Fix these.
(In reply to comment #17) > * Namespace in %_bindir, generic names > - Your srpm installs many exectables under %_bindir, which is not desired. > Also some files has too generic names (like luck, wheel, highway, and so > on), > which is rather a blocker. > Please move (almost all) executables under %_bindir to %_libexecdir/%name, > for > example and add executables under %_bindir which are _really_ needed. - Or rename such files so that it makes sure that the names of files are peculiar to this rpm.
I was using the latest updated fedora 2.6.26.3-29.fc9.i686. The output of rpmbuild -bb gromacs.spec >output.txt 2>&1 is available at http://bioinf.uta.fi/~java/gromacs/output.txt I have not yet tested to compile mpi version from the source code. Here are the last lines of output: + mkdir mpi-single + cd mpi-single + ../configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-rpath --enable-shared --disable-static --enable-float --with-external-blas --with-external-lapack --with-gsl --with-x --enable-mpi --program-suffix=_mpi checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking for i686-pc-linux-gnu-cc... no checking for i686-pc-linux-gnu-icc... no checking for i686-pc-linux-gnu-xlc... no checking for i686-pc-linux-gnu-gcc... no checking for cc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking dependency style of cc... gcc3 checking for mpxlc... no checking for mpicc... mpicc checking whether the MPI cc command works... yes checking for catamount... no checking how to run the C preprocessor... mpicc -E checking whether mpicc accepts -O3... yes checking whether mpicc accepts -malign-double... yes checking whether mpicc accepts -funroll-all-loops... yes ****************************************** * Using CFLAGS from environment variable * ****************************************** checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for int... yes checking size of int... configure: error: cannot compute sizeof (int) See `config.log' for more details. error: Bad exit status from /var/tmp/rpm-tmp.28652 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.28652 (%build)
(In reply to comment #16) > (In reply to comment #13) > > BuildRequires: openmpi-devel > > > > FYI: Alternatives support in openmpi will probably be gone in next release > > (it's already gone from lam), so you might need something like this in the > > future: > > > > BuildRequires: environment-modules > > and > > . /etc/profile.d/modules.sh > > module load %{_libdir}/openmpi/*/openmpi.module > > before ./configure with mpi > > OK. > > Do you have any idea how this works in RHEL5? The newest update includes the > mpi-selector tool, which puts the MPI bin dir into the path. Yeah, that's a pain, but RHEL5.2 seems to have its own mechanism that works in similar fashion to environment-modules.
(In reply to comment #17) > Some notes: > > * EVR > - At least EVR (Epoch-Version-Release) needs fixing: Right, I seem to have missed that. Thanks for noticing. > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > * configure > - Doesn't the following work? > ----------------------------------------------------------- > # Single precision > mkdir single > cd single > ln -sf ../configure > %configure \ > --disable-rpath --enable-shared \ > --disable-static --enable-float \ > ....... > ----------------------------------------------------------- Thanks, I was thinking about how to avoid the long versions and this should work. > * Namespace in %_bindir, generic names > - Your srpm installs many exectables under %_bindir, which is not desired. > Also some files has too generic names (like luck, wheel, highway, and so > on), > which is rather a blocker. > Please move (almost all) executables under %_bindir to %_libexecdir/%name, > for > example and add executables under %_bindir which are _really_ needed. You're right. I guess I have to withdraw the approval until we resolve this. Thanks for catching it. > * Duplicate files > ----------------------------------------------------------- > $ rpm -qlp *rpm | sort | uniq -d > /usr/bin/GMXRC > /usr/bin/GMXRC.bash > /usr/bin/GMXRC.csh > /usr/bin/GMXRC.zsh > /usr/bin/demux.pl > ------------------------------------------------------------ > - Fix these. Ehhh, this happened after I asked Jussi to move the GMXRC.* scripts to subpackages and forgot that he had %{_bindir}/* in the main package. rpmlint should catch such things.
(In reply to comment #19) > I was using the latest updated fedora 2.6.26.3-29.fc9.i686. > > The output of rpmbuild -bb gromacs.spec >output.txt 2>&1 > is available at http://bioinf.uta.fi/~java/gromacs/output.txt > > I have not yet tested to compile mpi version from the source code. > > Here are the last lines of output: [...] > checking size of int... configure: error: cannot compute sizeof (int) > See `config.log' for more details. > error: Bad exit status from /var/tmp/rpm-tmp.28652 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.28652 (%build) Please post the failed test output from config.log. It builds fine in mock/devel-i386 and mock/f9-x86_64.
Some more notes: * Directory ownership issue - Please make it sure that directories which are created when installing a rpm are correctly owned by the rpm (or rpms which the rpms depends on). The following may be rather difficult to find out, but for example: ---------------------------------------------------- # rpm -i gromacs-libs-4.0-6.rc2.fc10.i386.rpm gromacs-devel-4.0-6.rc2.fc10.i386.rpm # env LANG=C rpm -qf /usr/share/gromacs/template/ gromacs-devel-4.0-6.rc2.fc10.i386 # env LANG=C rpm -qf /usr/share/gromacs/ file /usr/share/gromacs is not owned by any package ---------------------------------------------------- Here gromacs-devel Requires gromacs-libs, however neither of -devel, -libs packages Requires -common. So the above install succeeds. However the directory %{_datadir}/gromacs is owned by -common package so with this install %{_datadir}/gromacs is not owned by any packages, which is not right. Here -devel package must require -common directly or indirectly. Also, please check the ownership of %{_datadir}/gromacs/template/ or so. * ldconfig - Why does -devel package call /sbin/ldconfig? * Summary ---------------------------------------------------- %package devel Summary: Header files and static libraries for GROMACS ---------------------------------------------------- - What does "static" libraries mean here? * Timestamps - When using "install" or "cp" commands add "-p" option to keep timestamps on installed files. Also try ---------------------------------------------------- make DESTDIR=%{buildroot} INSTALL="install -p" install ---------------------------------------------------- This method usually works for Makefiles generated by recent autotools. * Using %_builddir ----------------------------------------------------- # Install manual install -c -m 644 %{SOURCE1} %{_builddir}/gromacs-4.0_rc2/ ----------------------------------------------------- - "install -cpm 0644 %{SOURCE1} ." is sufficient.
(In reply to comment #22) > > Please post the failed test output from config.log. It builds fine in > mock/devel-i386 and mock/f9-x86_64. Ok. Something is probably wrong on my PC configuration. Here are the config.log files: http://bioinf.uta.fi/~java/gromacs/single/config.log http://bioinf.uta.fi/~java/gromacs/mpi-single/config.log http://bioinf.uta.fi/~java/gromacs/double/config.log
(In reply to comment #24) > (In reply to comment #22) > > > > Please post the failed test output from config.log. It builds fine in > > mock/devel-i386 and mock/f9-x86_64. > > Ok. Something is probably wrong on my PC configuration. > Here are the config.log files: > > http://bioinf.uta.fi/~java/gromacs/mpi-single/config.log ./conftest: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory Looks like your openmpi is not installed properly.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #22) > > > > > > Please post the failed test output from config.log. It builds fine in > > > mock/devel-i386 and mock/f9-x86_64. > > > > Ok. Something is probably wrong on my PC configuration. > > Here are the config.log files: > > > > http://bioinf.uta.fi/~java/gromacs/mpi-single/config.log > > ./conftest: error while loading shared libraries: libmpi.so.0: cannot open > shared object file: No such file or directory > > Looks like your openmpi is not installed properly. Thanks! You were right. I removed openmpi-1.2.4-2.fc9.i386 and openmpi-libs-1.2.4-2.fc9.i386 packages. I had to use --noscripts option because of error: %preun(openmpi-1.2.4-2.fc9.i386) scriptlet failed, exit status 2 (bug?) Then I reinstall then by yum install openmpi openmpi-libs and now the gromacs builds properly.
(In reply to comment #17) > Some notes: > > * EVR > - At least EVR (Epoch-Version-Release) needs fixing: > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages Fixed. > * configure > - Doesn't the following work? Duh, much simpler. Thanks. > * Namespace in %_bindir, generic names > - Your srpm installs many exectables under %_bindir, which is not desired. > Also some files has too generic names (like luck, wheel, highway, and so > on), > which is rather a blocker. > Please move (almost all) executables under %_bindir to %_libexecdir/%name, > for > example and add executables under %_bindir which are _really_ needed. The problem is that GROMACS has a big bunch of independent analysis tools that users need, all of which must be in the system path. I renamed highway, luck, sigeps and wheel to g_highway, g_luck, g_sigeps and g_wheel. I used autoreconf to regenerate the scripts. I don't have access to the buildsystem yet, so I can't check whether it works on F10. > * Duplicate files Thanks, fixed.
(In reply to comment #23) > Some more notes: > > * Directory ownership issue Thanks. > * ldconfig > - Why does -devel package call /sbin/ldconfig? It shouldn't. > * Summary > ---------------------------------------------------- > %package devel > Summary: Header files and static libraries for GROMACS > ---------------------------------------------------- > - What does "static" libraries mean here? Whoops, there are no more static libraries. Just .so files in the devel packages. > * Using %_builddir > ----------------------------------------------------- > # Install manual > install -c -m 644 %{SOURCE1} %{_builddir}/gromacs-4.0_rc2/ > ----------------------------------------------------- > - "install -cpm 0644 %{SOURCE1} ." is sufficient. Much simpler. Thanks for the tip. Spec file & SRPM available at http://theory.physics.helsinki.fi/~jzlehtol/rpms/
rpmlint output: gromacs.x86_64: W: no-documentation gromacs-bash.x86_64: W: no-documentation gromacs-bash.x86_64: W: conffile-without-noreplace-flag /etc/bash_completion.d/gromacs gromacs-csh.x86_64: W: summary-not-capitalized csh GROMACS support 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-tutor.x86_64: W: no-documentation gromacs-zsh.x86_64: W: no-documentation gromacs-zsh.x86_64: W: summary-not-capitalized zsh GROMACS support 12 packages and 1 specfiles checked; 0 errors, 12 warnings.
One more thing from me: ------------------------------ install -c -m 644 ... ------------------------------ - Use "install -c -p -m 644" to keep timestamps. For other things, if Dominik think this package can be approved I won't oppose it anymore.
(In reply to comment #30) > One more thing from me: > ------------------------------ > install -c -m 644 ... > ------------------------------ > - Use "install -c -p -m 644" to keep timestamps. Fixed. > For other things, if Dominik think this package can be approved I won't > oppose it anymore. Thanks a lot for your input. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.8.rc2.fc9.src.rpm
(In reply to comment #27) [...] > > * Namespace in %_bindir, generic names > > - Your srpm installs many exectables under %_bindir, which is not desired. > > Also some files has too generic names (like luck, wheel, highway, and so > > on), > > which is rather a blocker. > > Please move (almost all) executables under %_bindir to %_libexecdir/%name, > > for > > example and add executables under %_bindir which are _really_ needed. > > The problem is that GROMACS has a big bunch of independent analysis tools that > users need, all of which must be in the system path. > > I renamed highway, luck, sigeps and wheel to g_highway, g_luck, g_sigeps and > g_wheel. I used autoreconf to regenerate the scripts. gromacs-filenames.patch looks like an autotools update for the whole GROMACS. I can't find what it really does among the hundereds of similar changes. Please limit the patch to renaming the problematic binaries only. Also I think more binaries should get the g_ prefix, but I'll look through the list tomorrow.
(In reply to comment #32) > gromacs-filenames.patch looks like an autotools update for the whole GROMACS. > I can't find what it really does among the hundereds of similar changes. > Please limit the patch to renaming the problematic binaries only. Yes, but I really don't want to mess with machine generated makefiles to fix the file names, since I would probably have to do it all over again in the next release of Gromacs. I changed the spec to use autoreconf again and tested it against rawhide - works flawlessly. The new patch works on only the Makefile.am files. > Also I think more binaries should get the g_ prefix, but I'll look through the > list tomorrow. I thought about renaming the lot of them, but came to the conclusion that could disturb the users too much if they're used to the normal commands. Of course, there is the option to rename everything to start with g_ and provide an additional symlink package to make it possible to use the same commands to run GROMACS as elsewhere. Or yet another: put everything in %{_libexecdir}/%{name} and implement a module. This would mean we could drop the renaming altogether! What do you think?
(In reply to comment #33) > Or yet another: put everything in %{_libexecdir}/%{name} and implement a > module. This would mean we could drop the renaming altogether! I prefer this way if possible.
Module system implemented after a lot of work. Please test on other architectures than x86_64. Have a look at http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.10.rc3.fc9.src.rpm If anyone knows how to build under mock for RHEL let me know. It should be quite simple, since one just needs to resource the shell profile somehow to make it refresh mpi variables. I'm also working on a gromacs3 package.
OK, it was as easy as I thought, just had to source /etc/profile.d/mpi-selector.sh . Thanks to the module system gromacs 4 and gromacs 3 can be installed simultaneously. I have created packages of GROMACS 3.3.3 using the same spec file with little modification. Some people may still want to run the older release version. Please review gromacs3 at https://bugzilla.redhat.com/show_bug.cgi?id=465617 New gromacs specfile: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec SRPM: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.11.rc3.fc9.src.rpm
(In reply to comment #35) > Module system implemented after a lot of work. Please test on other > architectures than x86_64. It seems to build and install properly on my i386. > > Have a look at > > http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec > http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.10.rc3.fc9.src.rpm >
Fixed building for EPEL4. Couldn't get it to compile in mock under F9, however, it fails at the mpi compiler detection stage. As RHEL5.2, RHEL4.7 uses mpi-selector, so the same commands should work. Maybe this is just due to some binary incompatibility problem..? http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.12.rc3.fc9.src.rpm
Is it possible to add /usr/libexec/gromacs-4.0 directory to PATH somehow by rpm? For example by adding /etc/profile.d/gromacs4.sh file: export PATH=$PATH:/usr/libexec/gromacs-4.0
(In reply to comment #39) > Is it possible to add /usr/libexec/gromacs-4.0 directory to PATH somehow by > rpm? > > For example by adding /etc/profile.d/gromacs4.sh file: > > export PATH=$PATH:/usr/libexec/gromacs-4.0 I see you aren't familiar with the module system. (BTW, I'm a bit surprised how long it's taken for it to be used in Fedora since it's been standard on HPCs for years..) Type: $ module load gromacs-4.0 and the paths are automatically added. (PATH, LD_LIBRARY_PATH, MANPATH, GMXLIB and so on.) Then you can run GROMACS as normal. In fact, I'll rename the module as gromacs, which is a better choice: when 4.1 comes out the users wouldn't have to bother about changing their scripts. The module for GROMACS 3.x series is then gromacs3. Updated spec & srpm: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.13.rc3.fc9.src.rpm
(In reply to comment #40) > (In reply to comment #39) > I see you aren't familiar with the module system. (BTW, I'm a bit surprised how > long it's taken for it to be used in Fedora since it's been standard on HPCs > for years..) > > Type: > > $ module load gromacs-4.0 > Yes, I was not aware of the module system. Thanks!
Putting end user executables under /usr/libexec seems to be in contradiction of what libexec is for. Certainly this kind of thing should at least be discussed by the packaging committee before it is done in Fedora.
(In reply to comment #42) > Putting end user executables under /usr/libexec seems to be in contradiction of > what libexec is for. Certainly this kind of thing should at least be discussed > by the packaging committee before it is done in Fedora. Then where should they be placed..?
Got an OK to use %{_libexecdir}/%{name}-%{version} from the Packaging committee. Also, modified the package to load the module automatically. gromacs.x86_64: W: no-documentation gromacs-bash.x86_64: W: no-documentation gromacs-bash.x86_64: W: conffile-without-noreplace-flag /etc/bash_completion.d/gromacs4 gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/modulefiles/gromacs gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/profile.d/gromacs.csh gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/profile.d/gromacs.sh gromacs-csh.x86_64: W: summary-not-capitalized csh GROMACS support gromacs-devel.x86_64: W: no-documentation gromacs-devel.x86_64: E: only-non-binary-in-usr-lib gromacs-libs.x86_64: W: no-documentation gromacs-mpi.x86_64: W: no-documentation gromacs-mpi-devel.x86_64: W: no-documentation gromacs-mpi-devel.x86_64: E: only-non-binary-in-usr-lib gromacs-mpi-libs.x86_64: W: no-documentation gromacs-tutor.x86_64: W: no-documentation gromacs-zsh.x86_64: W: no-documentation gromacs-zsh.x86_64: W: summary-not-capitalized zsh GROMACS support 12 packages and 1 specfiles checked; 2 errors, 15 warnings. Please review. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.14.rc3.fc9.src.rpm
(In reply to comment #44) > Got an OK to use %{_libexecdir}/%{name}-%{version} from the Packaging > committee. Also, modified the package to load the module automatically. I read the discussion in fedora-packaging, but I haven't seen any conclusion yet.
(In reply to comment #45) > (In reply to comment #44) > > Got an OK to use %{_libexecdir}/%{name}-%{version} from the Packaging > > committee. Also, modified the package to load the module automatically. > > I read the discussion in fedora-packaging, but I haven't seen any conclusion > yet. Whoops, seems like I spoke too soon. The initial comments were positive. Sorry. Anyway, I changed the locations of the binaries to libdir/gromacs-version/bin. gromacs.x86_64: W: no-documentation gromacs-bash.x86_64: W: no-documentation gromacs-bash.x86_64: W: conffile-without-noreplace-flag /etc/bash_completion.d/gromacs4 gromacs-common.x86_64: E: only-non-binary-in-usr-lib gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/modulefiles/gromacs gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/profile.d/gromacs.csh gromacs-common.x86_64: W: conffile-without-noreplace-flag /etc/profile.d/gromacs.sh gromacs-csh.x86_64: W: summary-not-capitalized csh GROMACS support gromacs-csh.x86_64: E: only-non-binary-in-usr-lib gromacs-devel.x86_64: W: no-documentation gromacs-devel.x86_64: E: only-non-binary-in-usr-lib gromacs-libs.x86_64: W: no-documentation gromacs-mpi.x86_64: W: no-documentation gromacs-mpi-devel.x86_64: W: no-documentation gromacs-mpi-devel.x86_64: E: only-non-binary-in-usr-lib gromacs-mpi-libs.x86_64: W: no-documentation gromacs-tutor.x86_64: W: no-documentation gromacs-zsh.x86_64: W: no-documentation gromacs-zsh.x86_64: W: summary-not-capitalized zsh GROMACS support gromacs-zsh.x86_64: E: only-non-binary-in-usr-lib 12 packages and 1 specfiles checked; 5 errors, 15 warnings. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-0.15.rc3.fc9.src.rpm
I've contacted upstream. Gromacs 4 can read files made with Gromacs 3, so there are no reasons to have two packages - the newest version available is enough. I closed the gromacs3 review request.
Since the discussion on fedora-packaging seems to have ceased without reaching a conclusion and there isn't a need to be able to have many versions of Gromacs concurrently installed, I have removed the support for environment-modules and just renamed all binaries to start with g_ . Since everything resides in standard locations the package should now be acceptable for distribution, please review. http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-1.fc9.src.rpm gromacs.x86_64: W: no-documentation gromacs-bash.x86_64: W: no-documentation gromacs-bash.x86_64: W: conffile-without-noreplace-flag /etc/bash_completion.d/gromacs4 gromacs-csh.x86_64: W: summary-not-capitalized csh GROMACS support 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-tutor.x86_64: W: no-documentation gromacs-zsh.x86_64: W: no-documentation gromacs-zsh.x86_64: W: summary-not-capitalized zsh GROMACS support 12 packages and 1 specfiles checked; 0 errors, 12 warnings.
$ wget http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-1.fc9.src.rpm --2008-10-12 23:10:01-- http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-1.fc9.src.rpm Resolving theory.physics.helsinki.fi... 128.214.57.188 Connecting to theory.physics.helsinki.fi|128.214.57.188|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2008-10-12 23:10:01 ERROR 403: Forbidden.
OK, now it has the read attribute set :)
(In reply to comment #48) > Since the discussion on fedora-packaging seems to have ceased without reaching > a conclusion and there isn't a need to be able to have many versions of Gromacs > concurrently installed, I have removed the support for environment-modules and > just renamed all binaries to start with g_ . Excellent. > Since everything resides in standard locations the package should now be > acceptable for distribution, please review. > gromacs-bash.x86_64: W: conffile-without-noreplace-flag > /etc/bash_completion.d/gromacs4 This could be easily fixed. And one last nitpick: %{_bindir}/g_mdrun_mpid is inconsistently named in comparison to all the other binaries which have _d suffix. You can fix both of these upon import. This package is now APPROVED. I have just sponsored you, so you can request the creation of CVS module for gromacs now and import the package after setting up your CVS access.
New Package CVS Request ======================= Package Name: gromacs Short Description: GROMACS: Fast, Free and Flexible MD Owners: jussilehtola Branches: F-8 F-9 F-10 EL-4 EL-5 InitialCC:
(In reply to comment #51) > You can fix both of these upon import. This package is now APPROVED. > I have just sponsored you, so you can request the creation of CVS module for > gromacs now and import the package after setting up your CVS access. Fixed. Thanks a lot. New spec & srpm: http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-2.fc9.src.rpm I'll push these to the release branches as soon as I'm able.
cvs done
gromacs-4.0-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/gromacs-4.0-3.fc9
gromacs-4.0-3.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/gromacs-4.0-3.fc8
Sorry for the spams about updates. Had to fight a bit with Bodhi to get the package included; the additional builds thingy in web bodhi doesn't seem to work, it only picks one of them.
gromacs-4.0-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
gromacs-4.0-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Package Change Request ====================== Package Name: gromacs New Branches: Owners: jussilehtola Updated Description: Fast, Free and Flexible Molecular Dynamics
Whoops, I changed the wrong flag, sorry Dominik :)
you want to update the description on the devel branch only? I think description gets updated from the package, but not sure how often or when. I can check on that if you like.
(In reply to comment #63) > you want to update the description on the devel branch only? > > I think description gets updated from the package, but not sure how often or > when. > I can check on that if you like. Yeah, I think devel is enough, since IIUC the only place the pkgdb description is visible is pkgdb itself? OK, and Bugzilla. In any case, yum shows the info from the rpms, so for a user there's no difference.
Looking into this. We have a script that should be updating this but it has obviously failed for Gromacs.
This has now been fixed. The scripts to update descriptions were looking for certain yum repositories. Unfortunately, those repositories could not be reached from inside of PHX. I've updated the scripts to use the mirrorlist and added a specific host (archives.fedoraproject.org) to the /etc/hosts files so that this is no longer an issue. Confirmed that gromacs' summary and description were updated after the changes.