PS: I'm barely maintaining this package anymore due to the amount of work I have at the moment and me not working in the hpc sector anymore. But I get regular bug reports and fixes for this package. Lucas Nussbaum was asking around for a new maintainer, but while apparently quite a few people use it, no one wants to actively maintain it.
Recently another person wrote me he maintains a current PPA for Ubuntu - I wasn't even aware of that. Aaron On Wed 11. Nov 2020 at 20:41, Aaron Zauner (azet) <a...@azet.org> wrote: > Hi, > > > On 11.11.2020, at 20:30, Paul Gevers <elb...@debian.org> wrote: > > > > Hi Aaron, > > > >> On 11-11-2020 20:11, Sudip Mukherjee wrote: > >> Hi Aaron, > >> > >>> On Wed, Nov 11, 2020 at 7:02 PM Aaron Zauner (azet) <a...@azet.org> > wrote: > >>> > >>> Hey, > >>> > >>> That command does load everything that lmod needs in terms of > dependencies and checks the environment. It's not a proper test suite but > none exists so far, and I think this is sufficient to see if there's any > bugs related to dependencies or the main function of the tool. writing a > empty module to test lmod won't be any more effective. > > > > I have no clue what lmod does. > > Loads different environments for different compilers, blas and other > libraries as toolchains for development, usually on high performance > computing systems. it's based on "environment modules" an old tool from the > HPC world that's very out of date but has a lot of modern and fast features > to change the environment to the toolchain you need to work with for eg > local development or sending cluster jobs. > > > > >> I think what you said exactly matches my description in the bug. :) > > > > So do I. > > > >>>> Executing that command is considered to be a trivial test, which > >>>> does not provide significant coverage for a package as a whole. > >>>> But these tests are a useful way to detect regressions in dependencies > >>>> and prevent them from breaking your package. > >> > >>> > >>> If you can find a better alternative I'm all in, this was the best I > could come up with when packaging initially. If you still think it should > be marked superficial please do so. > > > > So, can you elaborate why you think that this test is substantially > > testing your package. E.g. we have (for now) accepted that meta packages > > actually do not much more than testing dependencies? But e.g. Python > > modules or Node modules that just do an include are superficial. And so > > are all tests that just print the version number although that "load > > everything that X needs in terms of dependencies". These tests are > > valuable, except they are not enough to warrant the exception that we > > are giving packages with non-superficial tests during regular migration > > (reduced age) and the bullseye freeze (longer period of uploading > > without needing the release team). > > As I said I'm not aware that there's any test suite for lmod or I'd have > included it. Writing a dummy module for the system toolchain gcc glibc etc > won't really tell anything useful about lmod itself. Again: if you think it > should be marked superficial that's fine by me. > > Aaron > > > > > Paul > > >
