Bug 1567984 - Some gtk and qt apps show duplicates of print queues
Summary: Some gtk and qt apps show duplicates of print queues
Keywords:
Status: CLOSED DUPLICATE of bug 1765328
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 30
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-16 14:05 UTC by Attila
Modified: 2020-02-17 17:08 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-17 17:08:33 UTC
Type: Bug
caolanm: needinfo-


Attachments (Terms of Use)
Print dialog (21.20 KB, image/png)
2018-04-16 14:07 UTC, Attila
no flags Details
Debug of cups-browsed (116.47 KB, text/x-vhdl)
2018-04-18 09:02 UTC, Attila
no flags Details
System Settings (printer) (117.15 KB, image/png)
2018-04-23 07:45 UTC, Attila
no flags Details
lpstat -t with statement RemoteName (1.44 KB, text/plain)
2018-04-25 07:27 UTC, Attila
no flags Details
lpstat -t NO statement RemoteName (2.06 KB, text/plain)
2018-04-25 07:29 UTC, Attila
no flags Details
cupsd.conf from fileserver (3.03 KB, text/plain)
2018-04-26 11:25 UTC, Attila
no flags Details
cupsd.conf from workstation (6.14 KB, text/plain)
2018-04-26 11:25 UTC, Attila
no flags Details
cups-browsed.conf from workstation (25.59 KB, text/plain)
2018-04-26 11:26 UTC, Attila
no flags Details

Description Attila 2018-04-16 14:05:55 UTC
Hi,

I have added the statements "BrowsePoll fileserver" and "LocalQueueNamingRemoteCUPS RemoteName" to cups-browsed to be able to print and see all the remote printers on my Fedora 27 client.

When I want to print from LibreOffice I see unfortunately all the printers twice and one of them 3 times. The same from all KDE applications (based on Qt), see attachment. On Firefox and Thunderbird (based on Gtk) all the printers appear one time as expected. This is very chaotic and confusing.
Besides the print dialog from every application takes 3 to 4 seconds to appear. On Fedora 26 and before the print dialog was open immediately.

My first question is:
Is there a way to normalize the list of printers as it was on Fedora 26 and before?

My second question is:
Is there a way to accelerate the print dialog, so that it appears directly as it was on Fedora 26 and before?

Comment 1 Attila 2018-04-16 14:07:52 UTC
Created attachment 1422552 [details]
Print dialog

Comment 2 Zdenek Dohnal 2018-04-16 14:11:50 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1525937#c7

>'lpstat -a' doesn't return duplicates of print queues.

So does it return duplicate print queues or not? In this bugzilla you say otherwise.

If 'lpstat -a' doesn't return duplicates, issue isn't in cups or cups-filters, but in app using it.

Comment 3 Attila 2018-04-16 14:29:26 UTC
(In reply to Zdenek Dohnal from comment #2)
> https://bugzilla.redhat.com/show_bug.cgi?id=1525937#c7
> 
> >'lpstat -a' doesn't return duplicates of print queues.
> 
> So does it return duplicate print queues or not? In this bugzilla you say
> otherwise.


I am really sorry (was in hurry).
'lpstat -a' doesn't return duplicates of print queues.


> 
> If 'lpstat -a' doesn't return duplicates, issue isn't in cups or
> cups-filters, but in app using it.

Comment 4 Caolan McNamara 2018-04-16 15:56:41 UTC
"The same from all KDE applications (based on Qt)" so if there's a libreoffice bug those other apps will remaining affected if I can fix the apparent libreoffice problem. That said, unfortunately I can't reproduce it with a similar setup. I don't get any duplicated on F27.

Comment 5 Attila 2018-04-17 09:12:17 UTC
I think this isn't a LibreOffice bug.
Fact is that cups-browsed has changed from Fedora 26 to 27. That's why I don't see any printer on my Fedora 27 clients served by Fedora 26, except I add those two lines (BrowsePoll, LocalQueueNamingRemoteCUPS) to cups-browsed on every client.

Is there anything I can do to help you investigating this issue? Do you need additional info?

Comment 6 Caolan McNamara 2018-04-17 10:50:25 UTC
It seems to affect all/some KDE apps ? Maybe try a specific KDE bug if it affects all KDE applications, that might shake something lose.

Comment 7 Zdenek Dohnal 2018-04-17 11:04:02 UTC
cups-browsed is discovering printers and creates local print queues for them for local cups daemon. So if 'lpstat -a' doesn't show duplicates of print queues, that means cups-browsed or cups don't create duplicates...
Maybe these apps do discovery on its own (I know gtk has implemented its printing functions based on cups-libs, but not sure if qt...) and it creates duplicates?

Comment 8 Caolan McNamara 2018-04-17 13:00:00 UTC
AFAICS we just call cupsGetDests2 https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/generic/printer/cupsmgr.cxx#n209

Comment 9 Attila 2018-04-17 13:21:59 UTC
One more interesting info:

When I remove the line "LocalQueueNamingRemoteCUPS RemoteName" from cups-browsed, I get the following result:

- For all Qt-Applications: I see all printer once in the print dialog with their "description".

- For all Gtk-Applications: I see now suddenly all printer twice in the print dialog with their "name" and "description".

- For LibreOffice: The same as for all Qt-Applications.

To me as user it is very weird.

Any idea?

Comment 10 Zdenek Dohnal 2018-04-17 14:01:29 UTC
Would you mind trying to set cups-browsed to debug mode, see https://fedoraproject.org/wiki/How_to_debug_printing_problems#Gathering_debug_information_from_cups-browsed
and attach its debug log after service restart with command:

$ journalctl -u cups-browsed --since=time-of-restart > cups-browsed.debug

?

Comment 11 Zdenek Dohnal 2018-04-17 14:06:08 UTC
And what happens when you add 'AutoClustering Yes' to /etc/cups/cups-browsed.conf and restart service?

Comment 12 Attila 2018-04-18 09:01:36 UTC
(In reply to Zdenek Dohnal from comment #11)
> And what happens when you add 'AutoClustering Yes' to
> /etc/cups/cups-browsed.conf and restart service?

No changes. I see the printer twice. It doesn't help.

Comment 13 Attila 2018-04-18 09:02:51 UTC
Created attachment 1423398 [details]
Debug of cups-browsed

Comment 14 Zdenek Dohnal 2018-04-18 14:16:27 UTC
cups-browsed debug log showed correct creation of print queues:

Brother2250DN
ClusterDruck
EPSON7900
HP9050DN
HP9500DN
HPM880
DYMO_LabelWriter_400_Turbo

I have suspicion this is connected to patch for https://bugzilla.redhat.com/show_bug.cgi?id=1498091 in cups. I'll create testing package tomorrow.

Comment 15 Attila 2018-04-20 12:36:50 UTC
(In reply to Zdenek Dohnal from comment #14)

> I have suspicion this is connected to patch for
> https://bugzilla.redhat.com/show_bug.cgi?id=1498091 in cups. I'll create
> testing package tomorrow.

I can't await to test. Could you create a new package in the meantime or is it a bit tricky?

Comment 16 Zdenek Dohnal 2018-04-20 13:24:40 UTC
Sorry, I don't have much time - there is testing build with patch from upstream - patch was big and I had other pressing matters. https://koji.fedoraproject.org/koji/taskinfo?taskID=26469561

Comment 17 Attila 2018-04-23 07:44:33 UTC
(In reply to Zdenek Dohnal from comment #16)
> Sorry, I don't have much time - there is testing build with patch from
> upstream - patch was big and I had other pressing matters.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=26469561

Hi,

I am sorry to say, but the new packages don't help. Here is a list of installed "cups" packages on the client:

cups-2.2.4-11.fc27.x86_64
cups-client-2.2.4-11.fc27.x86_64
cups-filesystem-2.2.4-11.fc27.noarch
cups-filters-1.16.1-4.fc27.x86_64
cups-filters-libs-1.16.1-4.fc27.x86_64
cups-libs-2.2.4-11.fc27.x86_64
cups-pk-helper-0.2.6-4.fc27.x86_64

There is one interesting thing. When I excecute "systemsettings5" (System Settings by KDE) and choose printer, I see all the printer one time (see attachment). This seems to be the one and only Qt-Application which shows the list of printer correct. It's weird, isn't it?

Any new idea to try?

Comment 18 Attila 2018-04-23 07:45:50 UTC
Created attachment 1425571 [details]
System Settings (printer)

Comment 19 Zdenek Dohnal 2018-04-24 14:05:00 UTC
Hmm... Attila, what is your network topology? I have an idea (correct me if I'm wrong) - you have 2 servers, where all printers are installed and these server's IPs/hostnames you have in /etc/cups/cups-browsed.conf as BrowsePoll statement at client machine.
About 'LocalQueueNamingRemoteCUPS RemoteName' directive - cups-browsed creates print queue's names using DNS-SD ID of printer by default since cups-filters-1.16.0. Example of print queue:

printer1_example_com

, where printer1 can be various things - but mostly it's printer's make and model.

. But setting previous directive to 'RemoteName' makes cups-browsed to use print queue's names from remote servers as base for local print queues. Example:

printer1@example.com

where printer1 is print queue's name from server example.com. '@example.com' part is not necessary.

From the first attachment it looks like 'something' is discovering/creating/showing print queues both ways - e.g.:

Brother2250DN - as print queue created by remote print queue name
Brother_HL_2250DN_fileserver - as print queue created by DNS-SD ID 

AFAIK only component, which can create print queue, is cups - other components (e.g. cups-browsed, hplip, libreoffice, probably qt5-qtbase...) only communicate with CUPS by IPP protocol - that means they send requests like 'create-printer', 'create-job' etc... So if cups-browsed or cups created duplicate queues (which can be the case if CreateIPPPrinters can be set to All), it should be visible by 'lpstat -a' command...

Can you attach files with outputs of 'lpstat -t' once when you have 'LocalQueueNamingRemoteCUPS RemoteName' and restarted cups-browsed amd once when you don't have this directive and restarted cups-browsed?

Comment 20 Attila 2018-04-25 07:24:14 UTC
Hi,

just few words about the network topology.
I have got one server called "fileserver". All printer (except the "DYMO_LabelWriter_400_Turbo") are installed on this server and served by this machine to the clients. This is the cool way which works since more than a decade. The "DYMO_LabelWriter_400_Turbo" is served by a workstation which is connected via USB. That makes is possible to print from all clients to the LabelWriter.
I hate to repeat myself, but the fact is that cups-browsed has changed significant from Fedora 26 to 27.

I am going to attach the output from lpstat as requested.

Comment 21 Attila 2018-04-25 07:27:18 UTC
Created attachment 1426462 [details]
lpstat -t with statement RemoteName

Comment 22 Attila 2018-04-25 07:29:09 UTC
Created attachment 1426464 [details]
lpstat -t NO statement RemoteName

Comment 23 Attila 2018-04-25 12:31:02 UTC
Probably this could help? The printer on the server are installed as followed:

HP9500DN
socket://xxx.xxx.x.26:9100

HP9050DN
socket://xxx.xxx.x.22:9100

EPSON7900
dnssd://StylusPro7900-15A3D2._printer._tcp.local/

Brother2250DN
socket://xxx.xxx.x.27:9100

HPM880
dnssd://HP%20Color%20LaserJet%20flow%20MFP%20M880%20%5B37F096%5D._ipp._tcp.local/?uuid=3908b91e-ad0a-11e4-bd00-cf9b36ef9d36

Comment 24 Zdenek Dohnal 2018-04-26 08:55:46 UTC
As I said before - yes, cups-browsed changes a lot, it is expected and it isn't in my power to test every possible configuration. I'm thankful for such reports, Attila - it helps me to create better printing support.
Cups-browsed only automatically discover and creates local print queues for remote CUPS queues or network printers, so what you see by 'lpstat -t' or 'lpstat -a' is what is created by cups-browsed, if you don't have some manually created print queues.
What is interesting that in your first attachment I can see print queue names created by DNS-SD ID and print queues names created by remote queue name...

Would you mind attaching /etc/cups/cupsd.conf from workstations and fileserver and cups-browsed.conf from workstations? 

(In reply to Attila from comment #20)
> The "DYMO_LabelWriter_400_Turbo" is served by a workstation
> which is connected via USB. 
Like you have other workstation, which is this printer connected to by USB, and workstation, which you see duplicates on, is connected to this other workstation by ethernet?

Comment 25 Attila 2018-04-26 11:23:10 UTC
I am glad to hear that I am in best hands. You must be a CUPS guru, aren't you? I hope I may say that. Sure you can not test every possible configuration. Therefore I am here as a user and would like to provide you any information you need. A better printing support is also my goal.

The printer "DYMO_LabelWriter_400_Turbo" has only USB and is connected to one workstation which serves to the others.

I am going to attach the requested files.

Comment 26 Attila 2018-04-26 11:25:03 UTC
Created attachment 1427149 [details]
cupsd.conf from fileserver

Comment 27 Attila 2018-04-26 11:25:52 UTC
Created attachment 1427150 [details]
cupsd.conf from workstation

Comment 28 Attila 2018-04-26 11:26:29 UTC
Created attachment 1427151 [details]
cups-browsed.conf from workstation

Comment 29 Attila 2018-05-03 09:44:56 UTC
Hi,

could you analyse the requested "conf" files in the meantime? Anything wrong with them?

Comment 30 Zdenek Dohnal 2018-05-03 10:00:10 UTC
They don't seem bad... I think if you are okay with print queues created by cups-browsed without 'LocalQueueNamingRemoteCUPS RemoteName', you can use that for now (that settings is mainly for cups<1.5). With downside of duplicates for GTK apps.

Caolan, is there a way to get printer uri of discovered print queues in Libreoffice?

Comment 31 Caolan McNamara 2018-05-03 10:23:22 UTC
As in "printer-uri-supported" or "device-uri" ? no, we don't have any way to dump those.

Comment 32 Attila 2018-05-04 08:41:15 UTC
I could remove the line "LocalQueueNamingRemoteCUPS RemoteName" from cups-browsed.conf and yes, I would see duplicates and their "description" in the print dialog instead of their "names".
This could be a temporary solution but there is one thing I have mentioned earlier:

The print dialog takes from every application 3 to 5 seconds to appear. During this time the application doesn't response and the mouse pointer is invisible inside the window of the application (example Kwrite, always reproducible).
This is a really bad performance and user experience.

What do you think, how long does it take to fix this bug or could you fix it step by step. The first step could be a fix to improve the performance, so that the print dialog would appear immediately as it was on Fedora 26 and before? This would help a lot.

Comment 33 Zdenek Dohnal 2018-05-04 09:17:47 UTC
(In reply to Attila from comment #32)
> I could remove the line "LocalQueueNamingRemoteCUPS RemoteName" from
> cups-browsed.conf and yes, I would see duplicates and their "description" in
> the print dialog instead of their "names".
But only in GTK apps?

> The print dialog takes from every application 3 to 5 seconds to appear.
> During this time the application doesn't response and the mouse pointer is
> invisible inside the window of the application (example Kwrite, always
> reproducible).
> This is a really bad performance and user experience.
This can outcome of various reasons - from PC HW, app itself, CUPS, network, server and printer itself... hard to tell where the problem lies. 
> 
> What do you think, how long does it take to fix this bug or could you fix it
> step by step. The first step could be a fix to improve the performance, so
> that the print dialog would appear immediately as it was on Fedora 26 and
> before? This would help a lot.
I'm sorry, I'm grateful for your cooperation, but I have now other pressing matters to attend to, so I see this issue whenever I have some free time. The fact I'm not able to reproduce it makes it even more difficult. And IMHO, this issue doesn't block anyone to print.

Comment 34 debiantriage 2018-11-21 14:18:51 UTC
I use Debian (cups 2.2.9 and cups-browsed 1.21.3) but cannot imagine there is any significant difference in this instance between its printing system and that of Red Hat/Fedora. This post concerns Comment 1 and Comment 9 and the observations regarding the GTK print dialog.

This dialog is populated from the locally set up queues and by *directly* browsing the DNS-SD broadcasts of the remote print server and IPP printers. Whether cups is running or not, this is what happens. In fact, neither CUPS nor cups-browsed is required for the GTK print dialog to function as designed.

Suppose cups-browsed is running with its default cups-browsed.conf. It too will browse the same DNS-SD broadcasts and also populate the dialog, leading to duplicate entries. This is what is observed in Comment 9. If you really, really want cups-browsed, these duplicate entries can be removed by using the filtering facility available in cups-browsed.conf.

cups-browsed.conf in Comment 1 has "LocalQueueNamingRemoteCUPS RemoteName" as a non-default option. This directive is based on a change in cups 2.2.4 which introduced the concept of temporary queues (please see the Debian wiki) and "LocalQueueNamingRemoteCUPS" renames a temporary queue. But the GTK print dialog is clueless about what CUPS can do, so no renaming takes place and we get what is observed in Comment 1.

-- 
Brian.

Comment 35 debiantriage 2018-11-21 14:33:26 UTC
This post concerns Comment 1 and Comment 9 and the observations regarding the Qt and LibreOffice print dialogs. These dialogs need to have cupsd (but not cups-browsed) available to enumerate print queues and IPP printers and are therefore aware of the existence of its ability to create a temporary queue. By themselves they will display and print to these queues.

Now start cups-browsed. It too knows about CUPS' temporary queues and, by default, avoids producing duplicate entries. It does this by hijcking the temporary queue name and creating a local queue with it. This is seen to happen in Comment 9. In Comment 1 "LocalQueueNamingRemoteCUPS" does not take over the temporary queue name but renames it to form a local queue; hence the duplicate entries.

The bottom line is: unless there is a special reason, cups-browsed is not needed.
GTK apps do their own thing to create entries in a dialog; LibreOffice and Qt apps use the CUPS temporary queue mechanism; command line apps have 'lpstat -e'.

-- 
Brian.

Comment 36 Zdenek Dohnal 2018-11-22 09:25:53 UTC
Hi Brian!

Thank you for the information! I didn't know such details how gui apps use the printing system exactly, thanks for a big help!

Comment 37 Ben Cotton 2018-11-27 13:30:44 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 38 Ben Cotton 2019-05-02 20:14:30 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 39 Zdenek Dohnal 2020-02-17 17:08:33 UTC
Hi Attila,

I'm sorry for long inactivity.

Brian's comments explained the things to me - the problem is about mixing 3 things together - gtk print library, cups temporary queues and cups-browsed, which all can result in this mess under certain circumstances.

With LocalQueueNamingRemoteCUPS set - cups-browsed makes temporary queues from cups permanent and then rename them - this way CUPS thinks they do not exist yet (they check it by name) so it advertises it. Then applications which uses cups temporary queues sees it twice and removing LocalQueueNamingRemoteCUPS fixes it.

Ad Gtk dialog - I'm not quite sure how things goes there except for they are querying avahi directly and they do not use CUPS at all - probably it sees local name created by cups-browsed and by avahi? I'm not really sure.

Anyway, because your print queues are available as cups temporary queues, you can do the thing Brian suggested - turning off cups-browsed. cups-browsed is useful for two use cases - when you need to have print queues based on CUPS broadcasting (cups-1.5 and older) or in different network, or when you want to have those temporary queue permanent. IMO you are perfectly fine with temporary queues on the client.

You can check whether your printers are available as temporary queues by 'lpstat -e'.

Ad performance of print dialog, IMO 2-3 seconds are fine for the case - dialog shows more printers and it asks for their properties.

I have a plan to work with gtk people on simplifying things for modern users (LocalQueueNamingRemoteCUPS is more usable for clients, which depends on old cups-1.5 and older servers) to prevent such configuration issues which are not simple bugs. Hopefully this year I'll get into it.

I track those two features for gtk/gnome here  https://bugzilla.redhat.com/show_bug.cgi?id=1784449 and https://bugzilla.redhat.com/show_bug.cgi?id=1765328 , so I'm closing this as dupe.

*** This bug has been marked as a duplicate of bug 1765328 ***


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