Bug 876308 - fedpkg 1.11 breaks parsing of %{!?rhel:0}
Summary: fedpkg 1.11 breaks parsing of %{!?rhel:0}
Alias: None
Product: Fedora
Classification: Fedora
Component: fedpkg
Version: rawhide
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Dennis Gilmore
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
TreeView+ depends on / blocked
Reported: 2012-11-13 19:08 UTC by Mattias Ellert
Modified: 2013-01-20 03:03 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-01-18 20:49:14 UTC
Type: Bug

Attachments (Terms of Use)
This patch implements the proposed changes. (1.09 KB, patch)
2012-11-22 12:31 UTC, Mattias Ellert
no flags Details | Diff

Description Mattias Ellert 2012-11-13 19:08:20 UTC
Description of problem:
The expected interpretation of %{!?rhel:0} when parsed during a fedora build where rhel is not defined is 0:

$ rpm -E '%{!?rhel:0}'

However, the fedpkg 1.11 update does something like:
$ rpm --define "rhel %{nil}" -E '%{!?rhel:0}'

I.e. the macro no longer returns the expected value.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Build a package whose spec uses the %{!?rhel:0} macro. Example from koji:
Actual results:
Failed build (fedpkg srpm fails)

Expected results:
Successful build

Comment 1 Tom "spot" Callaway 2012-11-14 13:59:46 UTC
Grumble grumble grumble. rpm evaluates unset macros differently from macros forced to %{nil}.

Hey Panu, how do you want fedpkg to handle this? What is the "proper" way to undefine a macro at the commandline? 

When we set %{rhel} to 0 (for non-rhel builds), it broke parsing ops.
When we set %{rhel} to %{nil} (for non-rhel builds), it broke different parsing ops.
We can't leave it set (for non-rhel builds), because that is obviously wrong.

Comment 2 Tom "spot" Callaway 2012-11-14 20:39:40 UTC
In fact, I'd go so far as to say this is an RPM bug, where RPM treats the result of passing "--define %{rhel} %{nil}" differently from when %{rhel} is unset.

Comment 3 Panu Matilainen 2012-11-16 10:45:38 UTC
Macro defined to %{nil} IS different from an undefined one, that's not a bug.
There's no "proper" way to undefine macros from command line ATM (although I think I'll just go ahead and add --undefine cli switch now).

The macro "language" does have %undefine directive though, so there is *a* way to accomplish it, one that should work with pretty much any ancient rpm version as well:

rpm --eval "%undefine rhel" --eval "%{?rel}"

Comment 4 Panu Matilainen 2012-11-16 11:08:46 UTC
...or rather, for the reproducer case:

[pmatilai@shell ~]$ rpm --eval '%{rhel}'
[pmatilai@shell ~]$ rpm --eval '%undefine rhel' --eval '%{!?rhel:0}'

[pmatilai@shell ~]$

Note the extra empty line from the first eval - --eval is not really intended for this kind of use :)

Comment 6 Mattias Ellert 2012-11-19 05:36:41 UTC
So the ball is back in fedpkg's court.

fedpkg should use --eval "%undefine rhel" instead of --define "rhel %nil", and similarly for the other macros it wishes to undefine.

Comment 7 Mattias Ellert 2012-11-22 12:31:04 UTC
Created attachment 649782 [details]
This patch implements the proposed changes.

Comment 8 Mattias Ellert 2012-11-30 07:55:33 UTC
Can I do something more to encourage to fedpkg maintainer to provide a fix for this bag? I have set the priority to urgent, I have set the severity to urgent, I have nominated it as an F18 blocker and I have provided a patch based on the proposed solution.

This is a very disruptive bug. Two thirds of my packages are FTBFS due to it. And I have several package updates that I have checked in to git that I have not been able to build because of it.

Comment 9 Fedora Admin XMLRPC Client 2012-11-30 18:27:42 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Tim Flink 2012-11-30 18:51:28 UTC
This may be a disruptive bug but I don't think it qualifies as a blocker for F18. It doesn't violate any of the F18 release criteria and could be fixed with an update post-release.

-1 blocker

Comment 11 Adam Williamson 2012-12-01 08:22:17 UTC
-1 blocker, unless there is some consequence of this of which we are not aware. It does not affect the critical functionality of the release package set, so far as I can tell.

Comment 12 Jaroslav Reznik 2012-12-03 14:23:44 UTC
-1 blocker

Comment 13 Tim Flink 2012-12-04 20:54:33 UTC
I count -3 blocker votes, moving to rejected.

Comment 14 Mattias Ellert 2012-12-06 05:24:22 UTC
Hi Dennis!

I hope you have more time to fix things than the previous maintainer seems to have had. Could you please give this issue some priority. This bug is currently making it impossible for me to maintain my packages in Fedora. The solution has been known for three weeks, and a patch is attached to the bug report.

Comment 15 Mattias Ellert 2012-12-07 10:06:09 UTC
Hi again!

Can you give an estimate about when you will be able to fix this?

If you prefer I can apply for commit rights to the package and if you are willing to grant them I can provide a package update. Let me know.

Comment 16 Mattias Ellert 2012-12-12 07:42:45 UTC

Comment 17 Mattias Ellert 2012-12-13 07:52:42 UTC

Comment 18 Mattias Ellert 2012-12-14 07:50:32 UTC

Comment 19 Mattias Ellert 2012-12-15 08:36:24 UTC

Comment 20 Mattias Ellert 2012-12-16 12:15:08 UTC

Comment 21 Adam Williamson 2012-12-17 21:32:50 UTC
Mattias: please stop clogging up people's bug feeds. Daily pings are not polite behaviour.

Comment 22 Mattias Ellert 2012-12-19 09:55:36 UTC
(In reply to comment #21)
> Mattias: please stop clogging up people's bug feeds. Daily pings are not
> polite behaviour.

Thank you for your comment. Basically I agree with you. But my frustration with the handling of this bug is just growing every day. This critical regression has prevented me from doing my work as a package maintainer for a long time now. The solution is an almost trivial two-line patch that has been available for more than a month and there has still not been an update to fix it. I understand that not everything can be fixed immediatelly, but it has been a very long time now.

I understand this is not critical to everyone, because not everyone uses these kinds of macros in their specfiles, but for me it is. And it is frustrating feeling neglected and ignored.

I'll hold of the pings for a while. I was hoping to trigger some action from the mantainer, but if it goes on for too long it becomes counterproductive. I did get som feedback offline form the maintainer, but still no update. I am at a loss about what to do if this isn't resolved soon. I would feel a bit silly starting a non-responsive maintainer action against Dennis Gilmore, given that he is one of the core developers in Fedora.

Comment 23 Kevin Fenzi 2012-12-20 22:33:24 UTC
Just FYI, Dennis has been traveling of late, and has been very busy trying to get f18 out the door. 

I'll try and see about getting this moving along...

Comment 24 Toshio Ernie Kuratomi 2012-12-21 17:30:49 UTC
A quick look doesn't reveal anything that the patch will break internal to fedpkg but using it shows that the command line client now returns extra newlines.  I don't know if anything is depending on parsing the output of fedpkg and will be broken by that so I'm (not a maintainer, just a provenpackager) a little hesitant to apply this.

It seems like the conditionals can be modified to use 0%{!?rhel} instead of %{!?rhel:0} to workaround this.

Comment 25 Mattias Ellert 2012-12-27 22:37:56 UTC
I know the 0%{!?rhel} hack can be used. Personally, I find it very confusing and not very accurately expressing what the conditional is meant to express.

I do really hope that noone is suggesting that this bug should not be fixed. The %{!?rhel:0} macro has worked in specfiles for years and only a badly implemented change in the latest version of fedpkg broke it. The choice between fixing two buggy lines in fedpkg and forcing the implementation of a workaround in hundreds of lines of perfectly valid specfiles to be rather obvious in favour of fixing fedpkg.

Comment 26 Tom "spot" Callaway 2013-01-07 20:12:49 UTC
If the --eval workaround didn't emit an extra newline, I'd apply it without concern. Really, using --undefine is what we want here, but the problem is that it wouldn't work on RHEL era RPM (or even-non-rawhide Fedora). *sigh*

It might be possible to have pyrpkg (srpm is "rpkg") process the output (I'm guessing the newline goes to stdout) and strip out empty lines (just newline), but I don't think that is right either.

I think we will just have to live with the newline here. That seems less annoying than an entire class of macros not evaluating. Barring any opposition, I'll commit the eval fix and rebuild tomorrow.

Comment 27 Fedora Update System 2013-01-08 18:17:31 UTC
fedpkg-1.11-2.fc18 has been submitted as an update for Fedora 18.

Comment 28 Fedora Update System 2013-01-08 18:17:46 UTC
fedpkg-1.11-2.fc17 has been submitted as an update for Fedora 17.

Comment 29 Mattias Ellert 2013-01-09 05:56:56 UTC
Thanks for creating the updates. The rawhide buildroot is now working again. Would it be possible to add a buildroot override for the f18 update in order to have a working f18 buildroot while we wait for the update to reach stable.

Comment 30 Fedora Update System 2013-01-09 09:02:17 UTC
Package fedpkg-1.11-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fedpkg-1.11-2.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 31 Fedora Update System 2013-01-18 20:49:16 UTC
fedpkg-1.11-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 32 Fedora Update System 2013-01-20 03:03:14 UTC
fedpkg-1.11-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.