Bug 449717 - %check in rpm-spec comments kills rpm.specs
Summary: %check in rpm-spec comments kills rpm.specs
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jon Masters
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 449419 449485 449500 449544
TreeView+ depends on / blocked
Reported: 2008-06-03 03:17 UTC by Ralf Corsepius
Modified: 2009-12-18 06:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-12-18 06:11:35 UTC
Type: ---

Attachments (Terms of Use)

Description Ralf Corsepius 2008-06-03 03:17:48 UTC
Description of problem:

rpmbuild < FC10 had accepted using %check in comments.
rpmbuild >= FC10 doesn't do so anymore.

c.f. the build-log attached to
for an example of how this breaks working rpm.specs.

The fix to BZ 449419 had been this change to 

@@ -13,7 +13,7 @@
 BuildRequires:  perl(Date::Manip)
 BuildRequires:  perl(Log::Dispatch)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-# See comment in the %%check section
+# See comment in the %check section
 # BuildRequires:  perl(Log::Log4perl) >= 0.23
 Requires:       perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo

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

Steps to Reproduce:
rebuild perl-Log-Dispatch-FileRotate-1.16-2.fc9.src.rpm
in a Fedora-9 hosted fedora-10 mock chroot.

Actual results:

Expected results:
rpmbuild not to parse comments.

Comment 1 Panu Matilainen 2008-06-03 09:33:47 UTC
This comes from redhat-rpm-config having added

%check %%check\
unset DISPLAY\

Despite looking like one, %check wasn't macro before but it is now, and macros
are expanded even in comments...

Comment 2 Jeff Johnson 2008-06-03 10:11:33 UTC
Overloading %check is foolishly naive, particularly since the %check script (like
every other build scriptlet) is templated exactly so that additional commands
can be added pre/post to spec file sections without the necessity to overload the
%check section marker.

Specifically, what could/should have been configured is
    %__spec_check_pre      unset DISPLAY;

Silly puppies gotta learn somehow I 'spose ...

Comment 3 Ralf Corsepius 2008-06-03 10:58:59 UTC
Panu, I don't know if a separate BZ exists, but I guess you are aware about 
that rpmbuild >= FC10 also has killed
%check ||:

a construct, which some packagers apply to stay bugward compatible with ancient
rpm versions. 

Comment 4 Jeff Johnson 2008-06-03 16:54:11 UTC
Ick. Let's invent syntax and randomly feed it to interpreters
and pretend that we're programmers rather than script kiddies!

Have fun!

Comment 5 Panu Matilainen 2008-06-04 07:18:20 UTC
Reassigning to redhat-rpm-config which is where this trouble comes from -
instead of overloading %prep, %build, %install and now %check, the build
templates system should be used.

Comment 6 Jon Masters 2008-06-09 17:05:08 UTC
Thanks Panu. Jeff's insightful comments aside, I didn't actually know %check
wasn't internally a macro, so when the request came to override its behavior in
the macros file, it seemed like a reasonable thing to do at the time. I'm on the
fence about r-r-c in general - I own it because I needed to make some changes in
the past and was the last one to touch it, but it might make more sense to hand
it over to Panu, since you maintain the other version of the same macros/etc.
that we are shipping and it would be nice to keep these things actually in sync.


Comment 7 Jeff Johnson 2008-06-13 18:41:04 UTC
Jon: No offense intended. But r-r-c history goes way way way back ....

... to sopwith, a wonderful hacker with perhaps a twisted sense of humor
who started the practice of overloading %foo section markers because
it pleased his buildsys needs (AS 2.1 with ancient rpm in place).

You dinna do more than follow pre-existing style as any professional does.

Don't take the "puppies" comment personally ...

Comment 8 Matt Domsch 2008-07-08 04:40:03 UTC
builds as of 2008-07-03, version 9.0.3-1.fc10.

Comment 9 Ralf Corsepius 2008-07-08 05:48:17 UTC
reopening, should not have been closed by Matt.

Comment 10 Matt Domsch 2008-09-05 13:59:50 UTC
builds 2008-08-24

Comment 11 Matt Domsch 2008-09-05 15:00:31 UTC
arrgg, re-opening.

Comment 12 Bug Zapper 2008-11-26 02:22:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 13 Bug Zapper 2009-11-18 12:32:22 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 14 Bug Zapper 2009-12-18 06:11:35 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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