Thank you ci for catching the missing update of the c++ library standard x)

@tldahlgren it's not clear to me what went wrong here.
Do you have a way to see what the e4s build is having trouble with?

@tldahlgren it's not clear to me what went wrong here. Do you have a way to see what the e4s build is having trouble with?

Unfortunately there is no way to view the full logs for the failed Paraview build. It is a crazy reality because GitLab sets a 4MB limit on the log output and Paraview produces >4mb of log output with current verbosity settings. There is work in progress to fix this. In the meantime, I just pulled in the latest from develop and we will see if the pipeline will pass now.

Should we update the spack_cuda_arch_map to include an entry for the new Hopper, cuda_arch=90? @crtrott thoughts?

• https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/kokkos/package.py#L120-L135

@eugeneswalker adding the new architectures is a good idea, I have added Hopper and Navi.

Regarding the Paraview failures, what is the current option to move forward?

@tldahlgren it's not clear to me what went wrong here. Do you have a way to see what the e4s build is having trouble with?

Unfortunately there is no way to view the full logs for the failed Paraview build. It is a crazy reality because GitLab sets a 4MB limit on the log output and Paraview produces >4mb of log output with current verbosity settings. There is work in progress to fix this. In the meantime, I just pulled in the latest from develop and we will see if the pipeline will pass now.

I think this is the job for that run: https://gitlab.spack.io/spack/spack/-/jobs/6382577. Assuming that is the case, the build log is included in the Job Artifacts and can be downloaded. I'm seeing a number of failures in the log. It is almost 10K lines long so I'm not sure about uploading it here but will if you can't access it.

Regarding the Paraview failures, what is the current option to move forward?

Let us see if the failure reproduces itself on this most recent pipeline run. If it does, I will reproduce the failure locally and we can troubleshoot it that way. We on the E4S team want to get this PR merged and will help resolve the failure. Thank you @tldahlgren for pointing out that we can see full failure log in the job artifacts-- I didn't realize this!

I did not notice the artifacts on the right tab of the build pipeline. I was able to download the build output and I can see that vtk is using private headers from Kokkos. So this is an error on their side...
My guess is that their repo is configured to build automatically against the latest version of Kokkos or maybe the master branch, or worse the develop branch?
In any case, this pipeline is trying to build against a version they have clearly not tested. My guess is that they can simply update the logic in their spack package to specify which versions of Kokkos have been tested against?

It is the paraview +rocm build that is failing again:

• https://gitlab.spack.io/spack/spack/-/jobs/6397025
• Full logs: https://gitlab.spack.io/spack/spack/-/jobs/6397025/artifacts/file/jobs_scratch_dir/logs/spack-build-out.txt

Perhaps we should include in this PR a modification to paraview package.py so that the dependency of paraview +rocm on kokkos is capped to kokkos@:3.7.01 until this can be worked out? Then we can get the new kokkos in Spack for everyone else. What do you think? A simple follow-on PR could release this constraint on kokkos version for paraview+rocm once the issue is resolved.
https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/paraview/package.py#L215-L219

@danlipsa @kwryankrattiger @vicentebolea Thoughts?

@eugeneswalker looks good to me to constrain paraview to Kokkos <= 3.7. Will you do it in this PR or should we do it in our end in another PR?

@eugeneswalker looks good to me to constrain paraview to Kokkos <= 3.7. Will you do it in this PR or should we do it in our end in another PR?

Just now pushed the change to this PR.

The ParaView change looks good to me 👍

Will updating this branch require retesting or can it be merged after the update?

Well I guess I got my answer, let's see how it looks later today, hopefully we won't need to update again after the ci completes : )

Will updating this branch require retesting or can it be merged after the update?

yes, but the pipeline won't necessarily have to rebuild as much as the previous time if the effective hash the of kokkos package does not change. The biggest trouble with updating with the latest is it gets blocked by the currently running develop CI, which can take up to 12 hours to complete depending on what needs to be rebuilt.

Note, because of this delay, it is not required the be "up to date" with develop to merge, because it is impossible for that to happen unless you are the first PR to merge after the develop CI completes.

So long as there are no conflicts, do not update.

Okay this looks ready to merge then!

The biggest trouble with updating with the latest is it gets blocked by the currently running develop CI, which can take up to 12 hours to complete depending on what needs to be rebuilt.

That explains my long build wait times.