This is a tracking bug for Change: RPM MPI Requires Provides For more details, see: https://fedoraproject.org//wiki/Changes/RpmMPIReqProv Add dependency generators to encode the MPI compiler name in the provides string of a binary to distinguish otherwise identical provides between packages $foo, $foo-openmpi and $foo-mpich.
This message is a reminder that Fedora 23 Change Checkpoint: Completion deadline (testable) is on 2015-07-28 [1]. At this point, all accepted Changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline. This bug should be set at least to the MODIFIED state to indicate that it achieved completeness. Status will be provided to FESCo right after the deadline. If, for any reasons, your Change is not in required state, let me know and we will try to find solution. For Changes you decide to cancel/move to the next release, please use the NEW status and set needinfo on me and it will be acted upon. In case of any questions, don't hesitate to ask Wrangler (jkurik). Thank you. [1] https://fedoraproject.org/wiki/Releases/23/Schedule
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Remark on current status: test-builds done on COPR [1], requested proven packager help to rebuild affected packages in rawhide and F23 [2]. [1] https://copr.fedoraproject.org/coprs/smani/rpm-mpi-hooks-testing2/ [2] https://lists.fedoraproject.org/pipermail/devel/2015-July/212794.html
Removing from the scope of F23 as we have already passed the deadline when this change needs to be in MODIFIED state.
I could use some help with valgrind-openmpi Currently in rawhide I get: valgrind has broken dependencies in the rawhide tree: On x86_64: 1:valgrind-openmpi-3.10.1-18.fc24.x86_64 requires libmpi.so.1()(64bit) On i386: 1:valgrind-openmpi-3.10.1-18.fc24.i686 requires libmpi.so.1 On armhfp: 1:valgrind-openmpi-3.10.1-18.fc24.armv7hl requires libmpi.so.1 valgrind-openmpi provides the libmpiwrap library to use memcheck with your mpi programs. See: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mpiwrap libmpiwrap is build using openmpi mpicc and gets linked against openmpi libmpi.so.1 (which is where the requires comes from). What/How should I change to get the shared library to link and require the correct new library provides?
Do I understand correctly that, while it is built using openmpi, it can be used for any MPI implementation? In that case I think the cleanest solution would just be to filter the requires from the library, since it is safe to assume that if a user wants to debug an mpi application, some mpi implementation will be installed anyways.
(In reply to Sandro Mani from comment #6) > Do I understand correctly that, while it is built using openmpi, it can be > used for any MPI implementation? No, I don't think that would work. The libmpiwrap build for valgrind-openmpi is intended to be used with program build with the same openmpi mpicc. > In that case I think the cleanest solution > would just be to filter the requires from the library, since it is safe to > assume that if a user wants to debug an mpi application, some mpi > implementation will be installed anyways. Without openmpi installed valgrind-openmpi is indeed useless. So yes, the user most likely has openmpi already installed. I don't mind filtering out the requires from the libraries (although I don't know how that is done). But I am a little surprised that building a library using the openmpi mpicc doesn't generate the proper provides on the openmpi libmpi.so.
So, the script generating the requires / provides is looking for binaries within known MPI directories, which are: - Paths below %{_libdir}/$MPI - %{python_sitearch}/$MPI - %{_libdir}/gfortran/modules/$MPI where $MPI could be openmpi or mpich. The valgrind wrappers are not installed there: /usr/lib64/valgrind/libmpiwrap-amd64-linux.so /usr/lib64/valgrind/libmpiwrap-x86-linux.so so this is why the MPI dependency generator triggers ignore these. The filtering is described here [1]. I suppose something like %global __requires_exclude_from ^%{_libdir}/valgrind/libmpiwrap.*\.so$ should work. [1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
(In reply to Sandro Mani from comment #8) > So, the script generating the requires / provides is looking for binaries > within known MPI directories, which are: > > - Paths below %{_libdir}/$MPI > - %{python_sitearch}/$MPI > - %{_libdir}/gfortran/modules/$MPI > > where $MPI could be openmpi or mpich. > > The valgrind wrappers are not installed there: > > /usr/lib64/valgrind/libmpiwrap-amd64-linux.so > /usr/lib64/valgrind/libmpiwrap-x86-linux.so > > so this is why the MPI dependency generator triggers ignore these. Thanks. So I just changed things so that the libmpiwrap library gets installed under %{_libdir}/openmpi/valgrind with a symlink from the old location for backwards compatibility. And that seems to have triggered the new libmpi requires. See valgrind-3.10.1-19.fc24
Ok cool, nice solution.
rpm-mpi-hooks-3-1.fc23,mathgl-2.3-10.fc23,elpa-2015.05.001-2.fc23,freefem++-3.31-7.3.fc23,netcdf-4.3.3.1-5.fc23,MUMPS-5.0.1-2.fc23,gpaw-0.11.0.13004-15.fc23,ga-5.3b-18.fc23,valgrind-3.10.1-19.fc23,boost-1.58.0-6.fc23,dl_poly-1.9.20140324-14.fc23,hpl-2.1-13.fc23,netgen-mesher-5.3.1-8.fc23,espresso-3.3.0-7.fc23,scotch-6.0.4-5.fc23,hdf5-1.8.15-6.patch1.fc23,scalapack-2.0.2-10.fc23,gromacs-5.0.6-6.fc23,scorep-1.4.2-2.fc23,sundials-2.6.2-4.fc23,Ray-2.3.1-11.fc23,orsa-0.7.0-33.fc23,elk-3.1.12-14.fc23,mpich-3.1.4-5.fc23,openmpi-1.8.8-3.fc23,mpi4py-1.3.1-14.fc23,pypar-2.1.5_108-11.fc23,paraview-4.3.1-11.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/rpm-mpi-hooks-3-1.fc23,mathgl-2.3-10.fc23,elpa-2015.05.001-2.fc23,freefem++-3.31-7.3.fc23,netcdf-4.3.3.1-5.fc23,MUMPS-5.0.1-2.fc23,gpaw-0.11.0.13004-15.fc23,ga-5.3b-18.fc23,valgrind-3.10.1-19.fc23,boost-1.58.0-6.fc23,dl_poly-1.9.20140324-14.fc23,hpl-2.1-13.fc23,netgen-mesher-5.3.1-8.fc23,espresso-3.3.0-7.fc23,scotch-6.0.4-5.fc23,hdf5-1.8.15-6.patch1.fc23,scalapack-2.0.2-10.fc23,gromacs-5.0.6-6.fc23,scorep-1.4.2-2.fc23,sundials-2.6.2-4.fc23,Ray-2.3.1-11.fc23,orsa-0.7.0-33.fc23,elk-3.1.12-14.fc23,mpich-3.1.4-5.fc23,openmpi-1.8.8-3.fc23,mpi4py-1.3.1-14.fc23,pypar-2.1.5_108-11.fc23,paraview-4.3.1-11.fc23
BTW. For valgrind you'll need 3.10.1-20 which has one additional fix for s390x (which doesn't have openmpi, so would break with 3.10.1-19 which did things unconditionally). 3.10.1-20 - Don't move libmpiwrap when not building for openmpi (s390x) I'll do a backport to f23 and build. Should I also do the update?
valgrind-3.10.1-20.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=678500 Let me know if I should push that as an update or if you want to add that to the update group.
MUMPS-5.0.1-2.fc23, Ray-2.3.1-11.fc23, boost-1.58.0-6.fc23, dl_poly-1.9.20140324-14.fc23, elk-3.1.12-14.fc23, elpa-2015.05.001-2.fc23, espresso-3.3.0-7.fc23, freefem++-3.31-7.3.fc23, ga-5.3b-18.fc23, gpaw-0.11.0.13004-15.fc23, gromacs-5.0.6-6.fc23, hdf5-1.8.15-6.patch1.fc23, hpl-2.1-13.fc23, mathgl-2.3-10.fc23, mpi4py-1.3.1-14.fc23, mpich-3.1.4-5.fc23, netcdf-4.3.3.1-5.fc23, netgen-mesher-5.3.1-8.fc23, openmpi-1.8.8-3.fc23, orsa-0.7.0-33.fc23, paraview-4.3.1-11.fc23, pypar-2.1.5_108-11.fc23, rpm-mpi-hooks-3-2.fc23, scalapack-2.0.2-10.fc23, scorep-1.4.2-2.fc23, scotch-6.0.4-5.fc23, sundials-2.6.2-4.fc23, valgrind-3.10.1-19.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update freefem++ mathgl mpich netgen-mesher sundials paraview espresso netcdf elk valgrind gpaw elpa scotch boost orsa hpl Ray MUMPS mpi4py hdf5 pypar gromacs ga dl_poly openmpi rpm-mpi-hooks scorep scalapack'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/rpm-mpi-hooks-3-2.fc23%2Cmathgl-2.3-10.fc23%2Celpa-2015.05.001-2.fc23%2Cfreefem%2B%2B-3.31-7.3.fc23%2Cnetcdf-4.3.3.1-5.fc23%2CMUMPS-5.0.1-2.fc23%2Cgpaw-0.11.0.13004-15.fc23%2Cga-5.3b-18.fc23%2Cvalgrind-3.10.1-19.fc23%2Cboost-1.58.0-6.fc23%2Cdl_poly-1.9.20140324-14.fc23%2Chpl-2.1-13.fc23%2Cnetgen-mesher-5.3.1-8.fc23%2Cespresso-3.3.0-7.fc23%2Cscotch-6.0.4-5.fc23%2Chdf5-1.8.15-6.patch1.fc23%2Cscalapack-2.0.2-10.fc23%2Cgromacs-5.0.6-6.fc23%2Cscorep-1.4.2-2.fc23%2Csundials-2.6.2-4.fc23%2CRay-2.3.1-11.fc23%2Corsa-0.7.0-33.fc23%2Celk-3.1.12-14.fc23%2Cmpich-3.1.4-5.fc23%2Copenmpi-1.8.8-3.fc23%2Cmpi4py-1.3.1-14.fc23%2Cpypar-2.1.5_108-11.fc23%2Cparaview-4.3.1-11.fc23
For the record I submitted an valgrind f23 update myself because the -19 version doesn't build on s390x. https://bodhi.fedoraproject.org/updates/valgrind-3.10.1-20.fc23
(In reply to Mark Wielaard from comment #15) > For the record I submitted an valgrind f23 update myself because the -19 > version doesn't build on s390x. > https://bodhi.fedoraproject.org/updates/valgrind-3.10.1-20.fc23 Sorry, I missed your question. The update looks good.
MUMPS-5.0.1-2.fc23, Ray-2.3.1-11.fc23, dl_poly-1.9.20140324-14.fc23, elk-3.1.12-14.fc23, elpa-2015.05.001-2.fc23, espresso-3.3.0-7.fc23, freefem++-3.31-7.3.fc23, ga-5.3b-18.fc23, gpaw-0.11.0.13004-15.fc23, gromacs-5.0.6-6.fc23, hdf5-1.8.15-6.patch1.fc23, hpl-2.1-13.fc23, mathgl-2.3-10.fc23, mpi4py-1.3.1-14.fc23, mpich-3.1.4-5.fc23, netcdf-4.3.3.1-5.fc23, netgen-mesher-5.3.1-8.fc23, openmpi-1.8.8-3.fc23, orsa-0.7.0-33.fc23, paraview-4.3.1-11.fc23, pypar-2.1.5_108-11.fc23, rpm-mpi-hooks-3-2.fc23, scalapack-2.0.2-10.fc23, scorep-1.4.2-2.fc23, scotch-6.0.4-5.fc23, sundials-2.6.2-4.fc23, valgrind-3.10.1-19.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.