I don't think that's actually the problem - it skips those exceptions, as you can see. The problem is the YUI stuff later on.

openQA catches a Python backtrace via abrt when this test fails, which I think provides more info on the problem. It looks like this:

dialogs.py:1286:warningMsgBox:AttributeError: module 'yui' has no attribute 'YMGAWidgetFactory'

Traceback (most recent call last):
  File "/usr/bin/dnfdragora", line 83, in <module>
    main_gui = ui.mainGui(options)
  File "/usr/lib/python3.10/site-packages/dnfdragora/ui.py", line 268, in __init__
    self._setupUI()
  File "/usr/lib/python3.10/site-packages/dnfdragora/ui.py", line 396, in _setupUI
    self.mgaFactory = yui.YMGAWidgetFactory.getYMGAWidgetFactory(mgaFact)
AttributeError: module 'yui' has no attribute 'YMGAWidgetFactory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/dnfdragora", line 95, in <module>
    dialogs.warningMsgBox({'title' : _("Sorry"), "text": _("dnfdaemon attribute error occurred:%(NL)s%(error)s")%{'NL': "\n",'error' : str(e)}})
  File "/usr/lib/python3.10/site-packages/dnfdragora/dialogs.py", line 1286, in warningMsgBox
    factory = yui.YMGAWidgetFactory.getYMGAWidgetFactory(factory)
AttributeError: module 'yui' has no attribute 'YMGAWidgetFactory'

Local variables in innermost frame:
info: {'title': 'Sorry', 'text': "dnfdaemon attribute error occurred:\nmodule 'yui' has no attribute 'YMGAWidgetFactory'"}
retVal: 0
factory: <yui.YExternalWidgetFactory; proxy of <Swig Object of type 'YExternalWidgetFactory *' at 0x7f8a0bfcad60> >

There was a big update in libyui recently, from 3.10.0 to 4.2.16. I'm betting that may be the issue.

well, it looks more complicated, actually. There's a bunch of different packages around yui. YMGA stuff seems to be from the libyui-mga extension to the base libyui, but I don't know what should be providing the Python bindings for that, and what may have caused the one we're trying to use here to apparently disappear...

Proposing as a Beta blocker, as a violation of "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager). This includes downloading of packages to be installed/updated." The 'default' tool for KDE is sort of a tricky question; it seems both Discover and dnfdragora are included intentionally because dnfdragora handles some things Discover cannot handle - "Discover can't handle packages without appdata. dnfdragora can.". So I think it might be reasonable to consider this condition as requiring both of them to work.

dialogs.py:1286:warningMsgBox:AttributeError: module 'yui' has no attribute 'YMGAWidgetFactory'
seems to say that libyui-bindings has not been built against libyui-mga also.

once fixed that you should update to last dnfdragora and manafirewall

I don't think it's that simple? This is the last libyui-bindings build:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1909149

it does seem to have been built against libyui-mga. You can see -DWITH_MGA a lot in the build logs and the perl subpackage provides all of "perl(yui::YMGAAboutDialog) perl(yui::YMGAMenuBar) perl(yui::YMGAMenuItem) perl(yui::YMGAMessageBox) perl(yui::YMGAWidgetFactory) perl(yui::YMGA_CBTable)".

However, it looks like libyui-bindings hasn't been built since the version bumps of libyui and libyui-mga last month, so maybe that's what is needed? I'll try it.

Oh I see, libyui-bindings is part of libyui now, hence why there's a bootstrap issue.

yes, in mageia we left mga out of libyui and that's why we built libyui for bootstrap first

FWIW I started patching cmake files to build all into libyui tree, but i'm not sure all is upstream now.

Discussed during the 2022-03-07 blocker review meeting: [0]

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

"The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager)".

Note, the criteria did not anticipate a desktop shipping two package managers, but a majority decided that in this case, one of them not working violates the above listed Beta criterion.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-07/f36-blocker-review.2022-03-07-17.01.txt

Could you try following the way in which mageia build it? 
I could try to help here, but since i have very little spare time, try to reach me via mail and meet me into #manatools irc channel in the evening to find a common and rapid solution

Onuralp said on IRC he'd made substantial progress, but was running into a Python crash later. I could almost certainly help with that, but he has not sent his work-in-progress anywhere I can find, so I can't work on it. Onuralp, could you at least link to the changes you've made to get to where you were when we last talked about this?

(In reply to Angelo Naselli from comment #11)
> Could you try following the way in which mageia build it? 
> I could try to help here, but since i have very little spare time, try to
> reach me via mail and meet me into #manatools irc channel in the evening to
> find a common and rapid solution

I directly enable "mga" build on mageia way and that give me "UI" and opened dnfdragora, I'm going to send that into our RPM right now, I'll so send one more rebuild after libyui complete because "mga-gtk" require build because of the ABI change, that will fix that one too. 

@adamw, I'm pushing my changes into repos and send build right now to repo so we can move on and so you can also see same error, I have which was a "service error" I'm getting into it. "I also checked that no abrt trigger, It just "dnfdaemon" start then dnfdragora showing me the error and then service stop and dnfdragora ui close as well.

OK, so we have this all figured out now. We need to rebuild all the libyui libs as Onuralp listed above, and also update python-manatools to 0.0.4. That's all done in Rawhide and we have tested that it's working, Onuralp is doing builds for F36 now.

FEDORA-2022-dc056b5797 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-dc056b5797

FEDORA-2022-dc056b5797 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-dc056b5797`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-dc056b5797

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

FEDORA-2022-dc056b5797 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-97ba727bf1 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-97ba727bf1

FEDORA-2023-97ba727bf1 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-b67bbbd94f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b67bbbd94f

FEDORA-2023-b67bbbd94f has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.