Hi dear cups-devel@cups.org, It would be nice if someone could take a look at [Debian's #729713 bug] (http://bugs.debian.org/729713), which abstract log is below. What is CUPS doing wrong there? Cheers, OdyX Le lundi, 6 janvier 2014, 13.24:50 Wolfgang Walter a écrit : > On Sunday 05 January 2014 13:47:41 Till Kamppeter wrote: > > On 01/05/2014 01:36 PM, Wolfgang Walter wrote: > > > On Sunday 05 January 2014 13:12:31 Till Kamppeter wrote: > > >> On 01/05/2014 12:45 PM, Didier 'OdyX' Raboud wrote: > > >>> Le samedi, 16 novembre 2013, 05.34:09 Lionel Elie Mamane wrote: > > >>>> 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 > > >>> > > >> 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. > > > > > > 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). > > > > My patch did > > > > httpSeparateURI(HTTP_URI_CODING_ALL, > > > > device_uri, > > scheme, sizeof(scheme), > > username,sizeof(username), > > > > host, hostsize, port, resource, resourcesize); > > > > whereas the final fix does > > > > httpSeparateURI(HTTP_URI_CODING_ALL, > > > > _httpResolveURI(device_uri, uri, sizeof(uri), > > > > _HTTP_RESOLVE_DEFAULT, > > NULL,NULL), > > > > scheme, sizeof(scheme), > > username,sizeof(username), > > > > host, hostsize, port, resource, resourcesize); > > > > Can it be that the _httpResolveURI() causes some problem here? > > > > Till > > No, this makes no difference. The problem is using device_uri. Having > a device-uri starting with ipp:// does not ensure that the printer is > another cups-server which you can ask for a ppd.
Attachment:
signature.asc
Description: This is a digitally signed message part.