Description of problem: Current package does not build on RHEL7 (Even sources says it should ;)) Version-Release number of selected component (if applicable): Latest 2.28.0 rpm src package How reproducible: Steps to Reproduce: 1. Install package on RHEL7 2. Build with rpmbuild 3. Actual results: compilation & linking does not work Expected results: Packages shoudl be build & generated from source package. Additional info: This little patch fix the build: --- git.spec 2020-07-28 21:17:54.000000000 +0200 +++ git-exane.spec 2020-08-26 18:47:05.489853876 +0200 @@ -75,10 +75,12 @@ %endif # Hardening flags for EL-7 %if 0%{?rhel} == 7 %global _hardened_build 1 +%global build_cflags %__global_cflags +%global build_ldflags %__global_ldflags %endif # Hardening flags for EL-6 %if 0%{?rhel} == 6 %global build_cflags %{build_cflags} -fPIC -pie
Hmm. The intention is that we're building with EPEL enabled, where the %build_cflags and %build_ldflags are provided by epel-rpm-macros. But I realize it's easy to enable EPEL and still not have the macros package. So perhaps -- if wanted to make this easier for use with rpmbuild on an EL-7 host, outside of mock -- we could define those only when they aren't already set? FWIW, the epel-rpm-macros package defines them as: # Various build flag macros, backported from Fedora %build_cflags %{optflags} %build_cxxflags %{optflags} Something like this in the EL-7 section (untested, may contain typos or other errors): %{!?build_cflags: %global build_cflags %optflags} %{!?build_ldflags: %global build_ldflags %optflags} ?
Hello, Thanks for this quick update. I did get a bit lost in the macro code ... But your proposal looks good. Here the diff I tested (working one) with epel-rpm-macros not being installed. --- git.spec 2020-07-28 21:17:54.000000000 +0200 +++ git-exane.spec 2020-08-26 22:31:34.497538436 +0200 @@ -75,10 +75,12 @@ %endif # Hardening flags for EL-7 %if 0%{?rhel} == 7 %global _hardened_build 1 +%{!?build_cflags: %global build_cflags %optflags} +%{!?build_ldflags: %global build_ldflags %__global_ldflags} %endif # Hardening flags for EL-6 %if 0%{?rhel} == 6 %global build_cflags %{build_cflags} -fPIC -pie Frédéric
Thanks for testing! As I looked at it again, I wondered whether it would be just as easy and more future-proof to add epel-rpm-macros as a BR? Like so: diff --git i/git.spec w/git.spec index 381fe31..6550beb 100644 --- i/git.spec +++ w/git.spec @@ -142,6 +142,9 @@ BuildRequires: linkchecker BuildRequires: desktop-file-utils BuildRequires: diffutils BuildRequires: emacs +%if 0%{?rhel} == 7 +BuildRequires: epel-rpm-macros +%endif BuildRequires: expat-devel BuildRequires: findutils BuildRequires: gawk That way, if the macros change or we make use of any others, we'd be covered? It may also make it more obvious that EPEL is required. Of course, in testing, I just realized that none of the BuildRequires come from EPEL. That surprised me. I thought we required some packages from EPEL. I guess it's possible that RHEL-7 has pulled those in over it's lifespan. It's also possible that I simply never checked all the BuildRequires on EL-7. In many ways, it still seems like it may be best to BuildRequires epel-rpm-macros. However, without any BuildRequires from EPEL (currently), that would add a dependency on EPEL that isn't strictly needed. Some EL-7 users might find that onerous (or mildly annoying). The commit which added the build_cflags/build_ldflags macros was made in February 2019, so building git from rawhide without epel-rpm-macros hasn't worked in quite some time. This is the first report. :) Thoughts, Frédéric (or anyone else)?
Hello Todd, It's ok for me to have the epel-rpm-macros depedency at build time. as it won't be needed at run time. It will definitly solve the issue I went through. For the story I was using the build from Wandisco before (Stuck @2.22) then one obsure repo for 2.27.0 (That broke a few things), so I went back to the 'source', eg a rebuild of the Fedora Package. -> I made a few test on various Internal CIs with this package & so far it looks good on RHEL7. Frédéric
FEDORA-2020-5476485ad2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5476485ad2
FEDORA-2020-5476485ad2 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5476485ad2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5476485ad2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5476485ad2 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.