Hide Forgot
The hook for %description which should define %buildroot properly doesn't work for me. What I usually do is that I generate 'srpm' on Fedora box, and then I try to --rebuild this srpm in epel-5 mock. This end's up with strange errors saying that %buildroot is not defined. Reproduced with: epel-rpm-macros-5-7.noarch ==== off bugzilla ==== <praiskup> ping, hi .. just a quick question about epel-rpm-macros .. before I fill a bug <praiskup> I have epel-rpm-macros in minimal buildroot -> but still, the BuildRoot seems to have no effect <praiskup> i.e. %buildroot is not defined within %prep, etc... <praiskup> is this expected? <praiskup> (epel-5-x86_64, tested even the release 7 which is in testing) <praiskup> tbh, it seems to me that the %description "hook" should define %buildroot macro, too <praiskup> (on the other hand, I'm not sure how to define $RPM_BUILD_ROOT)
Created attachment 1205190 [details] possible fix The 'putenv' for RPM_BUILD_ROOT is not needed, for some reason when %buildroot is explicitly defined.
I saw your ping on IRC but it was a bit early for me and you had left by the time I was able to reply. I of course did test the macros in use, so I'm not entirely sure what's actually happening in your case. Could you perhaps provide the spec you are using, so I can try to understand the problem you are seeing? Perhaps I simply didn't anticipate your use case. All of this back and forth with the EPEL5 version of these macros has diminishing returns anyway, as it won't be too long before EPEL5 will be EOL. But I'd still like to see what's not working. Your explicit define of %buildroot is probably a good idea in any case; it shouldn't be possible for it to hurt anything, even though it should be unnecessary as RPM will parse the BuildRoot: tag we magically added. And for the record, RPM itself will export RPM_BUILD_ROOT in the shell script it generates for each section, so I don't believe that explicitly setting it in the environment does much of anything.
(In reply to Jason Tibbitts from comment #2) > Your explicit define of %buildroot is probably a good idea in any case; it > shouldn't be possible for it to hurt anything, even though it should be > unnecessary as RPM will parse the BuildRoot: tag we magically added. I'm not sure now, yes -- it looks innocent, but it actually doesn't help me anyway. The spec file example is: https://fedorapeople.org/cgit/praiskup/public_git/scl-autotools.git/tree/repos/autotools/autotools-git/autotools-git/autotools-git.spec?id=fac480ee69548f57229ac96e8f8884b945cb8068 Try to remove the explicit BuildRoot definition by removing the first line _compat_el5_build.
The patch: --- a/repos/autotools/autotools-git/autotools-git/autotools-git.spec +++ b/repos/autotools/autotools-git/autotools-git/autotools-git.spec @@ -1,4 +1,4 @@ -%{?_compat_el5_build} +%{?epel_macros_trace 1} # Workaround to always have %%scl defined %{!?scl:%global scl autotools-git} @@ -32,6 +32,7 @@ Package shipping essential scripts to work with %scl Software Collection. %prep +test %buildroot != %%buildroot %setup -c -T Causes: Epel macros loading. In %description. No Group tag found; adding one. No BuildRoot tag found; adding one. Adding %clean. Redefining %__spec_install_post. In %description. No Group tag found; adding one. Already did %description processing In %description. No Group tag found; adding one. Already did %description processing In %description. No Group tag found; adding one. Already did %description processing In %install. Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/autotools-git-1-18.el5.centos.src.rpm Yum-utils package has been deprecated, use dnf instead. See 'man yum2dnf' for more information. Getting requirements for autotools-git-1-18.el5.centos.src --> Already installed : scl-utils-build-20120927-9.el5.x86_64 --> Already installed : iso-codes-0.53-1.noarch No uninstalled build requires Finish: build setup for autotools-git-1-18.src.rpm Start: rpmbuild autotools-git-1-18.src.rpm Epel macros loading. In %description. No Group tag found; adding one. No BuildRoot tag found; adding one. Adding %clean. Redefining %__spec_install_post. In %description. No Group tag found; adding one. Already did %description processing In %description. No Group tag found; adding one. Already did %description processing In %description. No Group tag found; adding one. Already did %description processing In %install. Building target platforms: x86_64 Building for target x86_64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.35043 + umask 022 + cd /builddir/build/BUILD + LANG=C + export LANG + unset DISPLAY RPM build errors: + test %buildroot '!=' %buildroot
This seems to be related to %scl_package macro, which itself work with %description ... and I must admit that requesting to fix doesn't make much sense. So probably feel free to close this.
I guess the amount of documentation I left in the macros was at least sufficient to help you get some idea of what's going on, since you seem to have found most of the tricks. The SCL stuff is, sadly, rather horrible. I wasn't even aware that the SCL macros existed on EL5. Of course, those macros shouldn't be used in any Fedora package, and the whole point of the epel-rpm-macros hack is to make it easier to backport Fedora packages to EPEL, so in general there shouldn't be any conflict. The SCL macros interfere with EL6 as well, though there they simply break in some cases. In this case it _might_ be possible for me to simply add to the existing description macro instead of overwriting it, but experience has shown that even a slight perturbation to things causes the SCL macros to bug out in ways that are difficult to debug. And they're a pretty horrible mess of intertwined lua and classic RPM macro expansion with essentially no documentation, which makes them rather difficult to comprehend. If you have any ideas, though, I'm happy to at least try to accommodate.
Comments in code were useful, because some of the things would look definitely weird undocumented (candidates for removal), you deal with rather corner cases (but scl is corner case too obviously). The issue not about %scl non-readability in %scl macros, but rather about two macro packages not taking the other into account. Up to that, I found yet another issue with your "%clean" hack, because you re-define the __spec_post_install macro, and that is not friendly with find-debuginfo.sh script used from scl package. This makes me basically uinstall `epel-rpm-macros` from my minimal buildroot :(. Unfortunately I don't want to spend more time with this puzzle, so it is easier to switch back to my helper package `compat-rpm-config`. Thanks for having a look anyway!