FINAL_CONTENT_TYPE is set to printer/thinlocal rather than application/pdf, so tlclient thinks all jobs are raw jobs and refuses to show the printer selection dialog.
This is the same problem as reported in bug 5283, but I'm seeing this on Ubuntu servers. Reading the initial bug reports, I got the impression that this was limited to a Red Hat patch, but since this issue has shown up elsewhere, we should probably investigate if any other distributions are affected by this.
I've reported the problems with Ubuntu here:
This could be because of how >= CUPS 1.5 interprets the cupsFilter keyword in the thinlocal PPD.
> *cupsFilter: "source/type cost program"
In our case, this is:
> *cupsFilter: "application/pdf 0 -"
Jobs that match a cupsFilter rule are seemingly automatically converted to a destination type of "printer/thinlocal".
> D [06/May/2015:01:51:37 -0700] [Job 1] 1 filters for job:
> D [06/May/2015:01:51:37 -0700] [Job 1] - (application/pdf to printer/thinlocal, cost 0)
> D [06/May/2015:01:51:37 -0700] [Job 1] envp="FINAL_CONTENT_TYPE=printer/thinlocal"
There's also a new (since cups 1.5) cupsFilter2 keyword that looks like this:
> *cupsFilter2: "source/type destination/type cost program"
For us, this would look like this:
> *cupsFilter2: "application/pdf application/pdf 0 -"
If you set a destination type through a cupsFilter2, the correct destination type ends up in FINAL_CONTENT_TYPE, which is what we want. It's also possible to use cupsFilter together with cupsFilter2 - cups >=1.5 discards all cupsFilters if it encounters a cupsFilter2 in the PPD.
They've just blindly copied Red Hat's broken patch:
No comment as to why. Probably this generic changelog entry: "* Import Fedora
I've made a note of this in the platform specific notes.
Yay! They've dropped the patch in 1.7.5-6:
This version is in 16.04 (and later), but not the older 14.04. So most users should be unaffected.
I've removed the release note as it is very few users affected, and 14.04 is also almost EOL (april 2019).