Bug 980952 - RFE: Discover printers shared by CUPS 1.6
RFE: Discover printers shared by CUPS 1.6
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: FutureFeature, Patch, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-03 12:04 EDT by Tim Waugh
Modified: 2016-11-30 19:36 EST (History)
13 users (show)

See Also:
Fixed In Version: qt-4.8.6-2.fc20
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-15 10:00:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
qt-cupsEnumDests.patch (9.18 KB, patch)
2013-07-03 12:04 EDT, Tim Waugh
no flags Details | Diff
qt-cupsEnumDests.patch (9.97 KB, patch)
2014-05-09 06:40 EDT, Tim Waugh
no flags Details | Diff

  None (edit)
Description Tim Waugh 2013-07-03 12:04:11 EDT
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.
Comment 1 Rex Dieter 2013-07-03 12:51:41 EDT
Thanks! will give it a whirl.
Comment 2 Jason Tibbitts 2013-07-26 11:28:39 EDT
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.
Comment 3 Rex Dieter 2013-10-09 12:31:03 EDT
Sorry for the delay, will try to work on this today (or real soon).
Comment 4 John Layt 2013-11-18 05:53:22 EST
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.
Comment 5 Rex Dieter 2013-11-26 10:41:34 EST
%changelog
* Wed Oct 09 2013 Rex Dieter <rdieter@fedoraproject.org> 4.8.5-11
- Discover printers shared by CUPS 1.6 (#980952)
Comment 6 Fedora Update System 2013-11-26 10:51:57 EST
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
Comment 7 Fedora Update System 2013-11-26 10:53:15 EST
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
Comment 8 Adam Williamson 2013-11-26 12:27:25 EST
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?
Comment 9 Rex Dieter 2013-11-26 12:30:47 EST
0-day is probably fine here (imo)
Comment 10 Fedora Update System 2013-11-26 12:59:10 EST
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).
Comment 11 Kevin Kofler 2013-11-29 18:29:23 EST
Tim Waugh, could you please answer John Layt's comment #4? We'd really like such improvements to get upstreamed.
Comment 12 Tim Waugh 2013-12-02 06:18:27 EST
I don't know the answer at the moment but I will try to find out.
Comment 13 John Layt 2013-12-02 09:08:11 EST
Thanks Tim.  You might want to ask Lukáš Tinkl (ltinkl@redhat.com) or Dan Vrátil (dvratil@redhat.com) 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.
Comment 14 Fedora Update System 2013-12-05 19:21:53 EST
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
Comment 15 Tim Waugh 2013-12-09 08:14:35 EST
It seems like I need to sign the contributor agreement on my own behalf and license the patch appropriately.
Comment 16 Fedora Update System 2013-12-13 22:42:57 EST
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.
Comment 17 Fedora Update System 2013-12-16 17:59:40 EST
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.
Comment 18 Jason Tibbitts 2014-01-08 12:43:26 EST
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.
Comment 19 Tim Waugh 2014-01-09 11:40:26 EST
I've filed this bug report upstream:
  https://cups.org/str.php?U4332
Comment 20 Tim Waugh 2014-01-09 12:40:27 EST
Sorry, that should be:
  https://cups.org/str.php?L4332
Comment 21 Fedora Update System 2014-01-14 10:33:49 EST
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
Comment 22 Fedora Update System 2014-01-15 01:10:47 EST
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).
Comment 23 Kevin Kofler 2014-01-17 17:34:40 EST
Due to comment #18 and to bug #1054312, we are dropping this patch for now.
Comment 24 Kevin Kofler 2014-03-06 13:32:03 EST
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.
Comment 25 Tim Waugh 2014-03-07 05:14:53 EST
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.
Comment 26 Rex Dieter 2014-03-07 10:27:30 EST
OK, let's give it another whirl,

%changelog
* Fri Mar 07 2014 Rex Dieter <rdieter@fedoraproject.org> 4.8.5-21
- restore qt-cupsEnumDests.patch (#980952)
Comment 27 Fedora Update System 2014-04-25 17:53:40 EDT
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
Comment 28 Fedora Update System 2014-04-25 17:54:01 EDT
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
Comment 29 Fedora Update System 2014-04-27 05:09:28 EDT
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).
Comment 30 Fedora Update System 2014-05-01 18:22:33 EDT
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.
Comment 31 Jason Tibbitts 2014-05-05 12:01:36 EDT
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.
Comment 32 Rex Dieter 2014-05-05 12:16:56 EDT
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?
Comment 33 Rex Dieter 2014-05-05 14:54:46 EDT
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).
Comment 34 Fedora Update System 2014-05-06 11:41:28 EDT
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
Comment 35 Fedora Update System 2014-05-06 11:42:48 EDT
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
Comment 36 Tim Waugh 2014-05-07 07:59:57 EDT
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.
Comment 37 Tim Waugh 2014-05-09 06:40:39 EDT
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.
Comment 38 Rex Dieter 2014-05-09 09:45:10 EDT
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)
Comment 39 Tim Waugh 2014-05-09 11:05:33 EDT
(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.
Comment 40 Rex Dieter 2014-05-09 11:14:48 EDT
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.
Comment 41 Tim Waugh 2014-05-09 11:39:33 EDT
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.
Comment 42 Fedora Update System 2014-05-12 01:23:56 EDT
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.
Comment 43 Jason Tibbitts 2015-07-15 10:00:36 EDT
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.
Comment 44 Rex Dieter 2015-07-15 12:18:09 EDT
You sure it's only getting it right because /etc/printcap is getting populated as you like it?
Comment 45 Jason Tibbitts 2015-07-15 12:30:13 EDT
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.
Comment 46 Rex Dieter 2015-07-15 12:37:21 EDT
OK, my understanding is that *this* patch was about Qt supporting printer browsing itself, without the need of something like cups-browsed
Comment 47 Jason Tibbitts 2015-07-15 12:44:26 EDT
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.
Comment 48 Tim Waugh 2015-07-15 18:36:38 EDT
(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.
Comment 49 Jason Tibbitts 2015-07-15 18:43:07 EDT
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.
Comment 50 Tim Waugh 2015-07-16 04:01:27 EDT
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.
Comment 51 Jason Tibbitts 2015-07-16 09:53:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.