Created attachment 768324 [details] qt-cupsEnumDests.patch Description of problem: In CUPS 1.6, printer discover works differently. Whereas previously cupsd would listen for other cupsd instances on the network, the task of network queue discover has now been moved to the client. A new API set for this replaces 'cupsGetDest()'. Now, cupsEnumDest() should be used, and to fetch the PPD or submit a print job, cupsConnectDest() should be used in order to connect to the correct CUPS server. Version-Release number of selected component (if applicable): qt-4.8.4-19.fc19 Steps to Reproduce: 1.Try to print to a queue from a CUPS 1.6 instance on the network Actual results: Print dialog does not show queue. Expected results: Queue shown in print dialog. Attached is a patch that works in my testing.
Thanks! will give it a whirl.
Just applied this locally; it appears to work to the point that I can now at least see printers shared by F19 machines in the KDE print dialog and the fetched printer info appears to be correct.
Sorry for the delay, will try to work on this today (or real soon).
Hi, I'm the Qt Print Maintainer and I'd be interested in up-streaming this patch. It will need some work to make it conditional only if CUPS 1.6 is installed. What is the Red Hat policy on the Qt CLA? We would need at least an initial push to our Gerrit to clear the required legals, then I could pick up the patch and improve it from there.
%changelog * Wed Oct 09 2013 Rex Dieter <rdieter> 4.8.5-11 - Discover printers shared by CUPS 1.6 (#980952)
qt-4.8.5-11.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt-4.8.5-11.fc20
qt-4.8.5-11.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.5-11.fc19
This is too late for F20 final without a freeze exception; is there a strong desire to get it included in the f20 live, or would going out as a 0-day be fine?
0-day is probably fine here (imo)
Package qt-4.8.5-11.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt-4.8.5-11.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22157/qt-4.8.5-11.fc20 then log in and leave karma (feedback).
Tim Waugh, could you please answer John Layt's comment #4? We'd really like such improvements to get upstreamed.
I don't know the answer at the moment but I will try to find out.
Thanks Tim. You might want to ask Lukáš Tinkl (ltinkl) or Dan Vrátil (dvratil) in the Red Hat KDE team, I think they've made some contributions to Qt so might know the policy. Another alternative is just put on record that the code patch is in the public domain.
qt-4.8.5-12.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.5-12.fc19
It seems like I need to sign the contributor agreement on my own behalf and license the patch appropriately.
qt-4.8.5-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.8.5-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Just an FYI, the 4.8.4-11 package in F19 appears to break any concept of a default printer; the qt print dialog simply defaults to the first printer in the list, which is causing some problems for us here because that happens to be a copier three floors down that few people can physically access. I'm not sure what exactly was used to determine the default printer, but it ignores all what I'd expect (the cups default destination, $PRINTER and the last chosen printer). To recap: > sudo yum downgrade qt-4.8.5-10.fc19.x86_64.rpm qt-devel-4.8.5-10.fc19.x86_64.rpm qt-x11-4.8.5-10.fc19.x86_64.rpm > konqueror (hit Ctrl-P, notice that my usual printer appears as the chosen printer by default) > sudo yum -y update (4.8.5-11.fc19 versions are installed) > konqueror (hit Ctrl-P, notice that the third floor copier appears by default) I'll go ahead and reopen this; I hope that's OK.
I've filed this bug report upstream: https://cups.org/str.php?U4332
Sorry, that should be: https://cups.org/str.php?L4332
qt-4.8.5-14.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2013-22860/qt-4.8.5-14.fc20
Package qt-4.8.5-14.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt-4.8.5-14.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22932/qt-4.8.5-14.fc19 then log in and leave karma (feedback).
Due to comment #18 and to bug #1054312, we are dropping this patch for now.
I see bug #1054312 is finally getting fixed now, thanks for that! But what should we do about the default printer issue (comment #18)? Qt clearly needs to honor the default printer setting, or our users will send many printouts to the wrong printer.
https://admin.fedoraproject.org/updates/FEDORA-2014-3451 also addresses this upstream bug: https://cups.org/str.php?L4332 so please give cups-1.7.1-6.fc20 a go.
OK, let's give it another whirl, %changelog * Fri Mar 07 2014 Rex Dieter <rdieter> 4.8.5-21 - restore qt-cupsEnumDests.patch (#980952)
qt-4.8.6-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt-4.8.6-2.fc20
qt-4.8.6-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.6-2.fc19
Package qt-4.8.6-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt-4.8.6-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5695/qt-4.8.6-2.fc20 then log in and leave karma (feedback).
qt-4.8.6-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I fail hard for not testing this, but I have found that with this update, qt apps have gone back to the old behavior of simply picking the first printer in the (really long) list and ignoring any concept of a default, either set by the cups server, set by $PRINTER or simply the last printer selected.
Tim, per comment #25 (and taking tibbs' comment #31 into account), how is this expected to work now? In particular, do you think tibbs' issue is still some cups problem or qt printer client bug?
In my own testing, * I see Qt/KDE client applications either hang or take a really long time accessing some discovered printers. (not always). One was a HP LaserJet Pro 400 Color shared from an ubuntu box (not sure of ubuntu or cups version used), and the other was a HP LaserJet Pro 400 Color attached directly to the network (jetdirect or whatever its called these days) Interestingly, testing evince sees no delays but (some?) of those problematic ones Qt found are not listed either. I wonder of the Gtk handling is smarter or does some sort of filtering. * items shared from a rhel5 cups server show up as "Printer in <location> @ <servername>" with no mention of queuename. Where is that coming from? It's different than what cups-browsed finds and what gtk discovery does. Anyway, based on tibbs' and my own findings this morning, I'm going to yet again revert this patch until it can get tested more thoroughly. And, of course, time to push harder for *someone* to take lead on getting this upstreamed to qt-project (ideally someone @redhat).
qt-4.8.6-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt-4.8.6-5.fc20
qt-4.8.6-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.6-5.fc19
Oh, I think I see the problem. cupsCopyDest() doesn't copy the ->is_default member, so we have to track that ourselves. I'm testing an updated patch.
Created attachment 893999 [details] qt-cupsEnumDests.patch This patch fixes the default printer selection for me. The problem was that cupsCopyDest() doesn't copy the is_default member so we need to track that explicitly.
Thanks, I'll update the rawhide packaging to include this new version. Can you help with the issues I mentioned in comment #33 ? (either of those would likely be considered a blocker for use at my site)
(In reply to Rex Dieter from comment #33) > * I see Qt/KDE client applications either hang or take a really long time > accessing some discovered printers. (not always). One was a HP LaserJet > Pro 400 Color shared from an ubuntu box (not sure of ubuntu or cups version > used), and the other was a HP LaserJet Pro 400 Color attached directly to > the network (jetdirect or whatever its called these days) Unfortunately the CUPS enum API is blocking, which is why GTK+ implements Avahi discovery itself rather than using the CUPS API for it. However, it shouldn't take a really long time. What step actually takes the time? > * items shared from a rhel5 cups server show up as "Printer in <location> @ > <servername>" with no mention of queuename. Where is that coming from? > It's different than what cups-browsed finds and what gtk discovery does. I'm not sure where that's coming from. CUPS in Red Hat Enterprise Linux 5 doesn't advertise queues over DNS-SD.
I'll do more testing and followup with more details on item 2 later. For item 1 (long pauses), maybe getting the default printer thing working will mitigate it, but it turned out when I tested locally, the printer first in the printer list was one of those troublesome ones, so when pressing "Print" button from the Qt/KDE applications I tested, the app would end up hanging for 30 seconds to several minutes before showing the print dialog with that printer selected.
Maybe take a look at what network traffic occurs when you press Print? Or set a breakpoint on cupsConnectDest and cupsGetPPD2 to see which of those is taking the time and why. I've just noticed that the places that call cupsConnectDest() don't call httpClose() afterwards, so that also needs fixing.
qt-4.8.6-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Is there any reason for this ticket to remain open? Both Fedora 21 and 22 appear to get this right; F22 even puts the default printer at the very top of the list. I'm going to go ahead and close this and shrink someone's ticket list.
You sure it's only getting it right because /etc/printcap is getting populated as you like it?
I do have a printcap file (from cups-browsed) but it seems to have no information about default printers, and in F22 the print dialog puts the default printer at the top while it's not at the top of the printcap. So it's at least paying attention to something. If I don't run cups-browsed then nothing sees any printers at all, which I don't really understand. I guess a bunch of stuff changed in cups for F22 and I haven't figured it all out.
OK, my understanding is that *this* patch was about Qt supporting printer browsing itself, without the need of something like cups-browsed
OK, I guess cups-browsed is required to receive any printer broadcasts. But if I delete /etc/printcap, it doesn't recreate it. So, on this F22 machine, I have no /etc/printcap at all. lpstat shows all of my printers. Attempting to print from okular shows the complete printer list, with my default printer selected and at the top of the list. So something must be working. With a test account having no .config, .qt or .kde or any cups-related config and no $PRINTER in the environment, on a fresh login to the machine with no /etc/printcap, the okular dialog still gets the default printer. If this is due to something outside of qt/kde just getting it right, I'm not sure what that could be.
(In reply to Rex Dieter from comment #46) > OK, my understanding is that *this* patch was about Qt supporting printer > browsing itself, without the need of something like cups-browsed That's precisely the case. In an ideal set-up you shouldn't need to run cups-browsed at all: it is only for legacy environments. Reopening.
Interesting. Well, in my environment (F22 server, F22 clients) cups sees no printers at all unless cups-browsed is running. (And by that I mean lpstat -t shows nothing). avahi is running, avahi-browse -a does see the printers, and I haven't altered the client configuration from stock. Browsing On BrowseLocalProtocols dnssd I suppose that's a different bug. Honestly I just thought that cups-browsed is now required in order to receive printer broadcasts.
It isn't that *cups* sees printers, it's that *applications* see printers. Print jobs are submitted directly to remote CUPS servers. For GTK+, for instance, try 'gedit' and invoke the print dialog. When you have things configured right (i.e. firewalld isn't blocking avahi, avahi is running, remote cups is advertising with DNS-SD), you will see remote printers. You don't even need cupsd running locally.
OK, I see what you're talking about, and indeed, with neither cupsd nor cups-browsed running, evince will see the printers while okular won't. I didn't realize anything at all would work without cupsd going as I never use gnome apps. Sorry for getting in the way here.