Bug 1243128

Summary:	pam FTBFS during stage2 bootstrap - please, move autoreconf from %build to %prep
Product:	[Fedora] Fedora	Reporter:	Jaromír Cápík <jcapik>
Component:	pam	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	21	CC:	jcapik, ovasik, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-15 13:38:46 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:
Embargoed:
Bug Depends On:
Bug Blocks:	1224209

Description Jaromír Cápík 2015-07-14 20:37:08 UTC

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 10:01:50 UTC

Do you need this change to be done in F21? Isn't rawhide sufficient?

Comment 2 Jaromír Cápík 2015-07-15 13:38:46 UTC

As discussed online. We're ok with SRPM override in this case. Thanks for the push. I'm closing this bug.