Bug#974490: lmod: autopkgtest must be marked superficial

2020-11-11 Thread Aaron Zauner (azet)
Hi,

> On 11.11.2020, at 20:30, Paul Gevers  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)  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
> 



Bug#951508: A patch file

2020-09-15 Thread Aaron Zauner (azet)
Hi,

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

Thanks,
Aaron

> On 15.09.2020, at 09:33, Lucas Nussbaum  wrote:
> 
> retitle 951508 lmod: broken on all architectures except x86_64 (wrong search 
> path)
> severity 951508 serious
> thanks
> 
> Hi,
> 
> We ran into the same bug on an arm64 system, so it looks like lmod is
> broken on all architectures except x86_64. I'm updating the bug title
> and the severity to reflect that.
> 
> I'm attaching the diffoscope output that shows that the generated
> packages are indeed different on amd64 and arm64.
> 
> A simple fix would be to turn this package into an Architecture:any
> package.  But indeed, it should probably be reported (and fixed) upstream.
> 
>> On 17/02/20 at 19:49 +0100, Aaron Zauner wrote:
>> Since I'm barely keeping this package updated I'd suggest that you use the
>> upstream Lmod project source with the dependencies that come with this
>> package, you'll get more bug fixes, Performance and features out of it in a
>> production environment. That's what we used to do on live HPC systems since
>> a lot of software needs to be built by hand outside of the distro packaging
>> anyway.
> 
> Err, if this is the case, maybe you should mark this package as orphaned
> or RFA? I'm also Ccing people who uploaded NMUs for the package. Maybe
> someone is interested in taking over.
> 
> Lucas
>