Enable testing builds using packit for Fedora

[bkmgit]

Additional tests that will make distributing Fedora RPMs easier.

To get it to work, someone with commit access will need to agree to make a Fedora account at:
https://accounts.fedoraproject.org/

and agree to Fedora Code of Conduct, then follow the steps at:

http://packit.dev/docs/guide#1-set-up-packit-integration

Closes #27878

[jabraham17]

I've only taken a cursory look at the new chapel.spec, but I have some other concerns. In general, I am very excited about the prospect of being able to test Chapel rpms on packit/copr and about having Chapel rpms available in standard fedora pacakges. I do have a fedora account that can be used for this

This is a big change in how we do packaging (arguably for the better). I have two big overarching concerns

• maintenance of this rawhide spec
  • there are a number of fields in the spec that will need to be update (the version number and some of the pinned dependencies like clang20) that will need to be updated over time. Who is responsible for doing that (i.e. does this need to be added to our release process)
• divergence of packaging builds
  • This is very different from how we do the current packaging builds for fedora (see util/packaging/rpm/fc41/spec.template). While this is probably much better and more thorough in terms of the spec, its also very different (this makes it a maintenance issue more than anything) and has a much smaller feature set (only CHPL_COMM=none, no multi-locale builds).
  • What can be done to close the gap between these two packaging strategies?

[jabraham17]

I think a better approach here is to write a chplconfig file before running ./configure

[jabraham17]

I see some changes made to add a chplconfig and want to clarify. I was referring to https://chapel-lang.org/docs/main/usingchapel/chplenv.html#chapel-configuration-files, not a shell script.

[jabraham17]

scspell3k is a development only dependency and is not needed in an rpm

[jabraham17]

CHPL_TASKS=fifo should not be used, this should be qthreads

[bkmgit]

Will package qthreads.

[jabraham17]

CHPL_TARGET_CPU should be set to none

[bkmgit]

ok

[bkmgit]

I've only taken a cursory look at the new chapel.spec, but I have some other concerns. In general, I am very excited about the prospect of being able to test Chapel rpms on packit/copr and about having Chapel rpms available in standard fedora pacakges. I do have a fedora account that can be used for this

This is a big change in how we do packaging (arguably for the better). I have two big overarching concerns

* maintenance of this rawhide spec
  
  * there are a number of fields in the spec that will need to be update (the version number and some of the pinned dependencies like `clang20`) that will need to be updated over time. Who is responsible for doing that (i.e. does this need to be added to our release process)

This can be automated to some degree, in particular the version number can be bumped whenever there is a release.
Pinned dependencies would probably need some manual changes, llvm and clang are the most important. Some of the Python tools may also require care as Fedora typically has one version of Python and associated libraries. Is there a policy on how long to support particular versions? EPEL moves more slowly than Fedora, but is consumed by RHEL, Rocky Linux and Alma Linux.

* divergence of packaging builds
  
  * This is very different from how we do the current packaging builds for fedora (see `util/packaging/rpm/fc41/spec.template`). While this is probably much better and more thorough in terms of the spec, its also very different (this makes it a maintenance issue more than anything) and has a much smaller feature set (only CHPL_COMM=none, no multi-locale builds).

libfabric is packaged in Fedora, but the build with this fails for some reason. Trying to figure out why.
GASNet needs to be packaged, though Fedora strongly prefers shared libraries and GASNet is at present
static only.

  * What can be done to close the gap between these two packaging strategies?

A template spec file would ease maintenance. The documentation can also be built within Fedora. The other binaries could also be built once the necessary dependencies are available.

[jabraham17]

Generally, this is all looking good to me (pending the implementation of the rest of the feedback).

This can be automated to some degree, in particular the version number can be bumped whenever there is a release.
Pinned dependencies would probably need some manual changes, llvm and clang are the most important

I would love your help in implementing some of this? How would the version number be automated? Our current processes are pretty manual

Is there a policy on how long to support particular versions? EPEL moves more slowly than Fedora, but is consumed by RHEL, Rocky Linux and Alma Linux.

Pretty much our policy is we support a platform until it goes EOL for the compiler/runtime. For some other tools, we require slightly higher dependencies (mostly newer Python versions). For binary packages, we currently support FC41, FC42, and EL10 (see https://github.com/chapel-lang/chapel/releases/tag/2.6.0). For fedora, we track whatever is not EOL since fedora moves fast. For EL, we drop the binary package when we can no longer build the binary package (usually when python3 gets too old)

I would love to work with you on getting more of our preferred configurations into this spec that are already in the RPMs in our release, and maybe one day have those get replaced by RPMs that are just in the fedora repos.

As far as getting this merged to chapel main, I think an important next step is to discuss it in our next project meeting. I think this is a big enough change that community input is important. You can comment on #27886 to queue this up. If you can't make that time, as a fallback I can try and champion this for you