On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: > On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: > > Control: tags -1 +moreinfo > > > > Hi Lionel and Wolfgang, > > hi Till, > > > > thanks for your detailed bugreports and proposed patch. > > > > Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane a écrit : > >> Let FOO be a printer configured in CUPS with an > >> ipp://foo.localdomain.tld/something device uri. > >> Mine is a Konica Minolto C353. > >> > >> All cups clients fail to show printing options. > >> > >> "lpoptions -d FOO -l" says: > >> lpoptions: Unable to get PPD file for FOO: Not Found > >> > >> A wireshark shows a request for http://device_ip:631/ipp.ppd, > >> to which the printer replies by a 404. > >> > >> The attached patch disables that undesirable behaviour, which is new > >> in 1.6 (did not happen in 1.5). > > > > Your proposed patch is functionally equivalent to disabling the get-ppd- > > file-for-statically-configured-ipp-shared-queues.patch , which was > > introduced in 1.6.1-1 as a backport from upstream's fix for > > http://cups.org/str.php?L4178 > > > > Till, as you wrote this patch, what do you think about this? > > > > Apparently, http://cups.org/str.php?L4159 was related to this problem > > and got solved differently in 1.6.2, and now cups/util.c appears to be > > redundant around this codeblock. > > > > Till, can we remove this patch on all versions > 1.6.2 ? > > Important is to check whether if you create a raw IPP queue pointing to > a CUPS queue on a remote server that you get access to the options on > the client (means that the client loads the PPD from the server). Please > test this. > > You can test by creating an arbitrary print queue with PPD on one > machine (the server) and sharing it. On another machine (the client) you > either create a raw ipp: or ipps: queue pointing to the queue on the > server or you run cups-browsed (which creates such a queue > automatically). If you print out of a GUI app on the client using the > ipp/ipps queue pointing to the CUPS server you should see the PPD > options in the print dialog. You should also run "lpoptions -p <printer> > -l" on the client and should see the options if <printer> is an ipp/ipps > queue pointing to the server and no error message if <printer> is > pointing to a native IPP printer. > > Till
We do not have a cups-server running on the client. Our configuration is: client: only /etc/cups/client.conf with ServerName cups.localdomain.tld. On the print server cups.localdomain.tld. we have a lot of printers in printers.conf like that <Printer Mehltau> AuthInfoRequired none Info Mehltau Location Rosenstraße MakeModel MyFavoritePostscripPrinterModel DeviceURI ipp://mehltau.drucker.localdomain.tld/ipp State Idle StateTime 1387541234 Type 8425548 Filter application/vnd.cups-raw 0 - Filter application/vnd.cups-command 0 commandtops Filter application/vnd.cups-postscript 0 - Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy abort-job </Printer> We do not wan't to mehltau to be a raw-printer as the printer server should e.g. handle pdfs etc. This setting breaks with cups 1.6. as now the client contacts cups.localdomain.tld but then tries to get the ppd from mehltau.drucker.localdomain.tld instead from cups.localdomain.tld But mehltau.drucker.localdomain.tld is a ipp postscript printer (e.g. from HP or any other vendor) and does not provide ppds (and in our case the client is not even allowed to communicate with Mehltau directly). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
