CUPS 1.6 has major incompatible changes. Do not use CUPS 1.6.1 on stable Ubuntu releases

CUPS 1.6 will have major incompatible changes:

"Transition all non-Mac filters to OpenPrinting"
http://www.cups.org/str.php?L3930
"Deprecate and stub out image file support"
http://www.cups.org/str.php?L3931

"Drop serial and parallel backends"
http://www.cups.org/str.php?L3935

"Drop support for CUPS Browsing and Polling"
http://www.cups.org/str.php?L3922
"CUPS browsing is deprecated and scheduled for removal ... after 1.5.x"
http://www.cups.org/str.php?L3889
"Bonjour is the replacement"
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22Why+is+CUPS+browsing+deprecated%22

"Deprecate PPD functions"
http://www.cups.org/str.php?L3926
"Deprecate the PPD compiler"
http://www.cups.org/str.php?L3927
"Support for PPDs is not going away in CUPS 1.6"
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22CUPS+1.6+and+PPD%22

In general for changes in the upcomming CUPS version 1.6 see
http://www.cups.org/roadmap.php?VERSION=1.6

Related to this is "PDF as Standard Print Job Format", see

http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format

A beta version of the new OpenPrinting CUPS Filters package
is released. See
http://www.cups.org/str.php?L2897
and
http://www.cups.org/str.php?L3930

Not an incompatible change but a noteworthy change:
In CUPS 1.6 the libusb-based "usb" backend will be built by default, see
http://www.cups.org/str.php?L2890
--------------------------------------------------------------------------
till.kamppeter 15:20 Feb 13, 2012

Mike, can you also change the build system so that
the libusb-based "usb" backend will get built by default?

The libusb-based backend has once more functionality, especially bi-di
works with all printers, without any manufacturer-wise restrictions,
and second, it works also in systems with usblp module present, as it
detaches the module from the printer before communicating and reattaches
the module after finishing the communication. This means that it
always "just works". The usblp-based backend is now only a fallback
solution for systems without libusb.
--------------------------------------------------------------------------

Probably of interest related to Samba and printing in Windows environment:
http://www.cups.org/str.php?L2900
---------------------------------------------------------------------------
Given that the Windows drivers are now unsupported, we will no longer
be investing time in new features or documentation for cupsaddsmb.
---------------------------------------------------------------------------

FYI,
some links to reports, discussions and replies from Michael Sweet:

(German only):
http://www.heise.de/newsticker/meldung/CUPS-1-6-unterstuetzt-Linux-schlechter-1435234.html

(German only):
http://www.heise.de/open/artikel/Kernel-Log-Apple-verschlankt-Cups-1435037.html

http://www.heise.de/open/news/foren/S-Und-hier-ist-eine-Antwort-des-Entwicklers/forum-222028/msg-21443591/read/

http://cyberelk.net/tim/2012/02/06/cups-1-6-changes-ahead/

http://lists.fedoraproject.org/pipermail/devel/2012-January/161306.html

http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002412.html

http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002426.html

http://lists.linuxfoundation.org/pipermail/printing-architecture/2012/002425.html

Probably only of interest for exceptional use-cases
http://www.cups.org/str.php?L3999
---------------------------------------------------------------------------
... the PHP module has been removed from CUPS 1.6 and later.
---------------------------------------------------------------------------

Regarding "Drop support for CUPS Browsing and Polling" (see comment #0)
Ludwig Nussel suggested an interesting idea how to provide backward
compatibility in this case:

When a CUPS <= 1.5.x server should be replaced by a CUPS >= 1.6.x server
in a bigger network printing environment with arbitrary client systems,
the existing client systems expect to get CUPS Browsing information
as it had worked all the time up to CUPS <= 1.5.x.

Of course the admin could "just upgrade" all those arbitrary
client systems with CUPS >= 1.6.x - but perhaps he might not like it ;-)

To provide CUPS Browsing information to the clients
a separated CUPS-Browsing-daemon could be implemented
that gets print queue information from a CUPS >= 1.6.x server
and creates CUPS Browsing information.

The crucial point is that such a CUPS-Browsing-daemon is separated
software and not a SUSE-specific add-on-hack for CUPS 1.6.x
so that our CUPS 1.6.x is still in full compliance with upstream
and admins who don't need or want such a CUPS-Browsing-daemon
don't need to install its RPM package.

Related to "Drop support for CUPS Browsing and Polling"
the display of remote printers shared via LDAP, or SLP
will also be dropped in CUPS 1.6:

"Drop support for custom LDAP/SLP printer schemas"
http://www.cups.org/str.php?L3923

Regarding comment #9 "a separated CUPS-Browsing-daemon":

The CUPS Browse Protocol is described at
http://www.cups.org/documentation.php/doc-1.5/spec-browsing.html

What TYPE is can be found in the cups-1.5.3 sources in cups/cups.h
-----------------------------------------------------------------------------
typedef unsigned cups_ptype_t; /**** Printer type/capability bits ****/
enum cups_ptype_e /**** Printer type/capability bit constants ****/
{ /* Not a typedef'd enum so we can OR */
  CUPS_PRINTER_LOCAL = 0x0000, /* Local printer or class */
  CUPS_PRINTER_CLASS = 0x0001, /* Printer class */
  CUPS_PRINTER_REMOTE = 0x0002, /* Remote printer or class */
  CUPS_PRINTER_BW = 0x0004, /* Can do B&W printing */
  CUPS_PRINTER_COLOR = 0x0008, /* Can do color printing */
  CUPS_PRINTER_DUPLEX = 0x0010, /* Can do duplexing */
  CUPS_PRINTER_STAPLE = 0x0020, /* Can staple output */
  CUPS_PRINTER_COPIES = 0x0040, /* Can do copies */
  CUPS_PRINTER_COLLATE = 0x0080, /* Can collage copies */
  CUPS_PRINTER_PUNCH = 0x0100, /* Can punch output */
  CUPS_PRINTER_COVER = 0x0200, /* Can cover output */
  CUPS_PRINTER_BIND = 0x0400, /* Can bind output */
  CUPS_PRINTER_SORT = 0x0800, /* Can sort output */
  CUPS_PRINTER_SMALL = 0x1000, /* Can do Letter/Legal/A4 */
  CUPS_PRINTER_MEDIUM = 0x2000, /* Can do Tabloid/B/C/A3/A2 */
  CUPS_PRINTER_LARGE = 0x4000, /* Can do D/E/A1/A0 */
  CUPS_PRINTER_VARIABLE = 0x8000, /* Can do variable sizes */
  CUPS_PRINTER_IMPLICIT = 0x10000, /* Implicit class */
  CUPS_PRINTER_DEFAULT = 0x20000, /* Default printer on network */
  CUPS_PRINTER_FAX = 0x40000, /* Fax queue */
  CUPS_PRINTER_REJECTING = 0x80000, /* Printer is rejecting jobs */
  CUPS_PRINTER_DELETE = 0x100000, /* Delete printer @since CUPS 1.2/Mac OS X 10.5@ */
  CUPS_PRINTER_NOT_SHARED = 0x200000, /* Printer is not shared @since CUPS 1.2/Mac OS X 10.5@ */
  CUPS_PRINTER_AUTHENTICATED = 0x400000,/* Printer requires authentication @since CUPS 1.2/Mac OS X 10.5@ */
  CUPS_PRINTER_COMMANDS = 0x800000, /* Printer supports maintenance commands @since CUPS 1.2/Mac OS X 10.5@ */
  CUPS_PRINTER_DISCOVERED = 0x1000000, /* Printer was automatically discovered and added @since CUPS 1.3/Mac OS X 10
.5@ */
  CUPS_PRINTER_SCANNER = 0x2000000, /* Scanner-only device @since CUPS 1.4/Mac OS X 10.6@ */
  CUPS_PRINTER_MFP = 0x4000000, /* Printer with scanning capabilities @since CUPS 1.4/Mac OS X 10.6@ */
  CUPS_PRINTER_OPTIONS = 0x6fffc /* ~(CLASS | REMOTE | IMPLICIT | DEFAULT | FAX | REJECTING | DELETE | NOT_SHA
RED | AUTHENTICATED | COMMANDS | DISCOVERED) @private@ */
};
-----------------------------------------------------------------------------

What STATE is can be found in the cups-1.5.3 sources in cups/ipp.h
-----------------------------------------------------------------------------
typedef enum ipp_pstate_e /**** Printer states ****/
{
  IPP_PRINTER_IDLE = 3, /* Printer...

There is a typo in comment #9:
"Regarding comment #9" should read "Regarding comment #7".

Regarding sending CUPS Browsing info as UDP broadcast:

Sending CUPS Browsing info as UDP broadcast via bash fails (even as root):
-------------------------------------------------------------------------------
echo '2 3 ipp://PRINT.SERVER.IP.ADDRESS:631/printers/QUEUE-NAME "Location"
"Description" "Make and Model" lease-duration=300 job-sheets=none,none'
>/dev/udp/HOST:BROADCAST:IP:ADDRESS/631

-bash: connect: Permission denied
-bash: /dev/udp/HOST:BROADCAST:IP:ADDRESS/631: Permission denied
-------------------------------------------------------------------------------

I don't know how to set SO_BROADCAST (see "man 7 socket") via bash
so that I use this perl script (the $data assignment is one line):
--------------------------------------------------------------------------------
#!/usr/bin/perl

use strict;
use IO::Socket;

my $bcaddr = 'HOST:BROADCAST:IP:ADDRESS';
my $port = 631;
my $data = '2 3 ipp://PRINT.SERVER.IP.ADDRESS:631/printers/QUEUE-NAME "Location"
"Description" "Make and Model" lease-duration=300 job-sheets=none,none';

socket(sock, PF_INET, SOCK_DGRAM, getprotobyname("udp")) or die "socket:$@";
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, 1) or die "setsockopt:$@";
my $dest = sockaddr_in($port,inet_aton($bcaddr));

send(sock,$data,0,$dest) or die "send():$!";
--------------------------------------------------------------------------------

An overview regarding the changes:
http://www.cups.org/documentation.php/doc-1.6/whatsnew.html

It seems at least CUPS version 1.6.1 is not yet ready for normal
usage because it has major issues, see for example

http://www.cups.org/str.php?L4159
"For a raw queue pointing to a remote CUPS server
 via dnssd URI the options of the server's PPD
 are not shown by print dialogs"

http://www.cups.org/str.php?L4178
"CUPs 1.6.x server does not send PPD/option info to CUPS 1.6.x client"

http://www.cups.org/str.php?L4180
"CUPS 1.6.1 crashes on shutdown"

http://www.cups.org/str.php?L4183
"CUPS 1.6.1 crashes on startup when DNS-SD host name
 cannot get determined via Avahi"

http://www.cups.org/str.php?L4192
"CUPS daemon crashes on bad entry in cupsd.conf"

One more related to comment #12:

http://www.cups.org/str.php?L4200
"cupsd crashed with SIGABRT in __assert_fail_base()"

One more related to comment #12:

http://www.cups.org/str.php?L4213
"CUPS crashes on shutdown when taking down Avahi threaded poll"

Furthermore:

A general comment from the CUPS author regarding CUPS Browsing:
http://www.cups.org/str.php?L4206
---------------------------------------------------------------------
Sorry, CUPS browsing is gone for good. There are too many problems
with the CUPS browsing protocol in modern network environments to
continue using/supporting it.

CUPS 1.6 supports DNS-SD for automatic client discovery of printers,
and future versions of CUPS will also support LDAP and SLP.
Unfortunately, it may take some time for desktop toolkits to support
dynamic printers, but the APIs are there in CUPS 1.6...
---------------------------------------------------------------------

One must take some time and wait until desktop toolkits adapted
to the CUPS 1.6 APIs and provide support for dynamic printers
before one can use CUPS > 1.5.x in "real-world environments".

It seems CUPS introduced a chicken and egg issue:

If desktop toolkits use CUPS 1.6 APIs to get dynamic printers support
they need CUPS 1.6 installed on end-users machines but CUPS 1.6 cannot
be used on end-users machines until desktop toolkits use CUPS 1.6 APIs.

It seems one needs to do a "big jump" and upgrade both CUPS and the
desktop toolkits at the same time.

To prepare for such a "big jump" experienced users must test it
in advance before usual end-users get it.

To let users test it, I think we should have a new OBS project
whereto CUPS 1.6 and other related packages can be submitted
e.g. something like a "Printing:Playground" project to make
the distinction obvious that "Printing" is meant for (relatively)
stable stuff that can be used without expecting major issues
in "real-world environments" (e.g. on SLE11) but in contrast
"Printing:Playground" is meant for venturous testers who expect
even unexpected issues.

Printing:Factory if we try to respect what's done on obs.

My remark here is how debian like distribution have treated the problem? And thus are the only one distribution actually able to print correctly, compared especially to our 12.2 release?

So if we still want to get cups 1.6 into 12.3 now would be a good time to submit it.

I do not want to get CUPS 1.6 in openSUSE 12.3
unless the openSUSE community agreed how to deal
with all those issues above.

Till Kamppeter who maintains CUPS in Ubuntu
re-introduced Browsing for CUPS 1.6, see
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1061063
and
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1061069

Basically this means CUPS 1.6 "as is" can really not be used
for convenient printing in existing Linux networks (perhaps except
very small networks with only a few clients and one or two printers).

It seems that even with CUPS Browsing re-introduced in Ubuntu,
a "client-only" config (i.e. ServerName set in client.conf)
does no longer work with CUPS "1.6+Browsing" in Ubuntu, see
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1069671

I don't know if a "client-only" config still works
with plain upstream CUPS 1.6 without any patch.

(In reply to comment #18)
> I do not want to get CUPS 1.6 in openSUSE 12.3
> unless the openSUSE community agreed how to deal
> with all those issues above.

Ok. If it's not ready then it's not ready. Maybe the issue could also be brought up on the Factory list. I suppose many are not aware of the reasons why we can't upgrade cups yet.

I will post a notification on <email address hidden>

If someone requests an upgrade to a new version of a package
but is not aware of such major changes, the request is unfounded
because the requester does not care what he gets by the new version.

Regarding comment#15 "Printing:Playground"
and comment#16 "Printing:Factory":

I think we do not need a new project only for CUPS 1.6.

I think it is simpler and sufficient to have CUPS 1.6 as separated
OBS source package "cups16" in the "Printing" project.

The cups16.spec file would build binary RPMs with same names
as the package "cups" does, i.e. cups16.spec would contain:
--------------------------------------------------------------------
Name: cups
...
Version: 1.6.xxx
...
%package libs
...
%package client
...
%package devel
...
%package ddk
--------------------------------------------------------------------
plus appropriate RPM requirements and conflicts to make sure
that either CUPS <= 1.5 packages or CUPS >= 1.6 packages
can be installed on an end-user system.

This way the OBS source packages "cups" and "cups16" in "Printing"
would build binary RPMs with same names but with different versions
(name-1.5...rpm versus name-1.6...rpm).

Additionally CUPS >= 1.6 requires the filters of the cups-filters
software that is provided by OpenPrinting.org, see comment#2.

My plans are to patch the CUPS daemon to dynamically create queues to remote printers which are broadcasted via Bonjour, making CUPS behaving as before for the end user, but using Bonjour as broadcasting protocol. See

https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-cups-bonjour-browsing

Alternatively, I could create a separate daemon which listens to Bonjour broadcasts of printers and creates/removes CUPS queues pointing to the remote printers automatically. This extra daemon would eliminate the need of submitting any patch to CUPS upstream and carrying it as distro patch if upstream reject it. The extra daemon I could host as part of the cups-filters package and packagers of distros could put the daemon into a separate binary to allow admins to opt out of the extra daemon.

Regarding comment#22 "notification on <email address hidden>":

See my "Opinion poll: CUPS 1.6 version upgrade"
http://lists.opensuse.org/opensuse-factory/2012-11/msg00468.html

Not much response up to now...

Regarding comment#20 "client-only config does no longer work with CUPS 1.6":

https://www.cups.org/str.php?L4231
"From CUPS 1.6.x on using a remote CUPS server via client.conf stopped working"

Only for venturous testers:

I made a first test version of CUPS 1.6.1
(without any fix of the issues in comment#12 and others)
as packages "cups161" and "cups" in "home:jsmeix"
for openSUSE 11.4/12.1/12.2 and SLE-11 SP1/SP2

See
https://build.opensuse.org/package/view_file?expand=1&file=cups.changes&package=cups161&project=home%3Ajsmeix

Read
https://build.opensuse.org/project/show?project=home%3Ajsmeix
in particular note
----------------------------------------------------------------
This is my personal playground where
packages could be severely incompatible
with official openSUSE packages.
...
If you are unexperienced with manual
installation, do not install any package
from "home:jsmeix".
...
The packages in the "home:jsmeix" project
are only for testing, without any guarantee
or warranty, and without any support.
As an extreme example, this means if your
complete computer center crashes because
of those packages, it is only your problem.
----------------------------------------------------------------

On my SLE-11 SP1 workstation I can print with it
to print queues on SLE-11 servers that run CUPS 1.3.9
and I can print PostScript files on my locally connected
(via USB) HP LaserJet 1220 PostScript printer
and I can print to my LaserJet 1220 from
an openSUSE 12.2 client that runs CUPS 1.5.3 and
from a SLED11-SP2 client that runs CUPS 1.3.9.

Printing other file types (e.g. PDF or plain text)
does not yet work because currently there
is no "cups-filters" package available,
see "CUPS 1.6 has major incompatible changes" at
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell

Right now I picked up
https://www.cups.org/str.php?L4233
which contains
----------------------------------------------------------------------------
mike: 07:10 Dec 17, 2012
...
There will be more 1.6.x releases (1.6.2 will be coming out fairly soon).

CUPS 1.7 will likely not come out until next summer...
----------------------------------------------------------------------------

Most of the above issues in CUPS (comment#12 and subsequent comments)
are fixed in CUPS 1.6.2.

For venturous testers:
I made CUPS 1.6.2 as source package "cups162" in "home:jsmeix"
that results binary RPMs named cups[...]-1.6.2-[...].rpm at
http://download.opensuse.org/repositories/home:/jsmeix/
for openSUSE 12.1/12.2/12.3 and SLE-11/SP1/SP2
Carefully read
https://build.opensuse.org/project/show?project=home%3Ajsmeix
and the RPM changelog
https://build.opensuse.org/package/view_file?expand=1&file=cups.changes&package=cups162&project=home%3Ajsmeix

Since CUPS 1.6. you usually need the "cups-filters" package
(unless you only print PostScript files on PostScript printers)
which I provide currently only in a very unfinished way
only for venturous testers in the "Printing" project and also
in "home:jsmeix" (it does not build for older openSUSE versions).

FYI:
A minor issue in CUPS 1.6.2:
https://www.cups.org/str.php?L4300
"When restarting avahi-daemon while CUPS is running, CUPS looses connection"
Workaround: After restarting Avahi also restart CUPS.

Regarding comment#7
"a separated CUPS-Browsing-daemon could be implemented"
and comment#15
"desktop toolkits use CUPS 1.6 APIs to get dynamic printers support":

For background information and reasoning what could be done
until print dialogs natively support DNS-SD browsing, see
the "An idea how to provide CUPS Browsing for CUPS 1.6" thread:

https://www.cups.org/newsgroups.php?gcups.general+T+Q%22An+idea+how+to+provide+CUPS+Browsing+for+CUPS+1.6%22

In particular see Till Kamppeter's proposal for
an "universal cups-browsed" in this thread.

Initially Till had implemented some of the "universal cups-browsed"
functionality in the cups-filters software.

Tim Waugh recently added support for BrowsePoll, and CUPS Browsing
for sharing and discovery to the cups-browsed program in cups-filters.

For the current state and details of the cups-browsed
see the NEWS and README files in the cups-filters sources.

The dowload URL for the cups-filters package is
http://www.openprinting.org/download/cups-filters/

For anyone willing to work on it I finished the migration stuff in Gentoo so it should be quite easy to copy&compare the changes (I even can use our internal printing system with it :-)).

It should be fairly easy to package but I sadly don't have the time for it now.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-print/cups/cups-1.6.3-r2.ebuild?revision=1.1&view=markup
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-print/cups-filters/cups-filters-1.0.35.ebuild?revision=1.2&view=markup

FYI for venturous testers:

I made CUPS 1.7rc1 (see http://www.cups.org/)
as source package "cups17rc1" in "home:jsmeix".
Note what I wrote in comment#28 above:
https://bugzilla.novell.com/show_bug.cgi?id=735404#c28

Currently cups-filters fails to build for openSUSE_Factory.
I am afraid currently I do not have time to work on it.

Tomas Chvatal,
regarding cups-filters:

As far as I see it fails to build for openSUSE_Factory
because we have poppler 0.23 there and in that poppler
version there have been changes in some poppler API
(in particular in poppler/Error.h regarding Goffset
in setErrorCallback) that require adaption of cups-filters.

But I have not at all any internal knowledge about poppler
so that I could be totally wrong here.

You may have a look at my preliminary attempts to try to fix it
in OBS home:jsmeix:branches:Printing cups-filters
(my current fix is still incomplete).

As far as I see there are no incompatible changes in poppler API
mentioned in poppler's ChangeLog.
Therefore I wonder if what cups-filters uses from poppler
is actually meant as public stable API from poppler?
Perhaps cups-filters uses private internal poppler API
that can change at any time as poppler upstream likes.
In this case cups-filters would need to get a major clean up
so that it only uses well known stable APIs.

But again - I have not at all any internal knowledge
about poppler so that this all is only blind guess.

I think we should get in contact with cups-filters upstream
(see the cups-filters README file regarding "Report bugs to")
to get the issue fixed properly and thoroughly together
with upstream.

The cups changes external api with no documentation on each minor bump. With patch bumps they manage to often break abi compatibility so this is quite common in the library.

The problem is on poppler side and there is nothing to expect apart few tweaks, ike the Goffset thingy in error callbacks, then they changed few more places which need to be adjusted.

Easiest path to contact upstream is join irc channel #openprinting at freenode server and speak with tkamppeter who is the coordinating guy from canonical.

Anyway you probably noticed I am too listed in AUTHORS so don't worry I already told him about the api breakage and it will be fixed :)

Tomas Chvatal,
regarding your cups-filters submitrequest 185049:

There you wrote (excerpt):
---------------------------------------------------------------------------
I didn't fix the poppler-0.23 compatibility because Timm is already
on it and will simply release 1.0.36 at some near future point.
---------------------------------------------------------------------------
Great!

Then let's wait for cups-filters 1.0.36.

FYI:
I really want that cups-filters is built for as many
older openSUSE versions as possible with reasonable effort.
Currently it builds for 12.2 and 12.3. and I like to keep that
for cups-filters 1.0.36 (if possible with reasonable effort).
The reason is that testers who have older openSUSE versions
could switch to CUPS 1.7.x plus cups-filters >= 1.0.36
and switch back to traditional CUPS 1.5.4 if needed.
Such testing is mandatory for me to feel a bit more on the safe side.

Tomas Chvatal,

I made you maintainer of cups-filters in the Printing project
so that you can directly work on it there.

FYI:
Regarding CUPS API changes:
Talk to CUPS upstream to discuss issues where they belong.
We (i.e. openSUSE) never changed the CUPS API.
You may read my comment#15 above and you may read my postings
at CUPS upstream to get a basic understanding about my personal
opinion in general regarding incompatible changes.
As long as I am basically the only one from openSUSE who is "visible"
at CUPS upstream, you cannot excpect that CUPS upstream cares much
about what openSUSE may like to have.

No need for special privs on me. As a factory-maint group member I can access every single devel project, if I want. We just for obvious reasons don't do so unless really needed (long-time breakages and no maintainer activity, etc...)

Anyway the bug about it is on upstream https://bugs.linuxfoundation.org/show_bug.cgi?id=1144

And the plan is to have it in next version fixed, so lets just wait a bit for the .36.

Also if the release will be delayed we can track the upstream SCM to grab the patch http://bzr.linuxfoundation.org/loggerhead/openprinting/cups-filters/changes/.

Tomas Chvatal,

I would apprecitate it if you as one of the cups-filters authors
would accept "official" maintainership of cups-filters.

This does of course not mean that now it is only you who must do
all the work for cups-filters - I am also its maintainer.

I think it makes a difference if you act as factory-maint group member
on arbitrary packages or if you act as one of the "officially" specified
maintainers for a particular package.

FYI:

I tried to compile cups-filters-1.0-20130802
(i.e. the daily snapshot dated 2013 August 02)
that fixes in particular
https://bugs.linuxfoundation.org/show_bug.cgi?id=1144

But compile fails with a new issue, see
https://bugs.linuxfoundation.org/show_bug.cgi?id=1145

I will now try to go back to cups-filters-1.0.35
and add a patch that only fixes
https://bugs.linuxfoundation.org/show_bug.cgi?id=1144

In OBS home:jsmeix:branches:Printing cups-filters
I am now back to cups-filters-1.0.35
with BZR_revision_7085_7084.diff that should fix
https://bugs.linuxfoundation.org/show_bug.cgi?id=1144

But currently OBS does not build it for openSUSE_Factory
(it is currently blocked by some other packages)
so that I don't know if it actually builds now
for openSUSE_Factory

Tomas Chvatal,

In OBS home:jsmeix:branches:Printing cups-filters
I have added your support for systemd according
to what you did in home:scarabeus_iv cups-filters

With submitrequest 185617 I submitted cups-filters
from home:jsmeix:branches:Printing to Printing.

OBS still could not build it for openSUSE_Factory.
I can only hope that BZR_revision_7085_7084.diff actually works.

Tomas Chvatal,
many thanks for your cups-filters version upgrade to 1.0.36
in the OBS Printing project!

Mainly for my own information:

Regarding Ghostscript version upgrade and cups-filters:

http://www.ghostscript.com/doc/current/History9.htm#Version9.09
reads
------------------------------------------------------------------------------
Version 9.09 (2013-08-21)

This is the eighth full release in the stable 9.x series,
and is primarily a maintenance release.
.
.
.
2013-07-30 20:29:01 +0200
Till Kamppeter <email address hidden>
...
Moved CUPS filters gstoraster and gstopxl to cups-filters

As Ghostscript's CUPS filters gstoraster and gstopxl need changes to
allow PPD-less printing on IPP printers and these changes introduce
a new dependency on the libcupsfilters library of the cups-filters
project, we have moved these filters to cups-filters now.
------------------------------------------------------------------------------

Since Ghostscript 9.09 it may require (to some extent) cups-filters
but no hard RPM "Requires" but perhaps a RPM "Recommends", compare
https://bugzilla.novell.com/show_bug.cgi?id=776080#c39

Ghostscript 9.09 causes a regression for "gv" see
http://bugs.ghostscript.com/show_bug.cgi?id=694534

Regarding Ghostscript 9.09 regression in above comment#44:

It seems this will be fixed soon in Ghostscript 9.10, see the
"Ghostrscript/GhostPDL 9.10 Release Candidate 1"
announcement on <email address hidden>
http://ghostscript.com/pipermail/gs-devel/2013-August/009504.html

You are welcome.

All the patches are now upstreamed, the .unit file will be included in the tarball next time, so we can drop all the extra files we ship with it.

WRT ghostscript:
I would recommend just requiring >= 9.9 in the cups-filters because otherwise we are colliding and if users add cups-filters from printing they can also get new ghostscript.

13.1:
Do you think it would be possible to have this mergable before the beta1 freeze which happens on 2013-09-19. Gnome guys already introduce patches for cups-1.5 compat and this might ease things up, even if there are some triv regressions.

Currently I work on the Ghostscript 9.10 Release Candidate 1.

But I think we cannot do the "big jump" (see comment#15) for 13.1
because there is at least one more regression when upgrading CUPS:

The YaST printer module.
In particular its "printing via network" and "share printers" stuff
only works up to CUPS 1.5 because it needs CUPS Browsing.
I have to do major work for the YaST printer module to let it
use the cups-browsed from cups-filters for CUPS >= 1.6.

Furthermore there is Dominique Leuenberger's response
regarding "Cups >= 1.6" on <email address hidden>
http://lists.opensuse.org/opensuse-factory/2013-08/msg00408.html
that reads (excerpt):
--------------------------------------------------------------------------
... incompatibility is now what we want at this stage; I already
looked at the issue from 'the other' side and it was rather trivial
to make it build with cups 1.5 without loosing functionality (the
cups 1.6 getter/setter functions were used; so I just added macros
to fall back to the old style direct access).

So, let's stay with 1.5 an let's see to get upgraded for 13.2.
--------------------------------------------------------------------------

I think "incompatibility is now what we want at this stage" is a typo
that should be "incompatibility is not what we want at this stage"
because otherwise "let's stay with 1.5" would not make sense.

Dominique Leuenberger,
is my understanding of what you wrote in that mail correct?

(In reply to comment #47)
> I think "incompatibility is now what we want at this stage" is a typo
> that should be "incompatibility is not what we want at this stage"
> because otherwise "let's stay with 1.5" would not make sense.
>
> Dominique Leuenberger,
> is my understanding of what you wrote in that mail correct?

Correct.. to fat fingers, too small keyboard.
There is no need for CUPS 1.6 with GNOME 3.10;

FYI:

cups-filters OBS submitrequest 196881:
  Renamed cups/banners/* files and cups/data/testprint
  to avoid a file conflict with CUPS which also provides those files.

Ghostscript 9.10 Release Candidate 1
  is available from home:jsmeix:branches:Printing

CUPS 1.7 Release Candidate 1
  is available from home:jsmeix

On my openSUSE 12.3 virtual machine (i586)
with a HP LaserJet 1020 USB printer I run now:

cups-1.7rc1

ghostscript-9.pre10rc1
installing it requires "rpm -Uhv --force" because
"zypper vcmp 9.07 9.pre10rc1" tells "9.07 is newer than 9.pre10rc1"
which is o.k. for me because it avoids an unintended overwrite
of the latest officially released Ghostscript 9.07 by a
release candidate - on the other hand the release candidate can
later simply upgraded to 9.10 because "zypper vcmp 9.10 9.pre10rc1"
tells "9.10 is newer than 9.pre10rc1".

cups-filters-1.0.36
that requires additionally libqpdf13 (its source package is qpdf)

I did the following adjustments:

# cp -p /etc/cups/cupsd.conf /etc/cups/cupsd.conf.backup

# cp /etc/cups/cupsd.conf.rpmnew /etc/cups/cupsd.conf

I disabled all lines in /etc/cups/pstotiff.convs
(strange file from HPLIP - I need to ask upstream what the
 reason behind is - I guess it has something to do with faxing)
otherwise one gets weird filtering e.g. of PostScript input
via pstotiff and imagetopdf (printing works nevertheless).

# systemctl restart cups.service

Printing PostScript, plain text, PDF and PNG works for me
on my local HP LaserJet 1020 USB printer using:

# echo hello | a2ps -1 -o- | lp -d HP_LaserJet_1020

# echo hello | lp -d HP_LaserJet_1020

# lp -d HP_LaserJet_1020 \
 /usr/share/ghostscript/9.10/examples/text_graphic_image.pdf

# lp -d HP_LaserJet_1020 /usr/share/icons/hicolor/256x256/apps/HPmenu.png

Using "grep PID /var/log/cups/error_log" you can see what filters
are run by CUPS for each kind of print job data.

FYI:

Ghostscript release 9.10 is available for various SLE and
openSUSE versions via the openSUSE build service projects
"home:jsmeix" and "home:jsmeix:branches:Printing".

For now Ghostscript 9.10 is intentionally not in "Printing"
because it is not fully compatible with our current printing
system (CUPS 1.5.4 without cups-filters) because Ghostscript 9.10
does no longer provide the CUPS filters gstoraster and gstopxl
(see comment#44).

After the openSUSE 13.1 release I will upgrade our printing
system in the openSUSE build service project "Printing"
to CUPS 1.7 plus cups-filters and Ghostscript 9.10.

Mainly for my own information:

Since CUPS 1.6 the entries in cupsd.conf were split into two files
- cupsd.conf
- cups-files.conf

Accordingly our SUSE documentation must be updated.

In particular the AutoYaST documentation regarding "Printer"
must be updated again for openSUSE 13.2, see bnc#828859

An addendum for comment#49 above at
https://bugzilla.novell.com/show_bug.cgi?id=735404#c49

Regarding
"weird filtering e.g. of PostScript input via pstotiff and imagetopdf":

With HPLIP's default entries in its /etc/cups/pstotiff.convs
------------------------------------------------------------------------------
application/postscript image/tiff 80 pstotiff
application/pdf image/tiff 80 pstotiff
application/vnd.cups-pdf image/tiff 80 pstotiff
application/vnd.cups-postscript image/tiff 80 pstotiff
------------------------------------------------------------------------------
one gets this weird filtering of PostScript input:
------------------------------------------------------------------------------
# echo hello1 | a2ps -1 -o- | lp -d HP_LaserJet_1020
[stdin (plain): 1 page on 1 sheet]
[Total: 1 page on 1 sheet] sent to the standard output
request id is HP_LaserJet_1020-58 (0 file(s))

# grep -o 'Job 58.*PID.*' /var/log/cups/error_log
Job 58] Started filter /usr/lib/cups/filter/pstotiff (PID 3949)
Job 58] Started filter /usr/lib/cups/filter/imagetopdf (PID 3950)
Job 58] Started filter /usr/lib/cups/filter/foomatic-rip (PID 3951)
Job 58] Started backend /usr/lib/cups/backend/hp (PID 3952)
Job 58] PID 3949 (/usr/lib/cups/filter/pstotiff) exited with no errors.
Job 58] PID 3950 (/usr/lib/cups/filter/imagetopdf) exited with no errors.
Job 58] PID 3951 (/usr/lib/cups/filter/foomatic-rip) exited with no errors.
Job 58] PID 3952 (/usr/lib/cups/backend/hp) exited with no errors.
------------------------------------------------------------------------------

When all entries in its /etc/cups/pstotiff.convs are disabled
------------------------------------------------------------------------------
#application/postscript image/tiff 80 pstotiff
#application/pdf image/tiff 80 pstotiff
#application/vnd.cups-pdf image/tiff 80 pstotiff
#application/vnd.cups-postscript image/tiff 80 pstotiff
------------------------------------------------------------------------------
plus restart of the cupsd so that it re-reads its *.convs files
one gets back the normal CUPS upstream filtering:
------------------------------------------------------------------------------
# echo hello2 | a2ps -1 -o- | lp -d HP_LaserJet_1020
[stdin (plain): 1 page on 1 sheet]
[Total: 1 page on 1 sheet] sent to the standard output
request id is HP_LaserJet_1020-59 (0 file(s))

# grep -o 'Job 59.*PID.*' /var/log/cups/error_log
Job 59] Started filter /usr/lib/cups/filter/pstopdf (PID 3997)
Job 59] Started filter /usr/lib/cups/filter/pdftopdf (PID 3998)
Job 59] Started filter /usr/lib/cups/filter/foomatic-rip (PID 3999)
Job 59] Started backend /usr/lib/cups/backend/hp (PID 4000)
Job 59] PID 3997 (/usr/lib/cups/filter/pstopdf) exited with no errors.
Job 59] PID 3998 (/usr/lib/cups/filter/pdftopdf) exited with no errors.
Job 59] PID 3999 (/usr/lib/cups/filter/foomatic-rip) exited with no errors.
------------------------------------------------------------------------------

The reason why HPLIP's default entries in its /etc/cups/pstotiff.convs
mess up the normal CUPS upstream filtering is:

When HPLIP adds CUPS filtering rules via a *.convs file
f...

The problem with the pstotiff->imagetopdf filter chain is known and I have fixed the problem in cups-filters 1.0.37. Please update to the newest cups-filters (today I released 1.0.39).

This is an autogenerated message for OBS integration:
This bug (735404) was mentioned in
https://build.opensuse.org/request/show/202685 Factory / ghostscript

FYI:

The CUPS 1.7.0 release is available from "home:jsmeix".

cups-filters version 1.0.40 is available from "Printing".

They are not yet tested by me.

FYI:

https://bugzilla.redhat.com/show_bug.cgi?id=1027317#c4
-------------------------------------------------------------------------
cups-browsed leaks a lot of memory
...
I figured out that cups-browsed from version 1.0.40 does not leak
but 1.0.41 does
-------------------------------------------------------------------------

Currently cups-filters-1.0.42 is not yet released at
http://www.openprinting.org/download/cups-filters/
but cups-filters-1.0-20131122 there contains in its NEWS file:
--------------------------------------------------------------------------
CHANGES IN V1.0.42
...
        - cups-browsed: Fixed several memory leaks by adding missing
          free() calls and removing an unneeded strdup(). Thanks to
          Jaromir Koncicky from Red Hat for the patch (Red Hat bug
          #1027317).
--------------------------------------------------------------------------

One more noteworthy change in cups-filters-1.0.42 NEWS file:
--------------------------------------------------------------------------
        - foomatic-rip: Moved foomatic-rip's upstream home from the
          foomatic-filters package to cups-filters, to make it easier
          for distributions to ship and maintain a complete printing
          stack and also to make upstream maintenance and development
          easier.
--------------------------------------------------------------------------

If I understand this correctly, it means that with cups-filters-1.0.42
I could remove our foomatic-filters package. I really appreciate
software package clean-ups!

The only thing that is currently in the foomatic-filters package
is /usr/lib/cups/backend/beh which seems to not have been moved
to cups-filters - but this does not really matter - I could easily
re-add http://www.openprinting.org/download/files/beh
back to our cups-backends package, cf. "rpm -q --changelog cups-backends"
--------------------------------------------------------------------------
* Thu May 28 2009 <email address hidden>
- Removed the beh backend because it is now provided
  in the upgraded foomatic-filters version 4.0.1 package.
--------------------------------------------------------------------------

Till Kamppeter,

perhaps it makes sense to also add the Backend Error Handler
to cups-filters to have an even more complete printing stack?

And if you are intersted, in 2009 I made a "pipe" backend.
It is a wrapper backend for printing to any program.
It forwards the print job data like a pipe into another command.

It is not needed often but for special cases it could help.
Only a few SUSE customers use it.

If you like, feel free to also add it to cups-filters.
It is just a bash script (I like bash programming :-), see

https://build.opensuse.org/package/view_file/Printing/cups-backends/cups-pipe.sh?expand=1

Yes, the foomatic-filters package is now discontinued and cups-filters takes its role now with the new included foomatic-rip filter.

The foomatic-filters package contains also beh but my feeling was all the time that no one uses it, especially it does not work with filters which have to run as root, as itself does not run as root. Perhaps it works if one would set beh's permissions to run as root, but then it also runs filters as root which should not run as root. Or one lets beh run as root, but check the filter which it calls and run it unprivileged if its permissions tell it should not run as root. Patches welcome.

It is also written in Perl, but nothing else in the printing stack is written in Perl. It should perhaps be rewritten in C or shell. Also here patches welcome.

Your pipe filter is a good idea, but I see a little missing feature. All CUPS filters/backends get the IPP attributes/options via the 5th command line argument. There is no way in pipe to make use of these, so that you can control the command line being called by pipe by supplying options to your print job.

Also no program which is not explicitly written for the use with pipe uses the PIPE_BACKEND_ARGV[0-6] environment variables, and if you write a program especially for being called with pipe you can directly write a CUPS backend.

Also programs called by pipe run as lp if pipe is installed world-executable and run as root if pipe is installed root-only-executable. So one installed pipe cannot serve both use cases on the same machine.

FYI:

CUPS 1.7.1 is available from "home:jsmeix".

cups-filters 1.0.52 is available from "Printing".

They are not thoroughly tested by me.

Check the RPM changelog entries for basic information.

Regarding banners and test page:

CUPS banners and the CUPS test page are no longer supported since CUPS >= 1.6.

The banners and the test page from cups-filters must be used instead.

The CUPS banner files in /usr/share/cups/banners/ and the CUPS testpage /usr/share/cups/data/testprint (which is also a CUPS banner file type)
are basically useless since CUPS >= 1.6 because there is no longer
a filter that can convert the CUPS banner files, see
http://www.cups.org str.php?L4120

Therefore those files will be no longer be provided in the cups RPM.

Since CUPS >= 1.6 only the banner files and testpage in the
cups-filters package work via the cups-filters PDF workflow
and the cups-filters package also provides the matching
bannertopdf filter.

FYI:

CUPS 1.7.3 is available from OBS home project "home:jsmeix".

cups-filters 1.0.54 is available from OBS devel project "Printing".

They are not thoroughly tested by me.

Check the RPM changelog entries for basic information.

Regarding packages from "home:jsmeix" and "Printing" read
https://build.opensuse.org/project/show?project=home%3Ajsmeix
and
https://build.opensuse.org/project/show/Printing

FYI:
CUPS 1.7.5 is available from OBS home project "home:jsmeix".
cups-filters 1.0.58 is available from OBS devel project "Printing".
See also comment#62 above.

*** Bug 900993 has been marked as a duplicate of this bug. ***

FYI:

CUPS 2.0.0 with upstream support for systemd socket activation
(cf. bug#857372) does not yet "just work", see for example
https://www.cups.org/str.php?L4497

Furthermore there is the open issue how the systemd unit files
should be named, see the "systemd unit files and service names"
mail thread on the CUPS developer list <email address hidden>
http://cups.org/pipermail/cups-devel/2014-October/thread.html
in particular
http://cups.org/pipermail/cups-devel/2014-October/015368.html
http://cups.org/pipermail/cups-devel/2014-October/015369.html
http://cups.org/pipermail/cups-devel/2014-October/015372.html

(In reply to Johannes Meixner from comment #65)
> FYI:
>
> CUPS 2.0.0 with upstream support for systemd socket activation
> (cf. bug#857372) does not yet "just work", see for example
> https://www.cups.org/str.php?L4497

https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c91

> Furthermore there is the open issue how the systemd unit files
> should be named, see the "systemd unit files and service names"
> mail thread on the CUPS developer list <email address hidden>
> http://cups.org/pipermail/cups-devel/2014-October/thread.html
> in particular
> http://cups.org/pipermail/cups-devel/2014-October/015368.html
> http://cups.org/pipermail/cups-devel/2014-October/015369.html
> http://cups.org/pipermail/cups-devel/2014-October/015372.html

How about raising your voice and state that the names they
chose don't fit SUSE either?

I just wanted to chime in and say that the "home:jsmeix" repository for Cups 1.75 is absolutely essential to connect to my wireless printer work with Avahi on openSUSE. Many thanks! I wouldn't be able to use openSUSE without this, and I'm probably not the only one.

In view of different user requirements (some need legacy support in the CUPS 1.5 branch, others need modern but not bleeding-edge support in CUPS 1.75, others will probably need the newest CUPS 2.0), would it be possible to offer an official openSUSE Printing OBS repo with sub-repos for CUPS 1.75 and 2.0? Thanks for taking this into consideration.

FYI:
another issue in CUPS 2.0.0 with upstream support for systemd
http://www.cups.org/str.php?L4491

Regarding comment#52
"HPLIP's default entries in its /etc/cups/pstotiff.convs
 mess up the normal CUPS upstream filtering":

I submitted a bug report to HPLIP upstream:
https://bugs.launchpad.net/hplip/+bug/1391963

In SLES12 we have CUPS 1.7.5 and
in openSUSE Tumbleweed CUPS 2.x.

As of this writing there are no big issues
so that in general CUPS > 1.5.4 plus cups-filters
seems to "just work".