packaging: Introduce Packit CI to track RPM building by Growl1234 · Pull Request #7910 · pmodels/mpich

Growl1234 · 2026-07-31T03:58:42Z

Pull Request Description

This PR brings the maintenance of the Fedora RPM build into the upstream repository, with the aim of strengthening the connection and collaboration between upstream development and downstream packaging. It also makes it possible to track the potential impact of upstream changes on the Fedora RPM during development. The goal is to minimize the maintenance burden associated with the RPM build and keep the upstream project more closely synchronized with the version available in the Fedora repositories.

The relevant CI tests are handled by Packit. Every commit pushed to the main branch triggers Packit CI, and users with triage permissions can also trigger a build from a pull request by commenting /packit build. This requires maintainers to install Packit-as-a-Service app for this repository and obtain access to Packit (see https://packit.dev/docs/guide).

The RPM spec with corresponding patches is copied from downstream repo; patches are adjust to meet the current upstream condition. Since MPICH uses release artifact, the maint/release.pl is reused in Packit to provide the proper tarball that allows the Packit workflow to pass.

Author Checklist

Provide Description
Particularly focus on why, not what. Reference background, issues, test failures, xfail entries, etc.
Commits Follow Good Practice
Commits are self-contained and do not do two things at once.
Commit message is of the form: module: short description
Commit message explains what's in the commit.
Passes All Tests
Whitespace checker. Warnings test. Additional tests via comments.
Contribution Agreement
For non-Argonne authors, check contribution agreement.
If necessary, request an explicit comment from your companies PR approval manager.

LecrisUT

Can you split the first commit in 2, one copying the downstream content as-is and another adding the changes to make it buildable for upstream? I will keep the review minimal here for just getting things to build, and minimizing the difference with downstream, and then we can work on improving the process in subsequent PRs/reviews

LecrisUT · 2026-07-31T11:02:01Z

+%dir %{_libdir}/%{name}/lib/cmake
+%dir %{_libdir}/%{name}/include
+%dir %{_fmoddir}/mpich
+%{_libdir}/%{name}/lib/*.so.*


We need to handle soversion here somehow.

Also best not to glob the library names. If a library is removed downstream needs to rebuild the dependencies (same with soversion changes)

The development branch treats soversion as 0, while release tarball is 12. Therefore, RPM-build tests failed. Is there way to better handle this?

Autotools and perl, my archenemies. I think

mpich/maint/release.pl

Line 224 in c2e6701

system(qq(perl -p -i -e 's/\\[libmpi_so_version_m4\\],\\[0:0:0\\]/[libmpi_so_version_m4],[$so_version]/g' ./maint/version.m4));

should handle the versioning if my blind guess is correct. Maybe check the order of the actions and if it does indeed replace that snippet after archiving.

IIUC the soversion flag should be passed as 18:1:6 for now, thus libmpi.so.12. What I'm concerning is whether we have to add --so-version 18:1:6 to .packit.yaml, which means for maintainers one more place will need to care, as I guess there's only one way to pull in soversion for MPICH: to run release.pl with manually adding --so-version.

Actually downstream did no soversion locked it so we can postpone this for a bit later.

For the PR and such here it would be fine to use some dummy values, unless you want to use a copr for more production stuff. We can just replace with actual good soversions in the propose_to_downstream when the specific value is given in the archive

I've temporarily set soversion to 0 in RPM spec. Hope we can find a solution in the future.

hzhou · 2026-08-01T22:59:10Z

@Growl1234 What is the impact if we merge this? I am tempted to merge this first to get the CI working. Then we can use additional PR to clean it up.

Please prefix each commit subject with packaging: prefix. Please add commit message stating the purpose of each commit.

Growl1234 · 2026-08-02T06:16:41Z

What is the impact if we merge this? I am tempted to merge this first to get the CI working. Then we can use additional PR to clean it up.

Sorry, I don't understand what did you mean by "impact"🤔 As I understand it, this doesn't touch the other part of the repository, except the need to adjust release.pl which is done via #7909. What we need in the next step is:

This requires maintainers to install Packit-as-a-Service app for this repository and obtain access to Packit (see https://packit.dev/docs/guide).

LecrisUT · 2026-08-03T06:57:37Z

Preferably the github app installation is done before the merge. If the app is not installed and this is merged, then it is just a no-op, but when it is installed you might get a flood of notifications if there are slight misconfigurations or you will get a bunch of red checks in the PR. If you install the app before though, all the notifications and statuses are still confined to this PR. Also from my experience, people forget to enable the app, and eventually lead to some nasty bit-rots.

For how ready this one is, from reading the commits, it should be all good, but seeing a green check here is always the best confirmation for it.

- Adjust patches: delete patches that are no longer needed, and sync some of them with upstream - Minor adjustments to spec itself, e.g. upstream no longer use README; they use README.md instead

Test RPM-build workflow upstream so that potentianal problems can be easier to track.

If library soversion is changed downstream needs to rebuild the dependencies, so we have to track it

If a library is removed downstream needs to rebuild the dependencies, so we have to track them.

This is a workaround to simply get rid of RPM-build failure. It should be revised somehow.

hzhou · 2026-08-03T16:36:10Z

@LecrisUT What permission should I grant?

--
Never mind. I see issue packit/notifications#746. On it.

Growl1234 · 2026-08-03T17:01:17Z

/packit build

hzhou · 2026-08-03T17:30:11Z

Is there a way to use version defined in

mpich/maint/version.m4

Line 17 in b29cabf

m4_define([MPICH_VERSION_m4],[5.1.0a1])dnl

?

Is there a way to run a basic test after the rpm install to verify working status? The following would be a good test:

mpicc -o cpi examples/cpi.c
mpiexec -n 2 ./cpi

Growl1234 · 2026-08-03T17:45:48Z

Is there a way to run a basic test after the rpm install to verify working status?

IIRC we can leverage Test Farm; unfortunately I'm not very familiar with it, but @LecrisUT can provide more information.

LecrisUT · 2026-08-03T17:47:00Z

Is there a way to use version defined in

mpich/maint/version.m4

Line 17 in b29cabf

m4_define([MPICH_VERSION_m4],[5.1.0a1])dnl

?

Definitely, but it depends on what you have in mind by "using it". How about making an issue to clarify that and address it in a follow up PR?

Is there a way to run a basic test after the rpm install to verify working status? The following would be a good test:
mpicc -o cpi examples/cpi.c
mpiexec -n 2 ./cpi

Do I have a fancy vacuum cleaner to sell you 😅. I'll make a PR to show the testing-farm onboarding for defining these kind of tests 😉.

hzhou · 2026-08-03T17:52:18Z

Okay. Sounds good.

One last question: can we disable the default pull requests build but retain a way to manually invoke it? I would like to keep the amount of noise low during a pull request iteration.

Growl1234 · 2026-08-03T17:58:46Z

can we disable the default pull requests build but retain a way to manually invoke it?

Done. It can be easily triggered via a simple /packit build.

(Btw, it not only processes new comments but also listens to edits. So, you can just re-use an existing comment. Inserting even a single space character will trigger a re-eval.)

hzhou

Looks good! Thanks @Growl1234 @LecrisUT for the work!

hzhou · 2026-08-03T18:00:05Z

test:mpich/ch3/tcp
test:mpich/ch4/ofi

There are a few unrelated test failures: ch4-ofi-vci: pt2pt/pingping and comm/comm_idup_comm2, both timeouts. Will investigate separately.

LecrisUT · 2026-08-03T18:01:41Z

Okay. Sounds good.

One last question: can we disable the default pull requests build but retain a way to manually invoke it? I would like to keep the amount of noise low during a pull request iteration.

Definitely. You can either run it based on a PR label (recommended workflow) or based on manual trigger. I do however recommend to still have at least either the rawhide-x86_64 or aarch64 running as regularly as possible because it also tracks changes outside of the project that you should be aware of. Can always ping us when something like that happens or we can add it so that we are pinged on each builf failure (prefer to avoid atm because we also get pinged when it fails while working on PRs ¹)

https://github.com/packit/packit-service/issues/2231 ↩

hzhou · 2026-08-03T21:55:43Z

@LecrisUT It still runs on every merge, right? Do I get notifications when the merge tests fail?

Growl1234 · 2026-08-03T23:14:58Z

Uh it turns out I forgot to add it to my copr project, which is why the CI didn't work on the merge. Sorry. Now it should be OK.

Growl1234 requested review from LecrisUT and hzhou July 31, 2026 03:58

LecrisUT reviewed Jul 31, 2026

View reviewed changes

Growl1234 force-pushed the rpm branch 4 times, most recently from 8ec52d4 to 2fc8b75 Compare August 1, 2026 03:25

Growl1234 force-pushed the rpm branch 2 times, most recently from e18aa0a to 283b27f Compare August 2, 2026 06:08

Growl1234 force-pushed the rpm branch from 283b27f to e9cef3a Compare August 2, 2026 15:20

Growl1234 added 6 commits August 3, 2026 11:32

packaging: Add RPM spec recipes from downstream

8632750

packaging: Adjust RPM recipes

3685682

- Adjust patches: delete patches that are no longer needed, and sync some of them with upstream - Minor adjustments to spec itself, e.g. upstream no longer use README; they use README.md instead

packaging: Add .packit.yaml for RPM-build CI-testing

e73f0ad

Test RPM-build workflow upstream so that potentianal problems can be easier to track.

packaging: Set soversion explicitly in RPM spec

caf1b0d

If library soversion is changed downstream needs to rebuild the dependencies, so we have to track it

packaging: Make library names explicit

93ec092

If a library is removed downstream needs to rebuild the dependencies, so we have to track them.

packaging: Temporarily set soversion to 0 in upstream RPM spec

0827227

This is a workaround to simply get rid of RPM-build failure. It should be revised somehow.

hzhou force-pushed the rpm branch from e9cef3a to 0827227 Compare August 3, 2026 16:32

Growl1234 changed the title ~~Introduce Packit CI to track RPM building~~ packaging: Introduce Packit CI to track RPM building Aug 3, 2026

packaging: add manual trigger for packit PR job

4de20d5

hzhou approved these changes Aug 3, 2026

View reviewed changes

hzhou merged commit 3385527 into pmodels:main Aug 3, 2026
15 of 16 checks passed

hzhou mentioned this pull request Aug 3, 2026

RPM building #7906

Closed

Uh oh!

Conversation

Growl1234 commented Jul 31, 2026

Pull Request Description

Author Checklist

Uh oh!

LecrisUT left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

LecrisUT Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

Growl1234 Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

LecrisUT Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

Growl1234 Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

LecrisUT Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

Growl1234 Aug 2, 2026

Choose a reason for hiding this comment

Uh oh!

hzhou commented Aug 1, 2026

Uh oh!

Growl1234 commented Aug 2, 2026

Uh oh!

LecrisUT commented Aug 3, 2026

Uh oh!

hzhou commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Growl1234 commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hzhou commented Aug 3, 2026

Uh oh!

Growl1234 commented Aug 3, 2026

Uh oh!

LecrisUT commented Aug 3, 2026

Uh oh!

hzhou commented Aug 3, 2026

Uh oh!

Growl1234 commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hzhou left a comment

Choose a reason for hiding this comment

Uh oh!

hzhou commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LecrisUT commented Aug 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

Uh oh!

hzhou commented Aug 3, 2026

Uh oh!

Growl1234 commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

hzhou commented Aug 3, 2026 •

edited

Loading

Growl1234 commented Aug 3, 2026 •

edited

Loading

Growl1234 commented Aug 3, 2026 •

edited

Loading

hzhou commented Aug 3, 2026 •

edited

Loading

LecrisUT commented Aug 3, 2026 •

edited

Loading