I would assume that RHEL 9 & co already contains Mercurial?

https://docs.fedoraproject.org/en-US/epel/ says
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions.

I'm thus not sure it would be good or possible to "just" ship the fedora pacakge in EPEL.

Yes, I agree not to include RHEL packages in EPEL as it is against the guidelines unless there is a modular exception.

I was not able to find Mercurial in RHEL9 Beta:

# dnf provides mercurial
Updating Subscription Management repositories.
Last metadata expiration check: 1:35:22 ago on Mon Mar 14 10:40:52 2022.
Error: No Matches found

Closing as not required.
Blocked package 2063779 is available in CRB repo.

*** Bug 2088452 has been marked as a duplicate of this bug. ***

RHEL9 does not contain mercurial package, as per both release notes: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/package_manifest/repositories and per actual repositories search on a machine with those repositories enabled.

Please consider reopening this bug and actually providing mercurial package via EPEL 9.

Many thanks!

Can someone confirm?

Stefan, you withdrew your request. Can you say more about why?

@Mads Killerich,

I believe I closed it as I didn't require it anymore. I wanted it to build python-setuptools_scm which already is in the CRB repo as I found out later.

So I didn't check/follow up on its existance.

There also does not seem to be a mercurial 9 branch:
https://git.centos.org/rpms/mercurial/branches?branchname=

This would be the source, right?

I don't know. I'm not familiar with modern EPEL.

I spent some time reading up on EPEL packaging. It is apparently non-trivial ... or just not explicitly documented. It should apparently just be "fedpkg request-branch epel9" ... but that fails and talks about https://pagure.io tokens. Too many unknowns and lack of clear documentation.

I will be happy to co-maintain with a packager with EPEL experience.

You are doing it right. Just that your credentials expired.
Set a token up at https://pagure.io/settings#nav-api-tab

Then you can put that key via
fedpkg set-pagure-token
(although I am not sure on this part and can't verify it on my setup as my tokens work).
you can also try to log in via
kinit username
But I think you only need that later on when building and submitting the package.

My setup works just fine for fedora packaging - including kinit.

Yesterday, pagure.io failed.
And what is the role of pagure.io, compared to src.fedoraproject.org ?
What permissions do the token need ... and why?
That is not clearly documented.

Are you an EPEL packager? Will you comaintain?

I don't really want to co-maintain as I already more packages than I can handle.
But you can add me if you like. So I can request the branch and also push to testing.
fas: sbluhm

I just noticed that I am set as collaborator so I have requested the epel9 branch:
https://pagure.io/releng/fedora-scm-requests/issue/44521

not sure if collaborator is sufficient for that of if it needs to be admin or maintainer. If not, maybe you can copy the ticket or add me to one of those other roles.

epel9 branch has been created.

Build now fails due to the rust changes, it seems. Lots of dependencies are now missing:

$ fedpkg build
Building mercurial-6.1.2-2.el9 for epel9-candidate
Created task: 87413861
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=87413861
Watching tasks (this may be safely interrupted)...
87413861 build (epel9-candidate, /rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46): free
87413861 build (epel9-candidate, /rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46): free -> open (buildvm-s390x-20.s390.fedoraproject.org)
  87413877 buildSRPMFromSCM (/rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46): open (buildvm-ppc64le-08.iad2.fedoraproject.org)
  87413902 buildArch (mercurial-6.1.2-2.el9.src.rpm, s390x): open (buildvm-s390x-33.s390.fedoraproject.org)
  87413900 buildArch (mercurial-6.1.2-2.el9.src.rpm, aarch64): open (buildvm-a64-20.iad2.fedoraproject.org)
  87413901 buildArch (mercurial-6.1.2-2.el9.src.rpm, ppc64le): open (buildvm-ppc64le-20.iad2.fedoraproject.org)
  87413903 buildArch (mercurial-6.1.2-2.el9.src.rpm, x86_64): open (buildvm-x86-20.iad2.fedoraproject.org)
  87413877 buildSRPMFromSCM (/rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46): open (buildvm-ppc64le-08.iad2.fedoraproject.org) -> closed
  0 free  5 open  1 done  0 failed
87413861 build (epel9-candidate, /rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46): open (buildvm-s390x-20.s390.fedoraproject.org) -> FAILED: BuildError: error building package (arch aarch64), mock exited with status 30; see root.log for more information
  0 free  4 open  1 done  1 failed
  87413902 buildArch (mercurial-6.1.2-2.el9.src.rpm, s390x): open (buildvm-s390x-33.s390.fedoraproject.org) -> FAILED: BuildError: error building package (arch s390x), mock exited with status 30; see root.log for more information
  0 free  3 open  1 done  2 failed
  87413900 buildArch (mercurial-6.1.2-2.el9.src.rpm, aarch64): open (buildvm-a64-20.iad2.fedoraproject.org) -> FAILED: BuildError: error building package (arch aarch64), mock exited with status 30; see root.log for more information
  0 free  2 open  1 done  3 failed
  87413901 buildArch (mercurial-6.1.2-2.el9.src.rpm, ppc64le): open (buildvm-ppc64le-20.iad2.fedoraproject.org) -> FAILED: BuildError: error building package (arch ppc64le), mock exited with status 30; see root.log for more information
  0 free  1 open  1 done  4 failed
  87413903 buildArch (mercurial-6.1.2-2.el9.src.rpm, x86_64): open (buildvm-x86-20.iad2.fedoraproject.org) -> FAILED: BuildError: error building package (arch x86_64), mock exited with status 30; see root.log for more information
  0 free  0 open  1 done  5 failed

87413861 build (epel9-candidate, /rpms/mercurial.git:739a392e82e4fc2453ce05ea2937fde25a8b8e46) failed



I will try to build and publish an earlier commit.

Wasn't able to publish an earlier commit anymore without messing up the git history. So I have made some changes to the SPEC file to disable Rust.

Can you check this PR to see if this is in your interest?
https://src.fedoraproject.org/rpms/mercurial/pull-request/17

FEDORA-EPEL-2022-e644087cc8 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e644087cc8

FEDORA-EPEL-2022-e644087cc8 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e644087cc8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Stefan, thanks for showing and doing the epel9 build. I realize it is simple when done right ;-)

Some user experience feedback that someone who really knows perhaps can use to make future me self-supported:

The big headline I was missing on most https://docs.fedoraproject.org/en-US/epel/ pages is that epel *really* is just like ordinary Fedora release branches, using exactly the same tools and process. 

This experience is confusing:
$ fedpkg request-branch epel9
Could not execute request_branch: The following error occurred while creating a new issue in Pagure: Invalid or expired token. Please visit https://pagure.io/settings#nav-api-tab to get or renew your API token.

The use of pagure.io (not under fp.o) for "something" is surprising for me.

It is not clear what the token will be used for.

It is very hard to find documentation of what permissions the token need. Now, when I know what to look for, I find https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ ... but it is still not very clear. At least, the error message should say what permission is needed for the token.

https://docs.fedoraproject.org/en-US/epel/fedora-package-in-epel/ links "standard procedure" to https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ ... but that doesn't mention request-branch at all. I guess https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_Existing_Contributors/ would be better.

https://docs.fedoraproject.org/en-US/epel/epel-packaging-examples/ is really confusing, showing up prominently, but not being clear that it (apparently) is a very rare special case that generally can be ignored.

yeah, I got told once how to do it. I noted it down and am following the process.
For pagure, I just grant all access.
Every now and then a token expires somewhere and I somehow manage to refresh it all the time.

FEDORA-EPEL-2022-e644087cc8 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.