Update the compiler from gcc@14.1.0 to gcc@15.1.0

[harshula]

• This will allow us to remove gcc@14.1.0 from our spack-config since we already have gcc@14.2.0.

---

🚀 The latest prerelease pinentry/pr20-1 at 759f394 is here: #20 (comment) 🚀

[github-actions]

The model version in the gh/spack.yaml has not been updated.
You can update it manually.
Alternatively, comment the following to have it updated and committed automatically:

• !bump major for feature releases
• !bump minor for bugfixes

[github-actions]

🚀 Attempted to deploy gh Prerelease pr20-1 with commit 759f394

🖥️ Gadi Deployment ❌

[github-actions]

The model version in the ncdu/spack.yaml has not been updated.
You can update it manually.
Alternatively, comment the following to have it updated and committed automatically:

• !bump major for feature releases
• !bump minor for bugfixes

[github-actions]

🚀 Attempted to deploy ncdu Prerelease pr20-1 with commit 759f394

🖥️ Gadi Deployment ❌

[github-actions]

The model version in the openssh/spack.yaml has not been updated.
You can update it manually.
Alternatively, comment the following to have it updated and committed automatically:

• !bump major for feature releases
• !bump minor for bugfixes

[github-actions]

🚀 Attempted to deploy openssh Prerelease pr20-1 with commit 759f394

🖥️ Gadi Deployment ❌

[github-actions]

The model version in the pinentry/spack.yaml has not been updated.
You can update it manually.
Alternatively, comment the following to have it updated and committed automatically:

• !bump major for feature releases
• !bump minor for bugfixes

[github-actions]

🚀 Attempted to deploy pinentry Prerelease pr20-1 with commit 759f394

🖥️ Gadi Deployment ❌

[dougiesquire]

@CodeGat what to do here? I don't think we want to update the versions because they're the versions of the upstream packages being deployed.

[CodeGat]

The packages need new versions because we use the version as the spack environment name - a similar issue @anton-seaice had in this repo.

When we get to v8 and decouple the package version from the deployment version it will no longer be an issue.

[dougiesquire]

@harshula how important is this? Could we leave the gcc@14.1.0 external?

ncdu and pinentry are already at their latest versions (gh and openssh could be updated).

[harshula]

Hi @CodeGat , Can we use YYYY.0M.MINOR-RELEASE as per https://github.com/ACCESS-NRI/dev-docs/wiki/Versioning#models ?

[CodeGat]

@harshula, unfortunately not. The package gh (and other upstream packages) define their own versions and the @git.YYYY.0M.MINOR-RELEASE tag wouldn't be in their packages repository. Furthermore, since the version of those packages is meaningful in itself (as in gh@2.49.2 maps to https://github.com/cli/cli/releases/tag/v2.49.2) I don't think we should change it too drastically, even if we could. Maybe in the form gh@2.49.2-1/gh@2.49.2-2/etc. if we need to rerelease something, like in this case.

That said, once we have moved to v8 and decoupled the version of the package from the version of the deployment, all this will no longer be an issue. We can have the version of the package be static, and the version of the deployment (and environment, and modulefile) be something like I described above. If it can wait until then, that would be good.

[harshula]

Hi @CodeGat , I should have been clearer and pasted the entire text, "There can be a Spack release tag. e.g. YYYY.0M.MINOR-RELEASE". i.e. Can we just add the -RELEASE? That's how GNU/Linux distros have been updating the packaging of the same release of the source package for decades.

[harshula]

Hi @CodeGat , ☝️

[CodeGat]

So we'd have gh@2.49.2-1, in https://github.com/ACCESS-NRI/system-tools/pull/20/files#diff-9c1184741666c054c0455bffdb3e18f2dc7298574e26dabf63b80c1d92ca851bL9 for example? We could only do that if the gh SPR has that version defined, which it doesn't.

Once we move to v8, we will be able to do that version as you describe, but on this version of the infrastructure, we can't.