Hey, Thanks for working this out guys! I think arch:all is a good solution having the Lua paths fixed upstream.
Aaron On Mon, Oct 26, 2020 at 1:45 PM Lucas Nussbaum <[email protected]> wrote: > Hi, > > On 26/10/20 at 11:19 +0100, Baptiste Jonglez wrote: > > Hi, > > > > On Tue, 15 Sep 2020 12:32:34 +0200 "Aaron Zauner (azet)" <[email protected]> > wrote: > > > If anyone wants to take over I'm more than fine with that. The amount > of work I have at the moment barely permits me from maintaining projects. > It's most sensible that someone actively using this project on Debian > maintains it, as is, I'm not using it much anymore and am not working in > HPC at the moment. The bug should definitely reported upstream. Upgrading > the package should be fairly simple though - the dependencies are already > in place, as are simple tests/git integration etc.: > https://github.com/azet/lmod-deb > > > > I had a look, and it seems to be an upstream "feature" that was > introduced > > between lmod 6.2 and lmod 6.3. > > > > The root cause is that the configure script uses the build-time paths > from > > lua, and then uses these paths at runtime. The upstream changelog for > 6.3 > > states: > > > > > Lmod now uses the values of LUA_PATH and LUA_CPATH at configuration > > > time. This way Lmod is safe from user changes to these important Lua > > > values. > > > > The corresponding upstream change and discussion: > https://github.com/TACC/Lmod/issues/112 > > > > This was already reported for ARM and closed: > https://github.com/TACC/Lmod/issues/338 > > > > Overall, I think the simplest solution is to change the architecture to > "any". > > Thanks Baptiste for the investigation. > I've just uploaded an NMU to unstable, and will also upload a fix to > stable. > > I also opened an RFA bug for this package to reflect the current > situation (#972938). > > - Lucas >
