Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1925932

Summary: fmt: rebase to 6.2.1
Product: [Fedora] Fedora EPEL Reporter: Andrew Bauer <zonexpertconsulting>
Component: fmtAssignee: Kefu Chai <tchaikov>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: carl, davejohansen, kchai, tchaikov, vitaly
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: fmt-6.2.1-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-21 01:56:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andrew Bauer 2021-02-07 13:55:13 UTC
I am part of the dev team for the ZoneMinder project, whose rpm packages live in RPMFusion.

We've had a recent proposal to build against the fmt library. The only blocker is this package is not currently available for el7. 

An alternative would be to embed the library into the project, but as you can see it adds quite a bit to the project:

Adding fmt-6.2.1 to epel 7 would be a much cleaner solution.

After a minor change to the spec file, the fmt package builds fine on el7:

Here is the change that is needed:

Would the package maintainer be willing to build this package for el7?

I get it. el7 is old, which is why I am perfectly willing to maintain this branch myself. My FAS account is kni.

If you are willing to give me commit access, I can do all the work for you. Thank you.

Comment 1 Andrew Bauer 2021-02-07 14:09:51 UTC
The proposed specfile change is even simpler than that.

Both cmake (fedora) and cmake3 (rhel 7) package define %ctest3 macro:

>[abauer@vFedora ~]$ rpm --eval %ctest3
>  cd "x86_64-redhat-linux-gnu" 
>  /usr/bin/ctest --output-on-failure --force-new-ctest-process -j4  
>  cd -

>[abauer@vCentOS7 ~]$ rpm --eval %ctest3
>  cd "." 
>  /usr/bin/ctest3 --output-on-failure --force-new-ctest-process -j4  
>  cd -

So, all we need to do is change:

ctest -> %{ctest3} under %check

Comment 2 Fedora Update System 2021-02-18 14:25:25 UTC
FEDORA-EPEL-2021-d5fe34a16a has been submitted as an update to Fedora EPEL 7.

Comment 3 Fedora Update System 2021-02-19 01:25:43 UTC
FEDORA-EPEL-2021-d5fe34a16a has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 4 Fedora Update System 2021-02-21 01:56:09 UTC
FEDORA-EPEL-2021-d5fe34a16a has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Carl George 🤠 2021-02-21 21:37:49 UTC
This update bumps the soname from to  This is a breaking change which is against EPEL Policy [0].  mkvtoolnix no longer installs and needs to be rebuilt against the new soname (bug 1931239). Why wasn't the Incompatible Upgrades Policy [1] followed?


Comment 6 Vitaly 2021-02-22 10:58:23 UTC
> This is a breaking change which is against EPEL Policy [0].

That's why I'm not touching EPEL.

> Why wasn't the Incompatible Upgrades Policy [1] followed?

EPEL 7 didn't previously have an FMT library. Please check which repo you got from.

Comment 7 Carl George 🤠 2021-02-22 19:30:01 UTC
> EPEL 7 didn't previously have an FMT library. Please check which repo you got from.

Yes it did, and that's where I installed it from.  I got it as a dependency of mkvtoolnix.  You can see in koji that mkvtoolnix-46.0.0-1.el7 was built against fmt-devel-3.0.2-1.el7 [0] and was linked against [1].  You can also see the previous bodhi updates for EPEL7 [2], as well as the fact that the epel7 merge commit [3] has a parent commit updating the package to 3.0.2-1 [4].

So I ask again, why wasn't the Incompatible Upgrades Policy followed?  At a minimum, the submitter needs to email epel-devel to inform people of this situation.  I've already rebuilt mkvtoolnix against the new soname (bug 1931239), but anyone else linking against that library needs to be informed.


Comment 8 Carl George 🤠 2021-02-22 23:18:59 UTC
> [1]

Please excuse the typo, this link should be

Comment 9 Carl George 🤠 2021-03-31 20:18:06 UTC
Kefu, please send an email to epel-devel to inform people about this incompatible upgrade.

Comment 10 Carl George 🤠 2021-05-06 23:45:24 UTC
Vitaly, since Kefu is not responding will you handle announcing this on epel-devel?

Comment 11 Vitaly 2021-05-07 13:12:51 UTC
Sorry, I'm not interested in EPEL7.

Comment 12 Kefu Chai 2021-05-08 02:23:27 UTC
hi Carl, sorry for

1) missing the needinfo. somehow, i didn't get the notification.
2) violating the policy. i didn't mean to do so. just forgot to check for packages depending on libfmt and to send the mail to the ML.
3) introducing the regression and the inconvenience.

i just sent a mail to the epel-devel ML.

hi Vitaly, i am sorry for the noise.