Bug 2060414 - On Fedora 36 KDE, dnfdragora does not start.
Summary: On Fedora 36 KDE, dnfdragora does not start.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnfdragora
Version: 36
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Depends On:
Blocks: F36BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2022-03-03 13:48 UTC by Lukas Ruzicka
Modified: 2023-01-15 18:53 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-10 07:18:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
The error message from dnfdragora (109.76 KB, image/png)
2022-03-03 13:48 UTC, Lukas Ruzicka
no flags Details

Description Lukas Ruzicka 2022-03-03 13:48:13 UTC
Created attachment 1863995 [details]
The error message from dnfdragora

Description of problem:

dnfdragora does not start on Fedora 36 KDE and reports an error. The error suggests that the dnfdragora.yaml file could not be found. This behaviour was seen on fresh installations where the file could not have been created by dnfdragora as it is started for the first time. One would expect that if a configuration file is missing a new configuration file gets created with some default configuration and that the application starts normally.

Version-Release number of selected component (if applicable):
dnfdragora: 2.1.2-1

How reproducible:
Always

Steps to Reproduce:
1. Try to start dnfdragora.

Actual results:

Dnfdragora does not start due to missing config file

Expected results:

Dnfdragora should create a new config file if it does not find any and start normally.

Additional info (the error message):

See the screenshot for the error message

Comment 1 Adam Williamson 2022-03-03 18:27:25 UTC
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> >

Comment 2 Adam Williamson 2022-03-03 18:31:35 UTC
There was a big update in libyui recently, from 3.10.0 to 4.2.16. I'm betting that may be the issue.

Comment 3 Adam Williamson 2022-03-03 18:51:32 UTC
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...

Comment 4 Adam Williamson 2022-03-03 18:55:08 UTC
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.

Comment 5 Angelo Naselli 2022-03-03 22:24:56 UTC
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

Comment 6 Adam Williamson 2022-03-03 23:57:21 UTC
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.

Comment 7 Adam Williamson 2022-03-04 00:09:42 UTC
Oh I see, libyui-bindings is part of libyui now, hence why there's a bootstrap issue.

Comment 8 Angelo Naselli 2022-03-04 21:51:04 UTC
yes, in mageia we left mga out of libyui and that's why we built libyui for bootstrap first

Comment 9 Angelo Naselli 2022-03-04 21:52:29 UTC
FWIW I started patching cmake files to build all into libyui tree, but i'm not sure all is upstream now.

Comment 10 Geoffrey Marr 2022-03-07 22:00:37 UTC
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

Comment 11 Angelo Naselli 2022-03-07 22:41:20 UTC
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

Comment 12 Adam Williamson 2022-03-08 18:39:51 UTC
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?

Comment 13 Onuralp SEZER 2022-03-08 18:45:48 UTC
(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.

Comment 14 Adam Williamson 2022-03-08 21:30:17 UTC
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.

Comment 15 Fedora Update System 2022-03-08 22:41:25 UTC
FEDORA-2022-dc056b5797 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-dc056b5797

Comment 16 Fedora Update System 2022-03-09 15:46:02 UTC
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.

Comment 17 Fedora Update System 2022-03-10 07:18:36 UTC
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.

Comment 18 Fedora Update System 2023-01-14 21:06:19 UTC
FEDORA-2023-97ba727bf1 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-97ba727bf1

Comment 19 Fedora Update System 2023-01-14 21:11:22 UTC
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.

Comment 20 Fedora Update System 2023-01-15 18:49:41 UTC
FEDORA-2023-b67bbbd94f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b67bbbd94f

Comment 21 Fedora Update System 2023-01-15 18:53:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.