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: >>> 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, >
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org