CUPS 1.6 has major incompatible changes. Do not use CUPS 1.6.1 on stable Ubuntu releases
- Quantal (12.10)
- Bug #1061069
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cups (Suse) |
Fix Released
|
High
|
|||
cups (Ubuntu) |
Fix Released
|
Critical
|
Till Kamppeter | ||
Quantal |
Fix Released
|
Critical
|
Till Kamppeter | ||
Raring |
Fix Released
|
Critical
|
Till Kamppeter | ||
cups-filters (Ubuntu) |
Fix Released
|
Critical
|
Till Kamppeter | ||
Quantal |
Invalid
|
Undecided
|
Unassigned | ||
Raring |
Fix Released
|
Critical
|
Till Kamppeter |
Bug Description
Drastic changes in CUPS 1.6.1 (non Apple feature removed mostly) are detrimental to Ubuntu users. We should wait until the missing features (like automatic appearing of remote CUPS queues) before to unleash the newer version to users. This means downgrading cups in Quantal.
See LP Bug 1061063 and Bug 1052897 for examples and the big list on Suse bugzilla : https:/
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: cups 1.6.1-0ubuntu9
ProcVersionSign
Uname: Linux 3.5.0-16-generic x86_64
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
CupsErrorLog:
W [03/Oct/
W [03/Oct/
Date: Wed Oct 3 18:23:44 2012
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120911)
Lpstat:
device for Brother: dnssd:/
device for HP_LaserJet_P3010: hp:/net/
MachineType: LENOVO 4293AA6
Papersize: a4
PpdFiles: HP_LaserJet_P3010: HP LaserJet P3010 Series Postscript (recommended)
ProcEnviron:
LANGUAGE=fr_CH:fr
TERM=xterm
PATH=(custom, no user)
LANG=fr_CH.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: cups
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/25/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 8DET61WW (1.31 )
dmi.board.
dmi.board.name: 4293AA6
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 4293AA6
dmi.product.
dmi.sys.vendor: LENOVO
modified.
mtime.conffile.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #4 |
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #5 |
Related to this is "PDF as Standard Print Job Format", see
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #6 |
A beta version of the new OpenPrinting CUPS Filters package
is released. See
http://
and
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #7 |
Not an incompatible change but a noteworthy change:
In CUPS 1.6 the libusb-based "usb" backend will be built by default, see
http://
-------
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.
-------
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #8 |
Probably of interest related to Samba and printing in Windows environment:
http://
-------
Given that the Windows drivers are now unsupported, we will no longer
be investing time in new features or documentation for cupsaddsmb.
-------
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #9 |
FYI,
some links to reports, discussions and replies from Michael Sweet:
(German only):
http://
(German only):
http://
http://
http://
http://
http://
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #10 |
Probably only of interest for exceptional use-cases
http://
-------
... the PHP module has been removed from CUPS 1.6 and later.
-------
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #11 |
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-
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-
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-
don't need to install its RPM package.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #12 |
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://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #13 |
Regarding comment #9 "a separated CUPS-Browsing-
The CUPS Browse Protocol is described at
http://
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_
CUPS_
CUPS_
CUPS_PRINTER_BW = 0x0004, /* Can do B&W printing */
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_PRINTER_BIND = 0x0400, /* Can bind output */
CUPS_PRINTER_SORT = 0x0800, /* Can sort output */
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_PRINTER_FAX = 0x40000, /* Fax queue */
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
CUPS_
.5@ */
CUPS_
CUPS_PRINTER_MFP = 0x4000000, /* Printer with scanning capabilities @since CUPS 1.4/Mac OS X 10.6@ */
CUPS_
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...
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #14 |
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.
"Description" "Make and Model" lease-duration=300 job-sheets=
>/dev/udp/
-bash: connect: Permission denied
-bash: /dev/udp/
-------
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
my $port = 631;
my $data = '2 3 ipp://PRINT.
"Description" "Make and Model" lease-duration=300 job-sheets=
socket(sock, PF_INET, SOCK_DGRAM, getprotobyname(
setsockopt(sock, SOL_SOCKET, SO_BROADCAST, 1) or die "setsockopt:$@";
my $dest = sockaddr_
send(sock,
-------
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #15 |
An overview regarding the changes:
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #16 |
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://
"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://
"CUPs 1.6.x server does not send PPD/option info to CUPS 1.6.x client"
http://
"CUPS 1.6.1 crashes on shutdown"
http://
"CUPS 1.6.1 crashes on startup when DNS-SD host name
cannot get determined via Avahi"
http://
"CUPS daemon crashes on bad entry in cupsd.conf"
Jonathan Ernst (jonathan.ernst) wrote : | #1 |
- BootDmesg.txt Edit (63.1 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (102.3 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (7.2 KiB, text/plain; charset="utf-8")
- KernLog.txt Edit (19.7 KiB, text/plain; charset="utf-8")
- Locale.txt Edit (335 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (12.2 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (1.0 KiB, text/plain; charset="utf-8")
- PrintingPackages.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (3.5 KiB, text/plain; charset="utf-8")
- ProcInterrupts.gz Edit (701 bytes, application/x-gzip)
- ProcModules.txt Edit (3.3 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (154.6 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (347.4 KiB, text/plain; charset="utf-8")
tags: | added: rls-q-incoming |
Till Kamppeter (till-kamppeter) wrote : | #2 |
Making bug numbers clickable: bug 1061063, bug 1052897.
Changed in cups (Ubuntu): | |
importance: | Undecided → High |
milestone: | none → ubuntu-12.10 |
Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in cups (Ubuntu): | |
status: | New → Confirmed |
Changed in cups (Suse): | |
importance: | Unknown → High |
status: | Unknown → Confirmed |
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #19 |
One more related to comment #12:
http://
"cupsd crashed with SIGABRT in __assert_
Changed in cups (Ubuntu Quantal): | |
assignee: | nobody → Till Kamppeter (till-kamppeter) |
tags: | removed: rls-q-incoming |
description: | updated |
Changed in cups (Ubuntu): | |
status: | Confirmed → In Progress |
Till Kamppeter (till-kamppeter) wrote : | #17 |
Fix committed in cups 1.6.1-0ubuntu10 in quantal-proposed.
Changed in cups (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in cups (Ubuntu Quantal): | |
importance: | High → Critical |
Till Kamppeter (till-kamppeter) wrote : | #18 |
FFe to re-introduce CUPS Broadcasting/
Launchpad Janitor (janitor) wrote : | #20 |
This bug was fixed in the package cups - 1.6.1-0ubuntu10
---------------
cups (1.6.1-0ubuntu10) quantal-proposed; urgency=low
* debian/
CUPS Browsing/
on the local network. We will keep this for the Quantal cycle until we
get automatic discovery of Bonjour-broadcasted printers, which most
probably needs to be implemented in the application's print dialogs. This
will only be possible to be done in Quantal+1 (13.04). The patch is large
but all code added worked very well in many generations of CUPS and the
code added back in smoothly without need of alterations of the existing
code (LP: #1061063, LP: #1061069).
* debian/rules: Set "./configure" arguments
"--
to make the re-introduction of CUPS Browsing/
* debian/
any more as we have re-introduced the Browsing/
* debian/
Fix another spot where Avahi crashes cupsd because it does not handle NULL
values returned by its own APIs (CUPS STR #4200, LP: #1041013).
* debian/
The IPP backend did not send a cancel request to printers when a job was
canceled and the printer did not support Create-Job. This is to improve the
"ipp" backend as much as possible to reduce the ned of the "ipp14" backend
("ipp" backend of CUPS 1.4.x added to the Debian/Ubuntu package as fallback
in case of regressions of the current "ipp" backend).
-- Till Kamppeter <email address hidden> Fri, 5 Oct 2012 20:56:30 +0200
Changed in cups (Ubuntu Quantal): | |
status: | Fix Committed → Fix Released |
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #21 |
One more related to comment #12:
http://
"CUPS crashes on shutdown when taking down Avahi threaded poll"
Furthermore:
A general comment from the CUPS author regarding CUPS Browsing:
http://
-------
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".
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #22 |
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:
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:
even unexpected issues.
In Novell/SUSE Bugzilla #735404, Bruno-ioda-net (bruno-ioda-net) wrote : | #23 |
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?
In Novell/SUSE Bugzilla #735404, Lnussel-k (lnussel-k) wrote : | #24 |
So if we still want to get cups 1.6 into 12.3 now would be a good time to submit it.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #25 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #26 |
Till Kamppeter who maintains CUPS in Ubuntu
re-introduced Browsing for CUPS 1.6, see
https:/
and
https:/
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).
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #27 |
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:/
I don't know if a "client-only" config still works
with plain upstream CUPS 1.6 without any patch.
In Novell/SUSE Bugzilla #735404, Lnussel-k (lnussel-k) wrote : | #30 |
(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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #31 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #32 |
Regarding comment#15 "Printing:
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.
In Novell/SUSE Bugzilla #735404, Till Kamppeter (till-kamppeter) wrote : | #28 |
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:/
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.
Changed in cups (Ubuntu Quantal): | |
status: | Fix Released → Confirmed |
status: | Confirmed → Fix Released |
Changed in cups (Ubuntu Raring): | |
status: | Fix Released → Confirmed |
milestone: | ubuntu-12.10 → ubuntu-13.04-feature-freeze |
Till Kamppeter (till-kamppeter) wrote : | #29 |
My plans for Raring 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:/
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #33 |
Regarding comment#22 "notification on <email address hidden>":
See my "Opinion poll: CUPS 1.6 version upgrade"
http://
Not much response up to now...
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #34 |
Regarding comment#20 "client-only config does no longer work with CUPS 1.6":
https:/
"From CUPS 1.6.x on using a remote CUPS server via client.conf stopped working"
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #35 |
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
Read
https:/
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://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #36 |
Right now I picked up
https:/
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...
-------
Till Kamppeter (till-kamppeter) wrote : | #37 |
I have now released cups-filters 1.0.26 upstream, with the new cups-browsed daemon added. cups-browsed browses the Bonjour broadcasts of shared remote CUPS queues and makes the queues available locally, eliminating the need of the forward-port patch for CUPS broadcasting/
Changed in cups (Ubuntu Raring): | |
status: | Confirmed → Triaged |
Changed in cups-filters (Ubuntu Quantal): | |
status: | New → Invalid |
Changed in cups-filters (Ubuntu Raring): | |
status: | New → Triaged |
importance: | Undecided → Critical |
assignee: | nobody → Till Kamppeter (till-kamppeter) |
milestone: | none → ubuntu-13.04-feature-freeze |
Launchpad Janitor (janitor) wrote : | #38 |
This bug was fixed in the package cups - 1.6.1-0ubuntu13
---------------
cups (1.6.1-0ubuntu13) raring; urgency=low
* debian/
forward-port of CUPS broadcasting/
on we have cups-browsed which does Bonjour browsing for us making the
patch unneeded. This eliminates also a crash bug in cupsd (LP: #1086019,
LP: #1061063, LP: #1061069).
* debian/rules: Removed "--with-
./configure command line and removed the "CUPS" from
"--
any more in stock CUPS 1.6.x (without forward-port of CUPS broadcasting/
browsing).
* debian/
and settings which got obsolete with the dropping CUPS Broadcasting/
Browsing in CUPS 1.6.x: BrowsePoll, BrowseAllow, BrowseDeny, BrowseOrder,
and BrowseRemotePro
removed from the BrowseLocalProt
* debian/
debian/
Refreshed with quilt.
* debian/
-- Till Kamppeter <email address hidden> Fri, 28 Dec 2012 22:27:30 +0100
Changed in cups (Ubuntu Raring): | |
status: | Triaged → Fix Released |
Launchpad Janitor (janitor) wrote : | #39 |
This bug was fixed in the package cups-filters - 1.0.28-0ubuntu1
---------------
cups-filters (1.0.28-0ubuntu1) raring; urgency=low
* New upstream release
- cups-browsed: Added daemon to browse the Bonjour broadcasts of
shared remote CUPS printers and automatically add local raw queues
pointing to them, to resemble the behavior of the former CUPS
printers appear as local print queues as before, but with the
standardized Bonjour broadcasting (LP: #1086019, LP: #1061063,
LP: #1061069).
* debian/control: Added build dependencies on Avahi, needed for the new
cups-browsed and also a new binary package named cups-browsed.
* debian/
* debian/
cups-browsed.
* debian/rules: Added everything needed so that the cups-browsed daemon gets
started automatically.
* debian/
-- Till Kamppeter <email address hidden> Sat, 29 Dec 2012 14:30:07 +0100
Changed in cups-filters (Ubuntu Raring): | |
status: | Triaged → Fix Released |
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #40 |
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[..
http://
for openSUSE 12.1/12.2/12.3 and SLE-11/SP1/SP2
Carefully read
https:/
and the RPM changelog
https:/
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:/
"When restarting avahi-daemon while CUPS is running, CUPS looses connection"
Workaround: After restarting Avahi also restart CUPS.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #41 |
Regarding comment#7
"a separated CUPS-Browsing-
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:
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://
In Novell/SUSE Bugzilla #735404, Tchvatal (tchvatal) wrote : | #42 |
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://
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #43 |
FYI for venturous testers:
I made CUPS 1.7rc1 (see http://
as source package "cups17rc1" in "home:jsmeix".
Note what I wrote in comment#28 above:
https:/
Currently cups-filters fails to build for openSUSE_Factory.
I am afraid currently I do not have time to work on it.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #44 |
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:
(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.
In Novell/SUSE Bugzilla #735404, Tchvatal (tchvatal) wrote : | #45 |
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 :)
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #46 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #47 |
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.
Till Kamppeter (till-kamppeter) wrote : | #48 |
For cups-filters vs. Poppler 0.24.x problem see https:/
In Novell/SUSE Bugzilla #735404, Tchvatal (tchvatal) wrote : | #49 |
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:/
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://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #50 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #51 |
FYI:
I tried to compile cups-filters-
(i.e. the daily snapshot dated 2013 August 02)
that fixes in particular
https:/
But compile fails with a new issue, see
https:/
I will now try to go back to cups-filters-1.0.35
and add a patch that only fixes
https:/
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #52 |
In OBS home:jsmeix:
I am now back to cups-filters-1.0.35
with BZR_revision_
https:/
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:
I have added your support for systemd according
to what you did in home:scarabeus_iv cups-filters
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #53 |
With submitrequest 185617 I submitted cups-filters
from home:jsmeix:
OBS still could not build it for openSUSE_Factory.
I can only hope that BZR_revision_
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #54 |
Tomas Chvatal,
many thanks for your cups-filters version upgrade to 1.0.36
in the OBS Printing project!
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #55 |
Mainly for my own information:
Regarding Ghostscript version upgrade and cups-filters:
http://
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:/
Ghostscript 9.09 causes a regression for "gv" see
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #56 |
Regarding Ghostscript 9.09 regression in above comment#44:
It seems this will be fixed soon in Ghostscript 9.10, see the
"Ghostrscript/
announcement on <email address hidden>
http://
In Novell/SUSE Bugzilla #735404, Tchvatal (tchvatal) wrote : | #57 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #58 |
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://
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 Novell/SUSE Bugzilla #735404, Dominique Leuenberger aka DimStar (dimstar) wrote : | #59 |
(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;
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #60 |
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:
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-
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/
# cp /etc/cups/
I disabled all lines in /etc/cups/
(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/
# lp -d HP_LaserJet_1020 /usr/share/
Using "grep PID /var/log/
are run by CUPS for each kind of print job data.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #61 |
FYI:
Ghostscript release 9.10 is available for various SLE and
openSUSE versions via the openSUSE build service projects
"home:jsmeix" and "home:jsmeix:
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #62 |
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
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #63 |
An addendum for comment#49 above at
https:/
Regarding
"weird filtering e.g. of PostScript input via pstotiff and imagetopdf":
With HPLIP's default entries in its /etc/cups/
-------
application/
application/pdf image/tiff 80 pstotiff
application/
application/
-------
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/
Job 58] Started filter /usr/lib/
Job 58] Started filter /usr/lib/
Job 58] Started filter /usr/lib/
Job 58] Started backend /usr/lib/
Job 58] PID 3949 (/usr/lib/
Job 58] PID 3950 (/usr/lib/
Job 58] PID 3951 (/usr/lib/
Job 58] PID 3952 (/usr/lib/
-------
When all entries in its /etc/cups/
-------
#application/
#application/pdf image/tiff 80 pstotiff
#application/
#application/
-------
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/
Job 59] Started filter /usr/lib/
Job 59] Started filter /usr/lib/
Job 59] Started filter /usr/lib/
Job 59] Started backend /usr/lib/
Job 59] PID 3997 (/usr/lib/
Job 59] PID 3998 (/usr/lib/
Job 59] PID 3999 (/usr/lib/
-------
The reason why HPLIP's default entries in its /etc/cups/
mess up the normal CUPS upstream filtering is:
When HPLIP adds CUPS filtering rules via a *.convs file
f...
In Novell/SUSE Bugzilla #735404, Till Kamppeter (till-kamppeter) wrote : | #64 |
The problem with the pstotiff-
In Novell/SUSE Bugzilla #735404, Bwiedemann (bwiedemann) wrote : | #65 |
This is an autogenerated message for OBS integration:
This bug (735404) was mentioned in
https:/
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #66 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #67 |
FYI:
https:/
-------
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://
but cups-filters-
-------
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
-------
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #68 |
One more noteworthy change in cups-filters-1.0.42 NEWS file:
-------
- foomatic-rip: Moved foomatic-rip's upstream home from the
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/
to cups-filters - but this does not really matter - I could easily
re-add http://
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:/
In Novell/SUSE Bugzilla #735404, Till Kamppeter (till-kamppeter) wrote : | #69 |
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_
Also programs called by pipe run as lp if pipe is installed world-executable and run as root if pipe is installed root-only-
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #70 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #71 |
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/
are basically useless since CUPS >= 1.6 because there is no longer
a filter that can convert the CUPS banner files, see
http://
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #72 |
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:/
and
https:/
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #73 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #74 |
*** Bug 900993 has been marked as a duplicate of this bug. ***
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #75 |
FYI:
CUPS 2.0.0 with upstream support for systemd socket activation
(cf. bug#857372) does not yet "just work", see for example
https:/
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://
in particular
http://
http://
http://
In Novell/SUSE Bugzilla #735404, Lnussel-k (lnussel-k) wrote : | #76 |
(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:/
https:/
> 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://
> in particular
> http://
> http://
> http://
How about raising your voice and state that the names they
chose don't fit SUSE either?
In Novell/SUSE Bugzilla #735404, Sb (sb56637) wrote : | #77 |
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.
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #78 |
FYI:
another issue in CUPS 2.0.0 with upstream support for systemd
http://
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #79 |
Regarding comment#52
"HPLIP's default entries in its /etc/cups/
mess up the normal CUPS upstream filtering":
I submitted a bug report to HPLIP upstream:
https:/
In Novell/SUSE Bugzilla #735404, Johannes Meixner (jsmeix) wrote : | #80 |
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".
Changed in cups (Suse): | |
status: | Confirmed → Fix Released |
CUPS 1.6 will have major incompatible changes:
"Transition all non-Mac filters to OpenPrinting" www.cups. org/str. php?L3930 www.cups. org/str. php?L3931
http://
"Deprecate and stub out image file support"
http://
"Drop serial and parallel backends" www.cups. org/str. php?L3935
http://
"Drop support for CUPS Browsing and Polling" www.cups. org/str. php?L3922 www.cups. org/str. php?L3889 www.cups. org/newsgroups. php?gcups. general+ T+Q%22Why+ is+CUPS+ browsing+ deprecated% 22
http://
"CUPS browsing is deprecated and scheduled for removal ... after 1.5.x"
http://
"Bonjour is the replacement"
http://
"Deprecate PPD functions" www.cups. org/str. php?L3926 www.cups. org/str. php?L3927 www.cups. org/newsgroups. php?gcups. general+ T+Q%22CUPS+ 1.6+and+ PPD%22
http://
"Deprecate the PPD compiler"
http://
"Support for PPDs is not going away in CUPS 1.6"
http://
In general for changes in the upcomming CUPS version 1.6 see www.cups. org/roadmap. php?VERSION= 1.6
http://