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: > >>> 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
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. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
