Description of problem: Activating a module breaks the man path Version-Release number of selected component (if applicable): environment-modules-4.1.1-1.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Install a package that provides a module, such as openmpi or mpich 2. Load the module 3. Try `man man` Actual results: Get "No manual entry for man" Expected results: Man page should be available Additional info: Unloading the module makes all the man pages available again: (ins)[asinha@ankur ~]$ module list Currently Loaded Modulefiles: 1) python-sphinx/python2-sphinx 2) mpi/openmpi-x86_64 (ins)[asinha@ankur ~]$ man man No manual entry for man Vim: Reading from stdin... (ins)[asinha@ankur ~]$ module unload mpi/openmpi-x86_64 (ins)[asinha@ankur ~]$ man man Vim: Reading from stdin... -- On further inspection, one finds that loading the module overwrites the man path, instead of maybe appending to it?: (ins)[asinha@ankur ~]$ module load mpi/openmpi-x86_64 (ins)[asinha@ankur ~]$ echo $MANPATH /usr/share/man/openmpi-x86_64 We thought it may be a bug in the packages, but given that another user experienced it with mpich, and I'm experiencing it with openmpi, I thought maybe it's the environment_modules package. Please re-assign it to openmpi if that's where the bug is. Thanks, Ankur
Please, try with https://bodhi.fedoraproject.org/updates/environment-modules-4.1.2-1.fc28.
Hi Jan, It doesn't look like I fixed it: $ env | grep MANPATH MANPATH_modshare=/usr/share/man/openmpi-x86_64:1 MANPATH=/usr/share/man/openmpi-x86_64 $ rpm -q environment-modules environment-modules-4.1.2-1.fc28.x86_64 Do you think it's a bug in openmpi instead maybe? The mpich maintainer pushed some fix as discussed in the other bug. Thanks, Ankur
Hi Ankur, Hi Jan, There was some hack in previous environment-modules version (v3.2.x) that was automatically adding "/usr/share/man" to MANPATH variable when appending-path/prepending-path to it. This hack does not exist anymore on new major version of environment-modules (v4.x). I was thinking to re-introduce the hack but it does not seem to be a good idea as it is not possible to finely control the variable with it (to clear completely MANPATH or set it to just one directory). So I suggest to handle the inclusion of regular man paths on all modulefiles prepending or appending to MANPATH variable, if they want the regular paths to still be there once their specific path is added. I suggest to move the ticket to openmpi to proceed like what was done for mpich. Best regards, Xavier
(In reply to Xavier Delaruelle from comment #3) > > There was some hack in previous environment-modules version (v3.2.x) that > was automatically adding "/usr/share/man" to MANPATH variable when > appending-path/prepending-path to it. That is quite thoroughly broken too. Maybe in not a such blatant and horrible way as the current situation but still broken. > > So I suggest to handle the inclusion of regular man paths on all modulefiles > prepending or appending to MANPATH variable, if they want the regular paths > to still be there once their specific path is added. Only the issue is than in the current setup MANPATH in general is NOT explicitely set but described in details in /etc/man_db.conf and setting it to point to one directory is definitely not good enough. > I suggest to move the ticket to openmpi to proceed like what was done for > mpich. In the case of MANPATH it was possible to work around with an extra ":". I am not sure if other possible environment variables would be so forgiving. From my POV a handling of implicit configuration settings in environment-modules is incorrect and a loaded trap.
(In reply to Michal Jaegermann from comment #4) > (In reply to Xavier Delaruelle from comment #3) > > > > There was some hack in previous environment-modules version (v3.2.x) that > > was automatically adding "/usr/share/man" to MANPATH variable when > > appending-path/prepending-path to it. > > That is quite thoroughly broken too. Maybe in not a such blatant and > horrible way as the current situation but still broken. Why? I mean, you can only do it one way or the other, there's nothing in between, really. > In the case of MANPATH it was possible to work around with an extra ":". I > am not sure if other possible environment variables would be so forgiving. > From my POV a handling of implicit configuration settings in > environment-modules is incorrect and a loaded trap. I leave this desicion on Xavier/upstream. I'm not sure how other common environment variables work, but I also think that NOT setting a variable automatically is a better decision. It's what env-modules is all about.
Switching component per comment 3.
(In reply to Jan Synacek from comment #5) > (In reply to Michal Jaegermann from comment #4) > > (In reply to Xavier Delaruelle from comment #3) > > > > > > There was some hack in previous environment-modules version (v3.2.x) that > > > was automatically adding "/usr/share/man" to MANPATH variable when > > > appending-path/prepending-path to it. > > > > That is quite thoroughly broken too. Maybe in not a such blatant and > > horrible way as the current situation but still broken. > > Why? I mean, you can only do it one way or the other, there's nothing in > between, really. Try to type on a default installation, where MANPATH is not explicitely set, manpath You see only /usr/share/man in the output or something else too? Now do 'mkdir ~/man' and type 'manpath' again. Something changed? Now assume that some other program either explicitely set MANPATH to something more involved (maybe using environment-modules or by editing /etc/man_db.conf and leaving MANPATH unset). Do you still think that adding _only_ /usr/share/man to whatever you are trying to add in your module is an not broken thing to do? It looked to me that this was quite obvious. Maybe adding in environment-modules an output of manpath to whatever you are trying to append would work around that but that could be too specific to a particular implementation of man-db.
Hi, Could we get a fix for this in the openmpi package in the meantime please? One similar to the mpich one would do. Thanks :)
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Hello, Bumping version---not sure if this has been fixed? Cheers!
Fixed in rawhide.
FEDORA-2019-af50f19b83 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.1-10.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pmix-3.1.4-2.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83
aircrack-ng-1.5.2-8.fc31, gromacs-2019.3-1.fc31.2, hpx-1.3.0-4.fc31, hwloc-2.0.4-1.fc31, legion-19.06.0-3.fc31, mpich-3.3.1-1.fc31, openmpi-4.0.2-0.2.rc1.fc31, pmix-3.1.4-2.fc31, pocl-1.2-6.20190221gita0b083a1b47a738.fc31, slurm-19.05.2-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.