Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

> On 2 Jan 2018, at 17:58, Mikael Öhman wrote: [ … ] > But the existance of another toolchain is not a problem; sparsely populated > toolchains versions are. > With the combinatorics of at least 2 primary toolchains (foss/intel), 2 major > python versions (3 when

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

On 01/03/2018 11:25 PM, Lev Lafayette wrote: > On Wed, 2018-01-03 at 09:00 +0100, Åke Sandgren wrote: >> It usually doesn't matter one iota which toolchain something is built >> with from a user perspective. And the user perspective is the only one >> that matters at all. >> > > Well, for

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

On Wed, 2018-01-03 at 09:00 +0100, Åke Sandgren wrote: > It usually doesn't matter one iota which toolchain something is built > with from a user perspective. And the user perspective is the only one > that matters at all. > Well, for starters different software performs better under different

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

Hi Äke I dont think this standpoint is any different from mine. The problematic case you mention is the case I and John are talking about specifically. If i try to summarize my point as well: I think we spread ourselves unnecessarily thin, which limits combinations of modules or requires the

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

Hi all, now for a somewhat different standpoint. It usually doesn't matter one iota which toolchain something is built with from a user perspective. And the user perspective is the only one that matters at all. If, for instance, GROMACS 2016.3 is built with foss/2017a and GROMACS 2016.4 is

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

Dear Joachim, On 08/12/2017 10:35, Joachim Hein wrote: Hi, Reading through Kenneth’ reply, I am honestly wondering whether we should skip a foss/2018a. The below does not suggest any big upgrade. Considering the human cost of moving all "helper” packages (such as HDF5, netcdf, Python and

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

| wo | do | vr - Original Message - From: "Joachim Hein" <joachim.h...@math.lu.se> To: "easybuild" <easybuild@lists.ugent.be> Cc: "Backeljauw Franky" <franky.backelj...@uantwerpen.be> Sent: Friday, 8 December, 2017 10:35:49 Subject:

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

On 12/08/2017 12:39 PM, Alvarez, Damian wrote: +1 for going for 18.1. But the glibc issues (not kernel issues) have been solved already (https://access.redhat.com/errata/RHBA-2017:3296). This package should find its way into CentOS 7.4 real quick (maybe it is already there, I am not sure).

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

+1 for going for 18.1. But the glibc issues (not kernel issues) have been solved already (https://access.redhat.com/errata/RHBA-2017:3296). This package should find its way into CentOS 7.4 real quick (maybe it is already there, I am not sure). Damian On 08/12/17 10:35,

Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

Hi, Reading through Kenneth’ reply, I am honestly wondering whether we should skip a foss/2018a. The below does not suggest any big upgrade. Considering the human cost of moving all "helper” packages (such as HDF5, netcdf, Python and Pythonwrapers, Boost) that our users require, I am close