@alalazo @tldahlgren
My PR fails one of the black formatting rules.
How do I find what line number and how to reformat?

Is there some way to automatically reformat?
I can't find the button for that.

@spackbot fix style

Let me see if I can fix that for you!

I was able to run spack style --fix for you!

==> Running style checks on spack
  selected: isort, mypy, black, flake8
==> Modified files
  var/spack/repos/builtin/packages/hpctoolkit/package.py
==> Running isort checks
  isort checks were clean
==> Running mypy checks
Success: no issues found in 558 source files
  mypy checks were clean
==> Running black checks
reformatted var/spack/repos/builtin/packages/hpctoolkit/package.py
All done! ✨ 🍰 ✨
1 file reformatted.
  black checks were clean
==> Running flake8 checks
  flake8 checks were clean
==> spack style checks were clean

I've updated the branch with isort fixes.

@alalazo Thanks! I'm still adjusting to the new formatter,
but I'll try to remember that.

Btw, besides the items 1-6 listed above, most of the diff is I did a little
rearranging of the variants and conflict to put related items together.

@alalazo Ok, I incorporated your suggestion.
I also eliminated the conflict for +gtpin ~level_zero since it's now redundant.

Unfortunately, adding +level_zero expands the "when" column awkwardly.
It might be better if spack allocated a width for each field and then
paginated within that width.
As is, running 'spack info' uses a lot of columns and the spillover looks ugly.

@spackbot run pipeline

I've started that pipeline for you!

@alalazo @hainest @blue42u
It took some digging, but I figured out why the ci pipeline is
failing. In the 2022.10.01 release, we have temporarily disabled +mpi
for hpcprof-mpi because there are some unresolved errors in the code.
And some of the e4s tests try to build hpcprof-mpi.

We would prefer not to delay the release to take the time to track
down the bugs and fix them. That's scheduled for the next release.

How should I handle this? I can think of a couple options:

1. Turn off the e4s test for hpcprof-mpi. I think this is the right
   thing to do.

Can someone show me how to do that?

2. Put in a hack in the spack recipe to build hpcprof-mpi anyway
   (there is a "force build" option). It should build, but some inputs
   cause it to crash. I think this is the wrong option and defeats the
   purpose of disabling hpcprof-mpi for now.

Plus, I see that I forgot to add a conflict for +mpi when @2022.10.01.
That would break any attempt to build +mpi.

Sorry for causing this trouble. We didn't realize that this would
break one of the tests.

@mwkrentel Let me know when the mitigation looks good to you and I'll merge.

@mwkrentel Is it good to be merged?

@alalazo Not quite yet. First, I want to ask E4S if it's feasible to temporarily
disable the ci/pipeline test that failed in the first place.
I decide sometime later today.

@alalazo @eugeneswalker
Ok, I've pushed up what I hope will be the last edit.
Assuming the CI tests pass and I expect they will,
then I'm ready to merge.
Thanks

@mwkrentel At the E4S meeting today, I brought up this issue with the ci pipeline. Sameer told me to email him and Wyatt, so they will take a look.

@eugeneswalker Ok, all green checks !

@hainest We decided to go ahead and merge the workaround for now.
But I'd still like to know how to handle this type of issue in the future.

What if we make a change in the package.py recipe that causes one of
the ci/gitlab tests to break?

Where do we go to update the ci tests?
And how big a deal is that?

@mwkrentel I'm afraid I don't know. I hope Sameer or Wyatt can help us with that.