Hide Forgot
Description of problem: After updating from F18 to F19 new cups fails to show the printers available on our network. Version-Release number of selected component (if applicable): cups-1.6.2-7.fc19.x86_64 How reproducible: 100% Steps to Reproduce: 1. install F18 2. setup cups to browse network printers 3. update to F19 Actual results: no printers in the print dialog (tried evince & firefox) Expected results: automatically migrated settings from old cups Additional info: I noticed, that this line has been migrated from cupsd.conf, but it doesn't seem to have any effect # Settings automatically moved from cupsd.conf by RPM package: BrowsePoll <our network>
(In reply to Jiri Moskovcak from comment #0) > # Settings automatically moved from cupsd.conf by RPM package: > BrowsePoll <our network> That's from cups-browsed.conf, right ? There should also be a note that you need to start&enable cups-browsed service, isn't it there ? Well, yes, it could be perceived as some sort of regression and we already discussed it: <jpopelka> I've been thinking about enabling cups-browsed during install if BrowsePoll was moved from cupsd.conf to cups-browsed.conf. Not sure whether we need a FESCo approval (https://fedoraproject.org/wiki/Starting_services_by_default) for this or something similar. <twaugh> Oh, good point <twaugh> Another thing that I thought yesterday was: we do want to try to get people to migrate to using mDNS <twaugh> So we could migrate the settings but maybe not enable the service by default, maybe? <twaugh> That way it's easy to enable it, but it's also easy to get mDNS working (if it's going to work) <jpopelka> not sure I understand. mDNS == Avahi support in cups ? service == cups-browsed ? If cups-browsed is running the mDNS doesn't work ? <twaugh> mDNS == Avahi support in cups <twaugh> service == cups-browsed <twaugh> If cups-browsed is running, won't that conflict with CUPS's native mDNS browsing? <twaugh> e.g. remote BrowsePolled server might be advertising queues with mDNS. Don't want duplicates.
(In reply to Jiri Popelka from comment #1) > (In reply to Jiri Moskovcak from comment #0) > > # Settings automatically moved from cupsd.conf by RPM package: > > BrowsePoll <our network> > - yes > That's from cups-browsed.conf, right ? > There should also be a note that you need to start&enable cups-browsed > service, isn't it there ? - great, that helped - but still I find it very inconvenient and not user friendly, that service should be started by default
After further investigation I can see that gtk3 has had the ability to use DNS-SD to discover network CUPS queues since 3.7.12 (in March). This works in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2 rather than gtk3. To adjust the CUPS server so that it advertises queues using DNS-SD, make sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf, like this: BrowseLocalProtocols CUPS dnssd (this is the default)
(In reply to Tim Waugh from comment #4) > After further investigation I can see that gtk3 has had the ability to use > DNS-SD to discover network CUPS queues since 3.7.12 (in March). This works > in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2 > rather than gtk3. > > To adjust the CUPS server so that it advertises queues using DNS-SD, make > sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf, > like this: > > BrowseLocalProtocols CUPS dnssd > > (this is the default) That doesn't work for me even though it seems it's set properly: grep "BrowseLocal" /etc/cups/cupsd.conf BrowseLocalProtocols CUPS dnssd gtk3-3.8.2-1.fc19.x86_64 service cups status Redirecting to /bin/systemctl status cups.service cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled) Active: active (running) since Fri 2013-06-07 08:45:14 CEST; 1h 45min ago Main PID: 2205 (cupsd) And there are no printers in Evince, but they appear when I start cups-browsed.
Perhaps you don't have the avahi daemon running, or the mDNS communications are blocked by the firewall?
Or cups server (running RHEL-6 I guess) in our (mine and reporters) network does not advertise printers via DNS-SD.
(In reply to Tim Waugh from comment #4) > After further investigation I can see that gtk3 has had the ability to use > DNS-SD to discover network CUPS queues since 3.7.12 (in March). This works > in e.g. gedit and Evince, but does not work in Firefox because it uses gtk2 > rather than gtk3. > > To adjust the CUPS server so that it advertises queues using DNS-SD, make > sure "dnssd" is in the BrowseLocalProtocols list in /etc/cups/cupsd.conf, > like this: > > BrowseLocalProtocols CUPS dnssd > > (this is the default) To be clear, I'm talking about making this BrowseLocalProtocols change on the CUPS *server*, not the cupsd scheduler instance running on the local machine. If the CUPS server is only advertising queues using CUPS Browsing, the Fedora 19 clients will need to use cups-browsed from the cups-filters package.
> To be clear, I'm talking about making this BrowseLocalProtocols change on > the CUPS *server*, not the cupsd scheduler instance running on the local > machine. > > If the CUPS server is only advertising queues using CUPS Browsing, the > Fedora 19 clients will need to use cups-browsed from the cups-filters > package. Invoking cups-browsed as root has things working, but I think a systemd script is missing in F19 to startup the cups-browsed.service. Or am I off track here?
(In reply to Harish Pillay from comment #12) > Invoking cups-browsed as root has things working, but I think a systemd > script is missing in F19 to startup the cups-browsed.service. Or am I off > track here? It's not missing on my F19 system: # systemctl status cups-browsed cups-browsed.service - Make remote CUPS printers available locally Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled) Active: active (running) since Wed 2013-06-12 14:57:49 CEST; 2 weeks 6 days ago Main PID: 628 (cups-browsed) CGroup: name=systemd:/system/cups-browsed.service └─628 /usr/sbin/cups-browsed # rpm -qf /usr/lib/systemd/system/cups-browsed.service cups-filters-1.0.34-1.fc19.x86_64
(In reply to Honza Horak from comment #13) > (In reply to Harish Pillay from comment #12) > > Invoking cups-browsed as root has things working, but I think a systemd > > script is missing in F19 to startup the cups-browsed.service. Or am I off > > track here? > > It's not missing on my F19 system: > > # systemctl status cups-browsed > cups-browsed.service - Make remote CUPS printers available locally > Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled) > Active: active (running) since Wed 2013-06-12 14:57:49 CEST; 2 weeks 6 > days ago > Main PID: 628 (cups-browsed) > CGroup: name=systemd:/system/cups-browsed.service > └─628 /usr/sbin/cups-browsed > > # rpm -qf /usr/lib/systemd/system/cups-browsed.service > cups-filters-1.0.34-1.fc19.x86_64 Indeed you are right. I've just checked and yes, the service is there but it was dead. Restarted it and looks like all's well.
It was dead because it's not enabled by default (for reason see comment #1). 'systemctl enable cups-browsed.service' should do the trick.
(In reply to Jiri Popelka from comment #15) > It was dead because it's not enabled by default (for reason see comment #1). > 'systemctl enable cups-browsed.service' should do the trick. yep. did that. thanks.
I don't think this is my problem but I want to confirm. I had F18->F18 printer discovery working. When I upgraded (via fedup) my desktop to F19 (which is the "print server") my wife's F18 laptop can no longer discover the printer. I have disabled the firewall on both ends to no avail. I copied cupsd.conf.rpmnew over my config (which seems to drop CUPS browsing) but that didn't fix things either. Do I need the cups-browsed service?
(In reply to Richard Shaw from comment #17) > I don't think this is my problem but I want to confirm. > > I had F18->F18 printer discovery working. When I upgraded (via fedup) my > desktop to F19 (which is the "print server") my wife's F18 laptop can no > longer discover the printer. I have disabled the firewall on both ends to no > avail. I copied cupsd.conf.rpmnew over my config (which seems to drop CUPS > browsing) but that didn't fix things either. > > Do I need the cups-browsed service? Yes, you need the cups-browsed service. See #15 and #16 above. Harish
But really. Given the prevalence of non-GTK3 applications out there still (hello Libre Office, Chrome, Firefox, etc.), who(!) isn't going to want cups-browsed enabled?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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 19 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.
I don't see any activity here that suggests that this has changed even as of F21 so can we please have the Version: field updated to F21?
This is not anything to do with non-GTK3 applications. Applications having trouble printing need to be migrated to the new discovery method. Applications using libcups for discovery will already work fine. It's only the applications using their own special discovery mechanisms that need work.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.