Issue is still present in 20200819.n.1 compose. The issue may be HP specific. I believe this is the relevant section of the journal:

Aug 20 13:40:24 localhost.localdomain polkitd[711]: Operator of unix-session:2 successfully authenticated as unix-user:test to gain TEMPORARY authorization for action org.opensuse.cupspkhelper.mechanism.all-edit for unix-process:2545:25863 [gnome-control-center] (owned by unix-user:test)
Aug 20 13:40:26 localhost.localdomain systemd[1]: Created slice system-dbus\x2d:1.14\x2dorg.opensuse.CupsPkHelper.Mechanism.slice.
Aug 20 13:40:26 localhost.localdomain systemd[1]: Started dbus-:1.14-org.opensuse.CupsPkHelper.Mechanism.
Aug 20 13:40:26 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.14-org.opensuse.CupsPkHelper.Mechanism@0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - - "POST / HTTP/1.1" 401 98 CUPS-Get-Devices successful-ok
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 173 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 327 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 176 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain kernel: lp0: using parport0 (interrupt-driven).
Aug 20 13:40:26 localhost.localdomain kernel: lp0: console ready
Aug 20 13:40:26 localhost.localdomain systemd[1503]: Reached target Printer.
Aug 20 13:40:26 localhost.localdomain systemd[1]: Reached target Printer.
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 323 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 322 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 331 CUPS-Get-Devices -
Aug 20 13:40:26 localhost.localdomain hp[2681]: io/hpmud/pp.c 627: unable to read device-id ret=-1
Aug 20 13:40:26 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 314 CUPS-Get-Devices -
Aug 20 13:40:30 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 175 CUPS-Get-Devices -
Aug 20 13:40:32 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 174 CUPS-Get-Devices -
Aug 20 13:40:32 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 179 CUPS-Get-Devices -
Aug 20 13:40:32 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 320 CUPS-Get-Devices -
Aug 20 13:40:32 localhost.localdomain systemd[1503]: Created slice dbus\x2d:1.2\x2dorg.fedoraproject.Config.Printing.slice.
Aug 20 13:40:32 localhost.localdomain systemd[1503]: Started dbus-:1.2-org.fedoraproject.Config.Printing.
Aug 20 13:40:32 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 173 CUPS-Get-Devices -
Aug 20 13:40:33 localhost.localdomain scp-dbus-service[2728]: /usr/share/system-config-printer/scp-dbus-service.py:602: DeprecationWarning: Gdk.threads_enter is deprecated
Aug 20 13:40:33 localhost.localdomain scp-dbus-service[2728]:   Gdk.threads_enter ()
Aug 20 13:40:33 localhost.localdomain python3[2737]: io/hpmud/model.c 546: no HP_Integrated_Module attributes found in /usr/share/hplip/data/models/models.dat
Aug 20 13:40:33 localhost.localdomain python3[2737]: io/hpmud/model.c 557: no HP_Integrated_Module attributes found in /usr/share/hplip/data/models/unreleased/unreleased.dat
Aug 20 13:40:33 localhost.localdomain python3[2737]: io/hpmud/musb.c 2129: ignoring hp:/usb/HP_Integrated_Module?serial=0 support=0
Aug 20 13:40:33 localhost.localdomain python3[2737]: io/hpmud/pp.c 627: unable to read device-id ret=-1
Aug 20 13:40:33 localhost.localdomain cupsd[769]: REQUEST localhost - root "POST / HTTP/1.1" 200 316 CUPS-Get-Devices -
Aug 20 13:40:35 localhost.localdomain gnome-control-c[2545]: g_signal_connect_object: assertion 'G_IS_OBJECT (gobject)' failed
Aug 20 13:40:35 localhost.localdomain gnome-control-c[2545]: g_signal_connect_object: assertion 'G_IS_OBJECT (gobject)' failed
Aug 20 13:40:35 localhost.localdomain gnome-control-c[2545]: g_signal_connect_object: assertion 'G_IS_OBJECT (gobject)' failed

Still seen with 20200912.n.0 compose.

Reverting upstream commit 4502673b[0] for pp-ppd-selection-dialog.c[1] fixes the issue. Upstream ticket 1126[2] references this issue.

[0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/4502673b6c2584cbcd116c782fc0b6c8392e3e3d
[1] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/master/panels/printers/pp-ppd-selection-dialog.c
[2] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1126

I have submitted a fix upstream: https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/842

Yes, I can confirm this, too. I was able to override this by providing a PPD file instead looking for a driver. Also, the web interface to CUPS is not affected by this problem.

Proposed as a Blocker and Freeze Exception for 33-beta by Fedora user lruzicka using the blocker tracking app because:

 Proposing to discuss this as a possible blocker. The problem can be overriden, but is an annoying behaviour.

Printing
Printing must work in release-blocking desktops on at least one printer available to those performing validation testing.

(In reply to Lukas Ruzicka from comment #5)
> Yes, I can confirm this, too. I was able to override this by providing a PPD
> file instead looking for a driver.

How do you find that PPD file? (If we want to document a workaround for people).

I can successfully add a Canon iR-ADB C256 by specifying the IP address in gnome-control-center-3.38.0-1.fc33.x86_64 without hitting this issue. It's definitely not universal.

Rejected as a Beta blocker, but I can't mark it here yet, because it's also proposed as a Final blocker, and that is still undecided:
https://pagure.io/fedora-qa/blocker-review/issue/124

(In reply to Kamil Páral from comment #7)
> (In reply to Lukas Ruzicka from comment #5)
> > Yes, I can confirm this, too. I was able to override this by providing a PPD
> > file instead looking for a driver.
> 
> How do you find that PPD file? (If we want to document a workaround for
> people).

Well, if there are no drivers in Cups, you can provide a PPD file, but that file needs to be a correct PPD file for your printer. I was able to dig mine out of the Windows drivers. 

Some printer drivers can be found via openprinting.org. Otherwise, it is just moving across the www jungle.

Anything that uses a flow that automatically selects a PPD (printers with only one PPD listed in CUPS I assume?) should be unaffected. I currently don't have any printers here where that's the case.

Anything that requires selecting a PPD manually is broken. As is the flow for changing the PPD for an already configured printer (Gear Icon -> Printer Details -> Select From Database...).

(In reply to Kamil Páral from comment #9)
> Rejected as a Beta blocker, but I can't mark it here yet, because it's also
> proposed as a Final blocker, and that is still undecided:
> https://pagure.io/fedora-qa/blocker-review/issue/124

Marking as a proposed F33 Final blocker and removing the F33 Beta blocker status.

(In reply to Brandon Nielsen from comment #11)
> Anything that uses a flow that automatically selects a PPD (printers with
> only one PPD listed in CUPS I assume?) should be unaffected. I currently
> don't have any printers here where that's the case.
> 
> Anything that requires selecting a PPD manually is broken. As is the flow
> for changing the PPD for an already configured printer (Gear Icon -> Printer
> Details -> Select From Database...).

Sure, but there is also the "Provide PPD file" button which works as expected for me. Can you confirm?

FEDORA-2020-151cfda095 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-151cfda095

FEDORA-2020-4d1f0627eb has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4d1f0627eb

(In reply to Lukas Ruzicka from comment #13)
> 
> Sure, but there is also the "Provide PPD file" button which works as
> expected for me. Can you confirm?

I should have been clearer. I was just stating that the "Select Printer Driver" PPD selection dialog does not work so anything that uses it does not work.

I do not see any flow in gnome-control-center for the printers I have here (network connected HP JetDirect printers) that avoids using that dialog. I don't see a way to use "Provide PPD file" until the printer already appears in the Printers panel, which requires me to first go through the "Add..." flow, which requires the broken "Select Printer Driver" dialog.

After a printer is added (say, via CUPS web interface) and appears in the Printers panel, I can get to the "Select PPD file" dialog by Gear Icon -> Printer Details -> Install PPD File..., That dialog works.

There are printers which can be added that do not require the manual PPD selection step, I do not have one here. Apparently you have a printer which does not automatically select a PPD, but is discovered in such a way that it appears in the Printers panel which in turn allows you to select a PPD via Printer Details?

Because of the issues above, I think configuring a printer through the CUPS web interface at localhost:631 is the better workaround to document, it provides both the selection list, and the option to provide a PPD file.

At some level, I feel like I should suggest adding the "Provide PPD file" button to the "Select Printer Driver" dialog upstream, otherwise I don't know how you ever add a network printer which isn't automatically discovered for which CUPS does not provide a PPD. I guess you first select a wrong PPD, then go back and fix it?

FEDORA-2020-151cfda095 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-151cfda095 \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-151cfda095

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-4d1f0627eb has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-4d1f0627eb \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4d1f0627eb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I don't see why the above builds of toot reference this bug.

The commit causing the issue has been reverted in the Gnome 3.38 branch: https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/847

(In reply to Brandon Nielsen from comment #19)
> I don't see why the above builds of toot reference this bug.

OMG! Sorry.
I think that I had this bug and the one related to the review of the toot package opened in my browser. And I copied and pasted this bug id in the bodhi update request instead of the other one :facepalm:

Discussed during the 2020-09-28 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"Printing must work in release-blocking desktops on at least one printer available to those performing validation testing."

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-28/f33-blocker-review.2020-09-28-16.01.txt

(In reply to Brandon Nielsen from comment #16)


> I do not see any flow in gnome-control-center for the printers I have here
> (network connected HP JetDirect printers) that avoids using that dialog. I
> don't see a way to use "Provide PPD file" until the printer already appears
> in the Printers panel, which requires me to first go through the "Add..."
> flow, which requires the broken "Select Printer Driver" dialog.

I do not have an option to test network printers, so I am only testing a local laser printer
Konica Minolta Bizhub 20P which is a problematic printer that has only a limited
support in CUPS itself. Therefore, I am using a PPD file to set it up.

> There are printers which can be added that do not require the manual PPD
> selection step, I do not have one here. Apparently you have a printer which
> does not automatically select a PPD, but is discovered in such a way that it
> appears in the Printers panel which in turn allows you to select a PPD via
> Printer Details?

The printer is automatically detected and always appears in the Printers list with a warning that
a driver could not be found and a generic driver (which only poorly works) has been selected.
Then I need to provide the PPD file by myself to be able to print properly.

> 
> Because of the issues above, I think configuring a printer through the CUPS
> web interface at localhost:631 is the better workaround to document, it
> provides both the selection list, and the option to provide a PPD file.

Yeah, localhost:631 has always worked for me, whenever there was an issue with the printer.

> 
> At some level, I feel like I should suggest adding the "Provide PPD file"
> button to the "Select Printer Driver" dialog upstream, otherwise I don't
> know how you ever add a network printer which isn't automatically discovered
> for which CUPS does not provide a PPD. I guess you first select a wrong PPD,
> then go back and fix it?

Maybe I am wrong, but I have always thought that a remote printer is configured on its host server and therefore
I only to send the printing data over and I do not need to know about the driver (or PPD) as it should be
communicated to my workstation from there.

The latest development update is in comment 4, fixing status.

I was trying again with the latest updates and the situation is still the same for me. I also tried to set up a network printer on one CUPS to see how that behaves with network printers and what happened:

1) I started gnome-settings and navigated to Printers
2) I unlocked the pane and deleted all printers I had.
3) I pushed the Add button
4) The network printer was found and added into Printers automatically with the note that drivers could not be found.
5) I could click on Printer details and got three buttons with approximately these texts: Search for drivers, Select driver from database, Provide PPD file.
6) Searching for drivers worked but none was found (the one selected automatically was "Generic-text only printer"
7) Select from database still did not work and somewhat hanged.
8) Provide PPD was successful.

I am attaching two videos for you to see.

Created attachment 1718115 [details]
Dealing with Printer dialogue 1

Created attachment 1718116 [details]
Dealing with Printer dialogue 2

(In reply to Lukas Ruzicka from comment #25)
> I was trying again with the latest updates and the situation is still the
> same for me. 

[Snip]

There hasn't been a new build of gnome-control-center since Sept. 19, before a fix was pushed to either the master or 3.38 branches.

Thanks for fixing this, Brandon!

I can see that the revert is in 3-38 branch upstream and we should get a 3.38.1 release in a few days. I'll link this ticket once we have a build in Bodhi.

FEDORA-2020-93095cb647 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-93095cb647

(In reply to Fedora Update System from comment #30)
> FEDORA-2020-93095cb647 has been submitted as an update to Fedora 33.
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-93095cb647

I no longer see the issue with this update. The "Select Printer Driver" PPD selection dialog is functional.

FEDORA-2020-93095cb647 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-93095cb647`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-93095cb647

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Lukas, can you please verify as well?

FEDORA-2020-93095cb647 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Bug fixed, commonbugs not needed.