Bug 1400641 - rpm srpm rebuild have different proggress with --target noarch then with other targets
Summary: rpm srpm rebuild have different proggress with --target noarch then with othe...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-01 16:59 UTC by jiri vanek
Modified: 2017-04-04 10:26 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-04 10:26:17 UTC
Type: Bug


Attachments (Terms of Use)

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.


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