Description of problem: I just reinstalled F33 from scratch. I'm trying to print. There's a magically discovered printer that doesn't work right, can't be configured, and can't be renamed. It also can't be removed. Version-Release number of selected component (if applicable): system-config-printer-libs.noarch 1.5.13-2.fc33 @updates system-config-printer-udev.x86_64 1.5.13-2.fc33 @updates How reproducible: 100% Steps to Reproduce: 1. open system-config printer 2. unlock 3. remove magic printer Actual results: printer disappears, but reappears when revisiting the config page Expected results: printer should disappear Additional info: the same holds true for trying to rename the printer. The following logs are from trying to remove the printer, starting with clicking into the printers page from the main system settings: Dec 15 16:51:44 localhost.localdomain cupsd[49494]: REQUEST localhost - - "POST / HTTP/1.1" 200 347 Create-Printer-Subscriptions successful-ok Dec 15 16:51:48 localhost.localdomain cupsd[49494]: REQUEST localhost - - "POST / HTTP/1.1" 200 6821189 CUPS-Get-PPDs - Dec 15 16:51:49 localhost.localdomain wpa_supplicant[1323]: wlp0s20f3: Reject scan trigger since one is already pending Dec 15 16:51:50 localhost.localdomain geoclue[2181]: Failed to query location: Forbidden Dec 15 16:51:54 localhost.localdomain systemd[1]: dbus-:1.15-org.opensuse.CupsPkHelper.Mechanism: Succeeded. Dec 15 16:51:54 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.15-org.opensuse.CupsPkHelper.Mechanism@9 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 15 16:51:57 localhost.localdomain geoclue[2181]: Failed to query location: Forbidden Dec 15 16:52:01 localhost.localdomain systemd[1]: Started dbus-:1.15-org.opensuse.CupsPkHelper.Mechanism. Dec 15 16:52:01 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dbus-:1.15-org.opensuse.CupsPkHelper.Mechanism@10 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 15 16:52:01 localhost.localdomain cupsd[49494]: REQUEST localhost - - "POST /admin/ HTTP/1.1" 200 181 CUPS-Delete-Printer client-error-not-found Dec 15 16:52:01 localhost.localdomain gnome-control-c[46223]: cups-pk-helper: removing of printer HP_Color_LaserJet_MFP_M277dw_1292F1_ failed: client-error-not-found
Hi Erik, thank you for reporting the issue! Are you sure you are using system-config-printer? Because your log shows you use gnome-control-center: >Dec 15 16:52:01 localhost.localdomain gnome-control-c[46223]: cups-pk-helper: removing of >printer HP_Color_LaserJet_MFP_M277dw_1292F1_ failed: client-error-not-found The fact the configuration tool is started from system settings doesn't mean it is system-config-printer. It depends on desktop environment you are using - iirc system-config-printer is used only in xfce, other desktops have its own control centers. So about the "magic" print queue, it helps a lot if a connection type is supplied in initial description (connected via ethernet, wifi or usb). Let's assume printer is connected via wifi, because the model has 'w' in its name, HP does it for models which are capable of connecting via wifi, but I'm not sure if it is capable of connecting by other means. Then we go to gnome-control-center (g-c-c) - g-c-c is implemented in GTK, which uses 2 ways how to find printers and creates print queue for it: 1) ask CUPS for permanent printers 2) ask Avahi for printing services in local network Type 1) can be easily removed, because it resides in CUPS, so my educated guess is your 'magic' printer is Type 2). In CUPS those Type 2) queues are called temporary queues, but GTK handles them differently. In CUPS, the temporary queue isn't seen among permanent queues, because it is meant to appear only when you need it - they appear in print dialog, and they disappear after successful printing. However, GTK searches printing services via Avahi even for g-c-c and doesn't indicate it is a temporary queue, so it cannot be removed, because Avahi still reports it. If you try to remove it, GTK sends the 'delete' request to CUPS, but CUPS cannot delete it too, because the queue doesn't exist. IMO GTK should know if the queue is created from Avahi response and doesn't contact CUPS about removing it. I talked with GTK maintainer about possible solutions how to make it clear it is a temporary queue - the current understanding is there will be message about the queue being a temporary one and an option to make it permanent. However, even a print queue discovered via Avahi should work - currently, there is a GTK bug about it - https://bugzilla.redhat.com/show_bug.cgi?id=1784449 . It covers all GTK work connected to temporary queues. I'll close this bug as a duplicate of #1784449. Please inform me if any of my assumptions are wrong and will re-evaluate the issue. *** This bug has been marked as a duplicate of bug 1784449 ***
So, all of your assumptions are correct. Part of the issue is that the avahi discovery of the printer isn't completely functional. For example, I can't set the color settings. They don't even show up. That's a separate bug, though.