Bug 1301358

Adding Jan (scl-utils maintainer) as this seems to be a conflict between rpm macros provided by both packages

For now, the workaround is (in epel repo configuration):

    exclude=epel-rpm-macros

Reproducer (package built in CBS):

Spec in https://github.com/sclorg-distgit/php-pecl-raphf
Mock configuration https://github.com/remicollet/remirepo/blob/master/tools/mock/sclo654.cfg

I can't reproduce this.  I suspect there is some  additional magic I need to do in order to activate the SCL magic when calling rpmbuild.

I have the spec and associated tarball.  Both epel-rpm-macros and scl-utils-build are installed, and the macros are all present.  I'm calling rpmbuild as follows:

rpmbuild --define "_sourcedir $PWD" --define "_sourcedir  $PWD" --define "_specdir $PWD" --define "_builddir $PWD" --define "_srcrpmdir $PWD" --define "_rpmdir $PWD" --define 'dist .el6' --define 'rhel 6' --eval '%undefine fedora' --define 'el6 1' --eval '%undefine fc23' -ba /*.spec

Calling -bs works fine as well, in case the issue is with building the srpm.

The mock config has "php54-build" installed as well.  I don't see that package in either EPEL6 or EL6.  Maybe it's tied into that?

Also, the initial error mentions php-pecl-weakref, but the reproducer is php-pecl-raphf.  Not sure if that's involved somehow.

Of course, there's a leading slash in there that shouldn't be there, because I edited out a path but forgot to remove the slash.  Oops.

And I really would like to get to the bottom of this, but without being able to reproduce it there's not a whole lot I can do.  I have another method of doing the single thing I need to do (define one macro at the appropriate place) which might have less of an impact.  I can throw out a package which does that if you want to try it.

Thanks for the time spent on this.

> The mock config has "php54-build" installed as well.  I don't see that package in either EPEL6 or EL6.  Maybe it's tied into that?

The mock config also have the repository configuration for "centos-sclo-rh" which provides needed packages.

> Also, the initial error mentions php-pecl-weakref, but the reproducer is php-pecl-raphf.  Not sure if that's involved somehow.

Because "all" packages are affected (at least all I have tested), and raphf is a very small one, and recently cleaned (for centos), built locally and in CBS.

> I can't reproduce this. 

It happens in mock during the "setup" phase.

Copr build are also affected (and I don't see way to workaround it)

Ex: https://copr-be.cloud.fedoraproject.org/results/remi/php54more/epel-6-x86_64/00155745-php-twig/build.log.gz

I can reproduce outside of mock

# yum --enablerepo=extras install centos-release-scl

# yum install scl-utils-build epel-rpm-macros rh-php56-build rh-php56-php-devel

$ LANG=C rpmbuild -bs php-pecl-raphf.spec 
384
error: lua script failed: [string "<lua>"]:3: attempt to compare number with nil
  7<               (empty)
error: Unclosed %if

I'm also seeing some issues since the introduction of the epel-rpm-macros. The error is different, but I thought I'd document it here in case it's helpful in diagnosing the problem. I have some spec files where the first non-comments in the file are expressions like this:

%{!?_foo: %define _foo /some/dir/here}

These macro definitions work fine up until the very end when rpmbuild (in mock) is processing the %files section. It looks like the macros are not expanded. This results in errors like this:

Processing files: foo-1.0.0-1.el6.x86_64
RPM build errors:
error: File must begin with "/": %{_foo}/some/file

I've been able to correct the issue by using %global in place of %define (which was probably the correct thing to have done in the first place), but I found it odd that this wasn't a problem until the introduction of the epel-rpm-macros.

Yes, the latter issue is known (and discussed in the epel-devel and devel lists); you really shouldn't be using %define unless you need the special properties of %define.  And if you don't know what those are, then, well, you really, really shouldn't be using %define.

And yes, the way I implemented the mapping from %license to %doc will expose this bug in your packages.  It's not an issue for Fedora, of course, because I have already fixed all of the affected packages.

In any case, I am still trying to work around this.  Unfortunately last night's mass rebuild with a new macro package in place failed for unrelated reasons, so I have to run it again.

FYI, people which need to build SCL in Copr can add the temporary repository:
https://copr.fedorainfracloud.org/coprs/remi/fake-epel-rpm-macros/

Version is 6-2.1 so override broken 6.2 but not any future versions which may fix this issue (I will update the repo if needed).

So, the problem is down in the %scl_debug() macro.  It is not at all clear what's actually gone wrong here, but that macro is not at all pretty, and basically it doesn't appear to tolerate any instance of lua code within the definition of %debug_package.

Anyway, regardless of whether or not the SCL macros are broken, I will try to find a way to get out of the way of them.  But really, the errors you're seeing are coming from the code beginning with:

debuginfo=tonumber(rpm.expand("%{old_debug}"))

Sadly, I think this could all be much simpler, and some useful commenting in those macros wouldn't hurt.  It could also be a whole lot nicer if it was just written in lua.

Anyway, I believe I have a workaround.  I just need to do another few mass EPEL6 rebuilds and then I'll push it to testing.

epel-rpm-macros-6-4 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-9e5249d510

The update I just submitted for testing allows me to build the example package on EL6 without issues.  It also should fix the issue Daniel mentioned in comment 9.  I have done another few mass builds and found no regressions within EPEL.  Please test and give karma if you can, so this doesn't need to wait another two weeks to go to stable.

epel-rpm-macros-6-4 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-9e5249d510

Just tested a test in mock with epel-rpm-macros-6-4, everything seems OK.

epel-rpm-macros-6-4 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.