Bug 1243128 - pam FTBFS during stage2 bootstrap - please, move autoreconf from %build to %prep
pam FTBFS during stage2 bootstrap - please, move autoreconf from %build to %prep
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-bootstrap
  Show dependency treegraph
 
Reported: 2015-07-14 16:37 EDT by Jaromír Cápík
Modified: 2016-01-31 21:01 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-15 09:38:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaromír Cápík 2015-07-14 16:37:08 EDT
Description of problem:
During the stage2 bootstrap we experience FTBFS caused by the pam-1.1.8-pwhistory-helper.patch that modifies Makefile.am. This breaks the bootstrap procedure since we have no autotools in the stage2 when building Fedora from scratch. Fortunately this can be solved with minimal effort. You call the autoreconf -i in the %build phase. Would it be possible to move the autoreconf call from %build to %prep ? The %prep phase is executed during the stage1 source unpacking and patching using the host's rpmbuild and that should prevent the build from requiring autotools when building stage2 natively. In general, calling autoreconf -i in %prep is probably more correct as it does a very similar task to patching. It prepares the sources for building and allows applying patches on top of auto-reconfigured sources.

Version-Release number of selected component (if applicable):
pam-1.1.8-19.fc21

How reproducible:
always
Comment 1 Tomas Mraz 2015-07-15 06:01:50 EDT
Do you need this change to be done in F21? Isn't rawhide sufficient?
Comment 2 Jaromír Cápík 2015-07-15 09:38:46 EDT
As discussed online. We're ok with SRPM override in this case. Thanks for the push. I'm closing this bug.

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