Bug 1400641

Summary: rpm srpm rebuild have different proggress with --target noarch then with other targets
Product: [Fedora] Fedora Reporter: jiri vanek <jvanek>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: ignatenko, kardos.lubos, lkocman, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-04 10:26:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Comment 2 jiri vanek 2016-12-01 17:27:21 UTC
So the issue is casued by 
-target noarch 

sued by brew for srpm rebuild. Why the resultis failure is still in investigations

Comment 3 jiri vanek 2016-12-01 18:14:35 UTC
So this cryptic message means, that scriplet is on wrong place. It is candidate for closing, but worty to think about:
 - the rpmbuild passes unless --target noarch is specified
 - the message do not help

I think the rpm should
 - faill on all targets or on one (as this issue isarch-independent)
 - may come with better error message if scriplet order is incorrect

Fixed like this: http://pkgs.devel.redhat.com/cgit/rpms/java-1.7.1-ibm/commit/?h=supp-rhel-6.9&id=3e87407558b369ebdfe4711a195d0d0583763700

Note that it may be coincidence, but it was necessary to move scriplet 42 line sup as original error message suggetsed. But may be coincidence...

Still - the rpm should fail target-independently.

Comment 4 Fedora End Of Life 2017-02-28 10:42:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 5 Panu Matilainen 2017-04-04 10:26:17 UTC
The build.log is gone by now, original error message(s) or logs not included in the bug and the description is so full of typos its really hard to follow at all.

There are any number of reasons why rpmbuild could fail differently dependening on --target values, for perfectly valid reasons too. Then there are those obscure cases which fail due to funny macro interactions originating from the recursive spec parsing with buildarchs, but I'm not going to try and guess what the error and the cause might've been here.

In the future, please include the relevant information in the bug itself.