we changed postscript/cups behavior recently for boards & the sdk

I don't think we changed anything recently around this part, did we? And I see 'cups' is getting emerged (as expected) before 'cups-filters', so 'cups-config' tool should be present.

Oh but wait, this is the build for the x86-generic board. Did we remove the SDK's cups ebuild (and therefore the common chroot /usr/bin/cups-config)? Maybe cups-filters was pointing at that version (not the /build/${BOARD}/usr/bin/cups-config).

The whole (non-pkg-config) 'cups-config' thing is pretty fragile anyway...

yes, we dropped cups from the sdk itself.  if the target board was using `cups-config`, then it was broken already, and we were getting lucky.

i'll post a CL.

Looks like somehow cups got disabled in icedtea, which we were previously (implicitly) relying on for pulling in cups-config:

https://uberchromegw.corp.google.com/i/chromiumos/builders/chromiumos-sdk/builds/7497/steps/InitSDK/logs/stdio

[ebuild  N     ] dev-java/icedtea-bin-7.2.5.3:7  USE="-X -alsa -cjk -cups -doc -examples -nsplugin -selinux -source -webstart" 0 KiB

But how'd that happen? I still see this:

m/master:profiles/targets/sdk/package.use:34:dev-java/icedtea-bin cups

Anyway, we should probably get cups-filters to look at the proper cross-targeted cups-config, not the SDK cups-config.

Just saw #5. Indeed.

This broke us:

https://chromium-review.googlesource.com/391136

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ea9367df921a8dc4cd1e96b14f19795c56f12e41

commit ea9367df921a8dc4cd1e96b14f19795c56f12e41
Author: Mike Frysinger <vapier@chromium.org>
Date: Tue Oct 11 22:12:36 2016

cups-filters: use correct cups-config script

Rather than execute the native `cups-config`, make sure we use the
target config script instead.

BUG= chromium:654890 
TEST=`emerge-samus cups-filters` works again after `sudo emerge -C cups`

Change-Id: I0c639c245e27112414b7e4176b6b3334bfbcb08f
Reviewed-on: https://chromium-review.googlesource.com/396898
Commit-Ready: Mike Frysinger <vapier@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

[modify] https://crrev.com/ea9367df921a8dc4cd1e96b14f19795c56f12e41/chromeos/config/env/net-print/cups-filters

Should be fixed. I think there's at least one chromiumos-sdk build still in the pipeline using the unpatched cups-filters, but after than things should be OK I think.

There is a new failure on Chromiumos-sdk.

cups-filters-1.8.2-r1: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.     -O2 -march=i686 -pipe -O2 -pipe -march=i686 -mfpmath=sse -mmmx -msse -msse2 -msse3 -g       -clang-syntax -Wall -pedantic -std=gnu99 -D_GNU_SOURCE -c -o pdftops-pdftops.o `test -f 'filter/pdftops.c' || echo './'`filter/pdftops.c
cups-filters-1.8.2-r1: filter/pdftops.c:262:28: error: use of undeclared identifier
cups-filters-1.8.2-r1:       'CUPS_PDFTOPS_RENDERER'
cups-filters-1.8.2-r1:   renderer_t    renderer = CUPS_PDFTOPS_RENDERER; /* Renderer: gs or pdf...
cups-filters-1.8.2-r1:                            ^
cups-filters-1.8.2-r1: 1 error generated.

I guess I'll reopen.

@10: That's strange. It looks like this build is actually happening with USE="-postscript". That's not really a build we've been testing much now, and it's possible something is screwed up. I can't reproduce that yet locally, but maybe I need to sync with the latest.

It happens in the waterfall.
https://uberchromegw.corp.google.com/i/chromiumos/builders/chromiumos-sdk/builds/7502/steps/SDKTest/logs/stdio

I've tracked the problem to the same root cause, essentially. cups-filters's configure.ac is truly broken; it's not looking for the cross-targeted binaries (like '/build/$BOARD/usr/bin/pdftops'), but it doesn't even *realize* that it didn't find them properly. See:

cups-filters-1.8.2-r1: checking for pdftops... ./configure: line 19674: pdftops: command not found
cups-filters-1.8.2-r1: no
cups-filters-1.8.2-r1: checking for pdftocairo... ./configure: line 19774: pdftocairo: command not found
cups-filters-1.8.2-r1: no
cups-filters-1.8.2-r1: checking for acroread... ./configure: line 19841: acroread: command not found
cups-filters-1.8.2-r1: no

but this doesn't kill the configure step. We only fail later. That's because this construct doesn't actually abort when we hit the AC_MSG_ERROR():

    AC_PATH_PROG(CUPS_PDFTOPS, [pdftops], [AC_MSG_ERROR([Required pdftops is missing. Please install CUPS developer packages.])])

So the problem is 2-fold:

(a) cups-filters isn't picking up the right helper binaries any more (it was always broken, but exacerbated by the SDK changes)
(b) cups-filters doesn't give clear feedback when it can't find the right binaries

that's just not how AC_PATH_PROG() works :).  the 3rd arg is the fall back value, not "execute this when not found" code.  so it's setting pdftops variable to the error code which makes no sense.  usually people use a form like:

  AC_PATH_PROG([CUPS_PDFTOPS], [pdftops], [no])
  if test "$ac_cv_path_CUPS_PDFTOPS" = "no"; then
    AC_MSG_ERROR(...)
  fi

the next question is, why does the build want these programs ?  is it going to run them at build time ?  if so, that's not going to work, even if we told them to look in /build/$BOARD/...  if it's because it wants them at runtime, then a $PATH search doesn't make much sense ... it should just hardcode "pdftops" and then execvp() the program (do the $PATH look up at runtime).

@14: Understood on most accounts.

"the next question is, why does the build want these programs ?"

Mostly, they don't want to run them at build time, although for 'pdftops' ./configure is trying to figure somethings out about the supported flags.

Except for the one exception above, then I think we just want to use the hardcode paths like --with-pdftops-path=/usr/bin/pdftops and --with-gs-path=/usr/bin/gs. (The latter of those two will resolve issue 655424, BTW.)

Oh, I see that you were suggesting switching to runtime $PATH lookup (i.e., execvp() instead of execve()). That would also fix issue 655424.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/5b4b173ac81b413d8685aa8aea12f4abaf655b28

commit 5b4b173ac81b413d8685aa8aea12f4abaf655b28
Author: Brian Norris <briannorris@chromium.org>
Date: Thu Oct 13 20:19:32 2016

net-print/cups-filters: don't let autoconf path-search for buildhost binaries

This is a bit of a hack to prevent ./configure from doing an
AC_PATH_PROG() search for pdftops, pdftocairo, or gs. For those
searches, autoconf is incorrectly looking for a binary on the build
system, not on the targeted system. This used to happen to work OK, but
it's not correct -- and we recently removed these from the build
toolset.

cups-filters already supports providing the exact path, to skip the
AC_PATH_PROG() search. We can use that now to skip some of these
searches. We should really just patch out the path search entirely
though, since we can do that perfectly well at runtime (these are
executed with execvp()/execvpe() anyway).

One hiccup with all this: configure.ac still tries to run the host
binary (which may or may not exist) like this:

	AC_MSG_CHECKING([whether pdftops supports -origpagesizes])
	AS_IF([`$CUPS_PDFTOPS -h 2>&1 | grep -q -- -origpagesizes`], [
	....
	AC_MSG_CHECKING([whether pdftops supports -r])
	AS_IF([`$CUPS_PDFTOPS -h 2>&1 | grep -q -- '-r '`], [
	....

That's wrong, at least for cross-compilation.

BUG= chromium:654890 
TEST=`emerge --unmerge poppler` on build system (i.e., clean slate); make sure
     `emerge-${BOARD} cups-filters` still works (both with USE=postscript and
     USE=-postscript)

Change-Id: I947720c675e3e922f12cf58479b4199b00ad535f
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/398261
Reviewed-by: Sean Kau <skau@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[rename] https://crrev.com/5b4b173ac81b413d8685aa8aea12f4abaf655b28/net-print/cups-filters/cups-filters-1.8.2-r3.ebuild

This job has the changes, and we can be sure there are no more failures if it passes:

https://uberchromegw.corp.google.com/i/chromiumos/builders/chromiumos-sdk/builds/7506

Will leave open until then.

Working on filing an upstream bug to cover this (and bug 655424) now.

The build from #19 passed building cups-filters, at least. I think we're good.

Filed this upstream for fixing the various problems noticed with cups-filters:

https://bugs.linuxfoundation.org/show_bug.cgi?id=1378