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?
Created attachment 1422552 [details] Print dialog
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.
(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.
"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.
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?
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.
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?
AFAICS we just call cupsGetDests2 https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/generic/printer/cupsmgr.cxx#n209
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?
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 ?
And what happens when you add 'AutoClustering Yes' to /etc/cups/cups-browsed.conf and restart service?
(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.
Created attachment 1423398 [details] Debug of cups-browsed
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.
(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?
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
(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?
Created attachment 1425571 [details] System Settings (printer)
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 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?
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.
Created attachment 1426462 [details] lpstat -t with statement RemoteName
Created attachment 1426464 [details] lpstat -t NO statement RemoteName
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
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?
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.
Created attachment 1427149 [details] cupsd.conf from fileserver
Created attachment 1427150 [details] cupsd.conf from workstation
Created attachment 1427151 [details] cups-browsed.conf from workstation
Hi, could you analyse the requested "conf" files in the meantime? Anything wrong with them?
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?
As in "printer-uri-supported" or "device-uri" ? no, we don't have any way to dump those.
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.
(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.
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.
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.
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!
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.
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.
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 ***