Package Details: lmod 8.6.14-1

Git Clone URL: https://aur.archlinux.org/lmod.git (read-only, click to copy)
Package Base: lmod
Description: Environment modules system based on Lua that handles MODULEPATH hierarchical problem. Supports also legacy TCL modules
Upstream URL: https://github.com/TACC/Lmod
Licenses: custom
Conflicts: env-modules, lmod-git
Provides: env-modules
Submitter: wookietreiber
Maintainer: matse
Last Packager: matse
Votes: 8
Popularity: 0.41
First Submitted: 2017-01-17 13:22 (UTC)
Last Updated: 2022-02-28 08:17 (UTC)

Required by (10)

Sources (1)

Latest Comments

matse commented on 2021-04-12 13:36 (UTC)

@sogaiu: thanks for the hint! That were indeed the wrong filenames. I've updated the hint with the correct filenames.

sogaiu commented on 2021-04-12 13:22 (UTC)

The current install message has the text (in lmod.install):

----------------------------------------------------
In order tu use lmod make sure to source
/etc/profile.d/module.sh or /etc/profile.d/module.csh
----------------------------------------------------

May be it's a bit better if modules.sh and modules.csh were used in that text instead of module.sh and module.csh respectively.

matse commented on 2020-09-04 17:23 (UTC)

@berquist: Updated to newest release and done. Thanks for the hint.

berquist commented on 2020-09-04 02:43 (UTC)

Can you change env-modules-tcl to env-modules inprovides and conflicts?

matse commented on 2020-08-06 10:28 (UTC) (edited on 2020-08-06 16:58 (UTC) by matse)

@simonp yes, it's because of the update to lua 5.4 and broken lua-posix at the moment. Since the package was updated today, just reinstall / recompile lua-posix and it will work again.

lahwaacz commented on 2020-08-06 10:14 (UTC) (edited on 2020-08-06 10:14 (UTC) by lahwaacz)

@simonp: you need to rebuild all lua modules and this package for the new lua version.

simonp commented on 2020-08-06 09:32 (UTC)

I'm getting the following error after updating lua this morning:

/usr/bin/lua: version mismatch: app. needs 503.0, Lua core provides 504.0 stack traceback: [C]: in ? [C]: in function 'require' /usr/share/lua/5.3/posix/init.lua:23: in main chunk [C]: in function 'require' /usr/share/lmod/lmod/libexec/lmod:61: in main chunk [C]: in ?

matse commented on 2019-06-19 23:23 (UTC)

lahwaacz: Convinced and thanks for the information! Fixed!

lahwaacz commented on 2019-06-19 05:34 (UTC)

matse: The assumption is for the base-devel group, not for base - see e.g. https://bbs.archlinux.org/viewtopic.php?pid=1699678#p1699678. The wiki was wrong, I just fixed that.

matse commented on 2019-06-18 23:11 (UTC) (edited on 2019-06-18 23:12 (UTC) by matse)

lahwaacz: procps-ng belongs to the base group, which is assumed to be installed on systems, on which you build your own packages, see: https://wiki.archlinux.org/index.php/Makepkg#Usage

lahwaacz commented on 2019-06-18 20:09 (UTC)

It does not seem to build in a clean chroot unless I add procps-ng into depends.

matse commented on 2019-05-24 05:35 (UTC) (edited on 2019-05-24 05:38 (UTC) by matse)

berquist: zsh support has not been removed, I myself use it. The supposed way to init lmod on zsh is also with "modules.sh". There in line 71 the shell specific file gets loaded. The file "/usr/share/lmod/lmod/init/zsh" was never meant to land in "/etc/profile.d". By default zsh users don't have to do anything, because the arch default on zsh is (see https://wiki.archlinux.org/index.php/Zsh#Startup/Shutdown_files) to source /etc/profile which again sources all *.sh files in /etc/profile.d where "modules.sh" gets sourced and inits lmod via the zsh file. So placing modules.sh in /etc/profile.d and renaming the zsh file to zsh.sh and place it there, is not, how it is intended to load lmod.

berquist commented on 2019-05-23 23:48 (UTC)

Why did you remove ln -sf /usr/share/lmod/lmod/init/zsh modules.zsh? Z shell support still exists.

angelv commented on 2018-07-04 10:15 (UTC)

On upgrade, I got:

error: failed to commit transaction (conflicting files) lmod: /usr/share/lmod/lmod exists in filesystem

I just rm /usr/share/lmod/lmod and did the package install again.

wookietreiber commented on 2018-06-11 17:12 (UTC)

@simonp: done

simonp commented on 2018-06-11 06:28 (UTC)

there is a conflict with env-modules-tcl (AUR):

lmod: /usr/share/man/man1/module.1.gz exists in filesystem (owned by env-modules-tcl)

devzero commented on 2018-04-19 06:10 (UTC)

I see you changed make pre-install to make install, that solved the problem for me.

wookietreiber commented on 2018-04-18 19:28 (UTC) (edited on 2018-04-18 19:33 (UTC) by wookietreiber)

I don't quite get what the problem is.

The package is creating the /usr/share/lmod/lmod symlink to the version it installs, as is normal with lmod. Then it creates the profile.d symlinks, e.g. /etc/profile.d/modules.sh -> /usr/share/lmod/lmod/init/profile.

I just did a fresh install, started a new login shell (bash) and it works.

At which point are your symlinks broken?

Edit: Sorry, forgot to mention, that I used the new PKGBUILD I just pushed.

devzero commented on 2018-04-18 01:26 (UTC)

Even with the pre-install step in, the package is still installing under /usr/share/lmod/$pkgver instead of /usr/share/lmod/lmod:

$ pacman -Qql lmod | xargs -n1 dirname | sort -u
/
/etc
/etc/profile.d
/usr
/usr/share
/usr/share/licenses
/usr/share/licenses/lmod
/usr/share/lmod
/usr/share/lmod/7.7.3
/usr/share/lmod/7.7.3/init
/usr/share/lmod/7.7.3/lib
/usr/share/lmod/7.7.3/libexec
/usr/share/lmod/7.7.3/libexec/term
/usr/share/lmod/7.7.3/lib/term
/usr/share/lmod/7.7.3/messageDir
/usr/share/lmod/7.7.3/modulefiles
/usr/share/lmod/7.7.3/modulefiles/Core
/usr/share/lmod/7.7.3/modulefiles/Core/lmod
/usr/share/lmod/7.7.3/modulefiles/Core/settarg
/usr/share/lmod/7.7.3/settarg
/usr/share/lmod/7.7.3/shells
/usr/share/lmod/7.7.3/tools
/usr/share/lmod/7.7.3/tools/i18n
/usr/share/man
/usr/share/man/man1

This breaks the symlinks in /etc/profile.d, and even if they pointed to the right place, the shell init scripts all have /usr/share/lmod/lmod hardcoded, so they still wouldn't work.

I am able to work around this by symlinking /usr/share/lmod/$pkgver to /usr/share/lmod/lmod, but it's not ideal.

Ergus commented on 2017-09-28 14:42 (UTC) (edited on 2017-09-28 16:07 (UTC) by Ergus)

Thank you very much! But there is "pre-install" now instead of just "install", so the package doesn't work out of the box because the links are not created in the path.

wookietreiber commented on 2017-09-28 12:45 (UTC)

just updated.

Ergus commented on 2017-09-28 12:03 (UTC)

Hi: The package is out of date. I updated the aur repository locally to version 7.7 (it is really very simple) and it is working in my system very fine. So if you want my changes just ask. Best

wookietreiber commented on 2017-02-05 17:00 (UTC)

The **module** command is provided as a shell function via the `/etc/profile.d` scripts. If you source them or start a new login shell and type: ``` $ type module module is a function module () { eval $($LMOD_CMD bash "$@") && eval $(${LMOD_SETTARG_CMD:-:} -s sh) } ```

davidovitch commented on 2017-02-04 22:31 (UTC)

Never mind, I think I have to read the docs with a bit more thought first, the module command is not set for non-root users by default, and is provided by /usr/share/lmod/lmod/libexec/lmod. I'll delete these useless comments in a few days.

davidovitch commented on 2017-02-03 22:36 (UTC)

Do I get it correctly that the current package does not provide the module command? The man pages are included though.