Bugzilla – Bug 1169817
Printing/cups: cannot use the "driverless" driver anymore with cups-2.3.3op2
Last modified: 2022-07-14 21:29:32 UTC
On 7 April 2020 I updated my OpenSUSE Tumbleweed using "zypper dup" which bumped my CUPS version to 2.3b6 and resulted in me being unable to print to my network printer via IPP ever since. The error log shows an apparent "document-format-error" and the CUPS queue says "Unable to add document to print job." Since I couldn't find any fix for this issue I ended up downgrading to CUPS 2.2.7 from the Leap 15.2 distribution. I also noticed that the 2.3b6 version of CUPS is a beta and already more than a year old. Perhaps it would be worthwhile to upgrade CUPS to the current version 2.3.1 for which there is already a package on the OBS but I'd rather have it in the Tumbleweed distribution proper. Many thanks, Manfred
We've got 2.3.3 in the meantime. Is this error still present?
(In reply to Martin Wilck from comment #1) > We've got 2.3.3 in the meantime. Is this error still present? I held out for a couple of months and then updated to 2.3.3op2-3.2 which seems to be working. However, apparently I cannot use the "driverless" driver anymore which had allowed me to just send a PDF directly to the printer. Now it has to be filtered first which makes for much slower printing and also the printout looks quite different. So, it's not completely broken anymore, but I would welcome to get the simplified setup back, where all I have to do is find the printer on the network and I can send whatever document (ie txt, pdf, ps) to it directly without additional filtering.
hm, driverless should work, AFAIK. Johannes, can you comment?
(In reply to Martin Wilck from comment #3) > hm, driverless should work, AFAIK. > > Johannes, can you comment? I would like to give more details but it has been a while since I tried this and I cannot test it right now because it's in the middle of the night and the child is sleeping, but from memory I think the problem was that the driver complained about "not supported image format" or similar. This wasn't very obvious either because as usual the printout would just not come out and the job would be stalled in the queue, but looking in the log files, this seems to have been the error more or less. Of course I know the printer itself supports PDF so the problem appears to be in the "driverless" driver in between.
I cannot say anything about "driverless" because I do not have a matching printer for it (I have only a traditional PostScript USB printer) so I cannot try out or reproduce anything in this area. It seems to work according to the recent "IPP Everywhere support" mail thread on factory@lists.opensuse.org https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/VRNHYW22SZZSXW72OCBU7ITZILRZXXCA/ "Printing to a network printer via IPP" is not the same as "driverless printing" because not each network printer that supports IPP to receive printing data also supports "driverless printing" i.e. network printers that support only plain IPP usually still need printer driver software. "IPP Everywhere" printers support "driverless printing". In general regarding "driverless printing" https://wiki.debian.org/CUPSDriverlessPrinting provides a good overview. "Unable to print via IPP" could be also things like bug #1178604 or something different... In general regarding how to report a printing issue see https://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue
Keeping this open for now, perhaps Manfred will be able to supply more details. @Manfred, please follow Johannes' advice from comment 5.
FYI: A good explanation how "driverless" actually works by Till Kamppeter who is the main author of the "driverless" functionality (which is not in CUPS but in cups-filters) is https://github.com/OpenPrinting/cups-filters/issues/391#issuecomment-875066110 You may also follow the links in that GitHub issue e.g. to https://lists.linuxfoundation.org/pipermail/printing-architecture/2021/004048.html Bottom line: Things are moving in CUPS together with cups-filters so from time to time this or that may work or may not work.
(In reply to Johannes Meixner from comment #7) > https://github.com/OpenPrinting/cups-filters/issues/391#issuecomment-875066110 "cups-browsed [...] fully automatically creates local permanent queues for all discovered printers. [...] The driverless utility retro-fits driverless printing into pseudo drivers, to make it accessible in printer setup tools". Am I understanding correctly that "cups-browsed" and "driverless" are supposed to work together ("cups-browsed" for the queues, and "driverless" for the setup tools)? IOW: does "driverless" provide the configuration interface that is later used by "cups-browsed"? Or are these rather competing concepts for achieving similar goals? Does the yast printing module support "driverless"? "I have always succeeded to let the show go on seamlessly for the users, whatever feature Michael (or anyone else) is removing by throwing in workarounds and retro-fits quickly enough, before running into a pandemic-alike "I CANNOT PRINT!!!" crisis." That sounds like a dangerous working model in the long run. One side permanently removing features and the other side trying to cope with it by retro-fitting. What if Till is hit by a bus?
Regarding "Does the yast printing module support 'driverless'?" see https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/3YJ5QMKMD36DIFS7NBGYWRXEDL5QHEUF/ In general regarding the YaST printer module see https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1
(In reply to Johannes Meixner from comment #9) > Regarding > "Does the yast printing module support 'driverless'?" > see > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/ > 3YJ5QMKMD36DIFS7NBGYWRXEDL5QHEUF/ According to that post, the answer is "no, use the CUPS web UI". > In general regarding the YaST printer module see https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1 ... which basically says "has been unmaintained for 6-8 years". I know this is mainly your work and I appreciate it a lot, but perhaps we should stop distributing it if it doesn't support what many consider the present (and future) state of the art of Linux printing. It's sad to say this, but we have to face the fact that some significant human resources are required to maintain something as complex as printer setup.
(In reply to Johannes Meixner from comment #9) > Regarding > "Does the yast printing module support 'driverless'?" > see > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/ > 3YJ5QMKMD36DIFS7NBGYWRXEDL5QHEUF/ > > In general regarding the YaST printer module see > https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1 So you are actually saying printer configuration in OpenSuse hasn't been updated since July 2013? Wouldn't it better at this point to remove it altogether and revert to some generic CUPS web interface that's up-to-date?
In general regarding the YaST printer module see https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1 and therein see the "See also" part and follow that links (as far as those links still work) ;-)
(In reply to Johannes Meixner from comment #12) > In general regarding the YaST printer module see > https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1 > and therein see the "See also" part and > follow that links (as far as those links still work) > ;-) Right, so basically the Yast client should have been removed 6 years ago. Anyway, for what it's worth I just tried to configure my printer through the CUPS webinterface on port :631 and even though this appeared to work at first, ultimately it didn't. I can choose "IPP Everywhere^TM" now for the driver (even though I still have to choose the Make of my printer first), but the printer that is added doesn't allow me any configuration, in particular it is added as a grayscale printer. Also, when I try to actually print to this printer, cups seems to be unable to find it anymore and the job hangs in the queue. To add insult to injury when I opened the printer queue widget in KDE Plasma and clicked on "Configure" for the selected printer/job it crashed and opened the Bug report tool which then proceeded downloading hundreds of debug source packages to generate a meaningful backtrace. At this point I gave up ...
Bug reporter gave up. I am not happy about it, but without further information we need to close this bug. Btw you can avoid the endless download of debuginfo packages by unsetting the environment variable DEBUGINFOD_URLS.