Bug 288375

Summary:	net-print/cups-1.3.10-r2 fails to build unless pdtftops is on the path
Product:	Gentoo Linux	Reporter:	John R. Graham <john_r_graham>
Component:	[OLD] Printing	Assignee:	Printing Team <printing>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	Patch to existing ebuild corrects build failure.

Description John R. Graham gentoo-dev

2009-10-10 03:58:17 UTC

There is an issue with the parameters passed to the configure script for cups.  The --enable-pdftops parameter causes the build to make its own pdftops executable.  The --with-pdftops parameter is used to specify that an external pdftops executable should be used instead of the one that comes with cups.  When both are specified as in the current ebuild, apparently the latter wins out and the configure script will bail out unless a pdftops executable exists on the path.

I've included a patch that modifies the way configure is called and corrects the issue.  Also, I thought it prudent to preserve the ability to select an external pdftops; I've added a new local USE flag that controls this.

The ebuild rev shouldn't need to be bumped as anyone who hasn't encountered  this issue (i.e., must have pdftops from another source; several packages appear to provide this executable) need not rebuild cups.

- John

Comment 1 John R. Graham gentoo-dev

2009-10-10 03:59:34 UTC

Created attachment 206612 [details, diff]
Patch to existing ebuild corrects build failure.

Comment 2 John R. Graham gentoo-dev

2009-10-10 04:09:02 UTC

Note that cups-1.3.11 and cups-1.4.1 also exhibit this issue.

- John

Comment 3 John R. Graham gentoo-dev

2009-10-13 09:11:30 UTC

Discovered that this issue was being caused on my machine by a corrupt copy of app-text/poppler-utils.  pdftops *should* have been provided by poppler-utils.  Closing as INVALID.

- John