Bug 1280181 - yumex-dnf don't launch with F24 rawhide
yumex-dnf don't launch with F24 rawhide
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnfdaemon (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tim Lauridsen
Fedora Extras Quality Assurance
:
: 1278892 (view as bug list)
Depends On: 1285991
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-11 01:16 EST by dominique
Modified: 2017-02-18 08:01 EST (History)
5 users (show)

See Also:
Fixed In Version: 0.3.12 dnfdaemon-0.3.15-1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-16 12:22:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The results of trying to install from yumex-dnf (951 bytes, text/plain)
2016-05-23 19:28 EDT, Lawrenc Graves
no flags Details

  None (edit)
Description dominique 2015-11-11 01:16:37 EST
Description of problem:

When I launch yumex-dnf in F24 rawhide I have this error message, and after yumex-dnf quit : 

[dominique@host-192-168-1-2 ~]$ /usr/bin/yumex-dnf
/usr/lib/python3.4/site-packages/yumex/__init__.py:22: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk
 
07:07:42: statusicon wrong api version 1 != 0
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[dominique@host-192-168-1-2 ~]$
Comment 1 Tim Lauridsen 2015-11-18 06:05:24 EST
Don't have a rawhide system, look like a problem with starting the statusicon dbus service, I will look into this.
Comment 2 Tim Lauridsen 2015-11-18 06:08:50 EST
could you run:

/usr/share/yumex-dnf/dbus_status.py

and post the output here.
Comment 3 dominique 2015-11-18 09:12:03 EST
Output of /usr/share/yumex-dnf/dbus_status.py

[dominique@host-192-168-1-2 ~]$ /usr/share/yumex-dnf/dbus_status.py
sys:1: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
sys:1: PyGIWarning: Notify was imported without specifying a version first. Use gi.require_version('Notify', '0.7') before import to ensure that the right version gets loaded.
/usr/share/yumex-dnf/dbus_status.py:167: PyGIDeprecationWarning: GObject.SIGNAL_RUN_FIRST is deprecated; use GObject.SignalFlags.RUN_FIRST instead
  'notify-action': (GObject.SIGNAL_RUN_FIRST, None,
Exception   : org.freedesktop.DBus.Error.Spawn.ChildExited
   message  : Launch helper exited with unknown return code 1 (25)
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 212, in _get_daemon
    proxy = bus.get(org, "/", interface)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 169, in get
    self.conn, 0, None, bus, obj, iface, None
GLib.Error: g-dbus-error-quark: Erreur lors de l'appel de StartServiceByName pour org.baseurl.DnfSystem : GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/yumex-dnf/dbus_status.py", line 373, in __init__
    self.backend = dnfdaemon.client.Client()
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 541, in __init__
    DnfDaemonBase.__init__(self, system, ORG, INTERFACE)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 205, in __init__
    self.daemon = self._get_daemon(bus, org, interface)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 223, in _get_daemon
    self._handle_dbus_error(err)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py", line 250, in _handle_dbus_error
    raise DaemonError(str(err))
dnfdaemon.client.DaemonError: g-dbus-error-quark: Erreur lors de l'appel de StartServiceByName pour org.baseurl.DnfSystem : GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1 (25)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/yumex-dnf/dbus_status.py", line 728, in <module>
    main()
  File "/usr/share/yumex-dnf/dbus_status.py", line 723, in main
    YumexStatusDaemon()
  File "/usr/share/yumex-dnf/dbus_status.py", line 377, in __init__
    error_notify('Error starting dnfdaemon service\n\n%s' % msg, msg)
  File "/usr/share/yumex-dnf/dbus_status.py", line 197, in error_notify
    notification.show()
GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files (2)
[dominique@host-192-168-1-2 ~]$
Comment 4 Tim Lauridsen 2015-11-18 12:31:31 EST
try if this can start

sudo /usr/share/dnfdaemon/dnfdaemon-system -v -d --notimeout
Comment 5 dominique 2015-11-18 13:01:01 EST
with the command I have that : 

su -c "/usr/share/dnfdaemon/dnfdaemon-system -v -d --notimeout"
Mot de passe : 
18:57:47: Starting org.baseurl.DnfSystem: API Version : 2

but nothing appear.

When I stop with ctrl+c I have that : 

^CTraceback (most recent call last):
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 765, in <module>
    main()
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 761, in main
    yd.mainloop_run()
  File "/usr/lib/python3.5/site-packages/dnfdaemon/server/__init__.py", line 1102, in mainloop_run
    MAINLOOP.run()
  File "/usr/lib64/python3.5/site-packages/gi/overrides/GLib.py", line 575, in run
    raise KeyboardInterrupt
KeyboardInterrupt
Comment 6 Tim Lauridsen 2015-11-25 08:50:46 EST
Try run this command

/usr/bin/dbus-send --system --print-reply --dest="org.baseurl.DnfSystem" / org.baseurl.DnfSystem.GetVersion

It should start the org.baseurl.DnfSystem DBus service and return the daemon API version.

Expected output:

method return time=1448459211.265059 sender=:1.947 -> destination=:1.946 serial=3 reply_serial=2
   int32 2
Comment 7 dominique 2015-11-25 09:17:06 EST
Output for your command : 

[dominique@host-192-168-1-2 ~]$ /usr/bin/dbus-send --system --print-reply --dest="org.baseurl.DnfSystem" / org.baseurl.DnfSystem.GetVersion
Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
[dominique@host-192-168-1-2 ~]$
Comment 8 Tim Lauridsen 2015-11-26 13:36:07 EST
Look like something is messed up in rawhide.

The dnfdaemon-service will not load when started as a DBus service, but works fine when you launch it directly (Comment 4), so it is not a bug in the daemon code.

could you please run journalctl -f in one terminal and run 

/usr/bin/dbus-send --system --print-reply --dest="org.baseurl.DnfSystem" / org.baseurl.DnfSystem.GetVersion

in another to see if it show some kind of error in the system log
Comment 9 dominique 2015-11-26 13:49:11 EST
With your command nothing appear in journalctl

[dominique@host-192-168-1-2 ~]$ /usr/bin/dbus-send --system --print-reply --dest="org.baseurl.DnfSystem" / org.baseurl.DnfSystem.GetVersion
Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
[dominique@host-192-168-1-2 ~]$ 

But if I launch yumex-dnf I have this in journalctl : 

nov. 26 19:48:16 host-192-168-1-2 dbus-daemon[963]: Activating service name='dk.yumex.StatusIcon'
nov. 26 19:48:16 host-192-168-1-2 dbus-daemon[963]: Successfully activated service 'dk.yumex.StatusIcon'
nov. 26 19:48:16 host-192-168-1-2 dk.yumex.StatusIcon[963]: /usr/share/yumex-dnf/dbus_status.py:170: PyGIDeprecationWarning: GObject.SIGNAL_RUN_FIRST is deprecated; use GObject.SignalFlags.RUN_FIRST instead
nov. 26 19:48:16 host-192-168-1-2 dk.yumex.StatusIcon[963]: 'notify-action': (GObject.SIGNAL_RUN_FIRST, None,
nov. 26 19:48:16 host-192-168-1-2 dk.yumex.StatusIcon[963]: Exception   : org.freedesktop.DBus.Error.Spawn.ChildExited
nov. 26 19:48:16 host-192-168-1-2 dk.yumex.StatusIcon[963]: message  : Launch helper exited with unknown return code 1 (25)
Comment 10 dominique 2015-11-26 13:53:35 EST
And if I launch journalctl -f as root I have that : 

ov. 26 19:51:38 host-192-168-1-2 dbus-daemon[963]: Activating service name='dk.yumex.StatusIcon'
nov. 26 19:51:38 host-192-168-1-2 dbus-daemon[963]: Successfully activated service 'dk.yumex.StatusIcon'
nov. 26 19:51:38 host-192-168-1-2 dbus[702]: [system] Activating service name='org.baseurl.DnfSystem' (using servicehelper)
nov. 26 19:51:38 host-192-168-1-2 org.baseurl.DnfSystem[702]: error: libgirepository.so (gobject-introspection) is not audited for use in setuid applications
nov. 26 19:51:38 host-192-168-1-2 org.baseurl.DnfSystem[702]: See https://bugzilla.gnome.org/show_bug.cgi?id=755472
nov. 26 19:51:38 host-192-168-1-2 dbus[702]: [system] Activated service 'org.baseurl.DnfSystem' failed: Launch helper exited with unknown return code 1
nov. 26 19:51:38 host-192-168-1-2 dk.yumex.StatusIcon[963]: /usr/share/yumex-dnf/dbus_status.py:170: PyGIDeprecationWarning: GObject.SIGNAL_RUN_FIRST is deprecated; use GObject.SignalFlags.RUN_FIRST instead
nov. 26 19:51:38 host-192-168-1-2 dk.yumex.StatusIcon[963]: 'notify-action': (GObject.SIGNAL_RUN_FIRST, None,
nov. 26 19:51:38 host-192-168-1-2 dk.yumex.StatusIcon[963]: Exception   : org.freedesktop.DBus.Error.Spawn.ChildExited
nov. 26 19:51:38 host-192-168-1-2 dk.yumex.StatusIcon[963]: message  : Launch helper exited with unknown return code 1 (25)
nov. 26 19:51:41 host-192-168-1-2 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Comment 11 Tim Lauridsen 2015-11-27 02:13:40 EST
Interesting

This look to be the problem

nov. 26 19:51:38 host-192-168-1-2 dbus[702]: [system] Activating service name='org.baseurl.DnfSystem' (using servicehelper)
nov. 26 19:51:38 host-192-168-1-2 org.baseurl.DnfSystem[702]: error: libgirepository.so (gobject-introspection) is not audited for use in setuid applications
nov. 26 19:51:38 host-192-168-1-2 org.baseurl.DnfSystem[702]: See https://bugzilla.gnome.org/show_bug.cgi?id=755472
Comment 12 Tim Lauridsen 2015-11-27 02:33:49 EST
I have created a report against gobject-introspection

https://bugzilla.redhat.com/show_bug.cgi?id=1285991

for this problem.
Comment 13 Tim Lauridsen 2015-11-28 10:46:14 EST
I have made a new build, It should work around the issues

http://koji.fedoraproject.org/koji/buildinfo?buildID=702072

It should hit rawhide in next push
Comment 14 Tim Lauridsen 2015-11-28 10:46:59 EST
*** Bug 1278892 has been marked as a duplicate of this bug. ***
Comment 15 dominique 2015-11-28 12:05:10 EST
Ok Tim, I install your new release, but that don't work.
I have this error message when I launch yumex-dnf with console : 

dominique@host-192-168-1-2 ~]$ yumex-dnf
/usr/lib/python3.5/site-packages/yumex/__init__.py:69: Warning: invalid cast from 'GtkBox' to 'GtkWindow'
  self.ui.add_from_file(const.DATA_DIR + '/yumex.ui')

(yumex-dnf:4680): Gtk-CRITICAL **: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed

(yumex-dnf:4680): Gtk-WARNING **: State 0 for YumexPackageView 0x55e517476bb0 doesn't match state 128 set via gtk_style_context_set_state ()
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/yumex/__init__.py", line 1329, in do_command_line
    self.do_activate()
  File "/usr/lib/python3.5/site-packages/yumex/__init__.py", line 1232, in do_activate
    self.win = YumexWindow(self, self.status)
  File "/usr/lib/python3.5/site-packages/yumex/__init__.py", line 401, in __init__
    CONFIG.conf.color_normal = color_to_hex(color_normal)
  File "/usr/lib/python3.5/site-packages/yumex/misc.py", line 118, in color_to_hex
    return rgb_to_hex(color.red, color.green, color.blue)
  File "/usr/lib/python3.5/site-packages/yumex/misc.py", line 114, in rgb_to_hex
    return "#%02X%02X%02X" % (r, g, b)
TypeError: %X format: an integer is required, not float
^C
[dominique@host-192-168-1-2 ~]$
Comment 16 Tim Lauridsen 2015-11-29 06:45:11 EST
That is another issuse fixed upstream

https://github.com/timlau/yumex-dnf/issues/81

You can test using a git checkout :

git clone https://github.com/timlau/yumex-dnf.git
cd yumex-dnf
git checkout rel_41X
cd src
./main.py
Comment 17 Tim Lauridsen 2015-11-29 06:46:31 EST
I will push a new yumex-dnf release very soon
Comment 18 dominique 2015-11-29 07:45:43 EST
Ok Tim, I build my own rpm with your git source and that work for me.

Thank
Comment 19 dominique 2015-11-30 11:42:00 EST
Sorry Tim, I don't test with an update, but today there are update.

And there is a problem. Normally after choose package to update there is a window asked for root password.

With your release that don't work, I have a window with :

Root backend was not authorized and can't continue

If I launch yumex-dnf as root in console that work.
Comment 20 Tim Lauridsen 2015-12-02 12:20:50 EST
Looks like a different issue.

please run journalctl -f (as root) an see what error you get.
Comment 21 dominique 2015-12-02 13:05:43 EST
I have this output : 
.......................................................
déc. 02 19:00:18 host-192-168-1-2 dbus-daemon[961]: Activating service name='dk.yumex.StatusIcon'
déc. 02 19:00:18 host-192-168-1-2 dbus-daemon[961]: Successfully activated service 'dk.yumex.StatusIcon'
déc. 02 19:00:18 host-192-168-1-2 dbus[721]: [system] Activating via systemd: service name='org.baseurl.DnfSystem' unit='dnfdaemon.service'
déc. 02 19:00:18 host-192-168-1-2 systemd[1]: Starting Package management dnf daemon...
déc. 02 19:00:18 host-192-168-1-2 dbus[721]: [system] Successfully activated service 'org.baseurl.DnfSystem'
déc. 02 19:00:18 host-192-168-1-2 systemd[1]: Started Package management dnf daemon.
déc. 02 19:00:18 host-192-168-1-2 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnfdaemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
déc. 02 19:01:01 host-192-168-1-2 CROND[12008]: (root) CMD (run-parts /etc/cron.hourly)
déc. 02 19:01:01 host-192-168-1-2 run-parts[12011]: (/etc/cron.hourly) starting 0anacron
déc. 02 19:01:01 host-192-168-1-2 run-parts[12017]: (/etc/cron.hourly) finished 0anacron
déc. 02 19:01:01 host-192-168-1-2 run-parts[12019]: (/etc/cron.hourly) starting mcelog.cron
déc. 02 19:01:01 host-192-168-1-2 run-parts[12023]: (/etc/cron.hourly) finished mcelog.cron
déc. 02 19:01:06 host-192-168-1-2 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnfdaemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
^C
[root@host-192-168-1-2 ~]#
Comment 22 Tim Lauridsen 2015-12-04 07:16:56 EST
looks like the service start ok, but there is some problem with polkit autherization, but can see any polkit output from your log.

Try.

journalctl  | grep org.baseurl.DnfSystem

I get output like this 

Dec 04 13:07:56 localhost.localdomain dbus[796]: [system] Successfully activated service 'org.baseurl.DnfSystem'
Dec 04 13:08:15 localhost.localdomain dbus[796]: [system] Activating service name='org.baseurl.DnfSystem' (using servicehelper)
Dec 04 13:08:16 localhost.localdomain dbus[796]: [system] Successfully activated service 'org.baseurl.DnfSystem'
Dec 04 13:08:46 localhost.localdomain polkitd[839]: Operator of unix-session:1 successfully authenticated as unix-user:tim to gain TEMPORARY authorization for action org.baseurl.DnfSystem.write for system-bus-name::1.1569 [/usr/bin/python3 /usr/bin/yumex-dnf] (owned by unix-user:tim)
Comment 23 dominique 2015-12-04 08:16:20 EST
Output for journalctl  | grep org.baseurl.DnfSystem

déc. 04 14:10:27 host-192-168-1-2 dbus[670]: [system] Activating via systemd: service name='org.baseurl.DnfSystem' unit='dnfdaemon.service'
déc. 04 14:10:28 host-192-168-1-2 dbus[670]: [system] Successfully activated service 'org.baseurl.DnfSystem'

ant that all.
Comment 24 Tim Lauridsen 2015-12-04 09:51:24 EST
Does polkit for for other apps, like the gnome Users app (select the unlock button)
Comment 25 dominique 2015-12-04 10:07:53 EST
I don't use gnome, but with kde I don't able to create a new user, for example, normally system ask me for root password (in F23), but with F24 rawhide I have no window ask me for root password, I have just a window with "Permission denied".

Also I think it's a problem with polkit, and not with yumex-dnf.
Comment 26 Tim Lauridsen 2015-12-05 07:16:28 EST
Yes, It looks like polkit is broken in you setup currently.

You can run try yumex-dnf as root and it should work
Comment 27 dominique 2015-12-05 14:24:40 EST
Ok Tim, I launch yumex-dnf as and that work.

Just one thing, I don't know if it's important for you, but when I launch yumex-dnf (as root or user), I have this warning : 

[root@host-192-168-1-2 ~]# yumex-dnf
/usr/lib/python3.5/site-packages/yumex/__init__.py:69: Warning: invalid cast from 'GtkBox' to 'GtkWindow'
  self.ui.add_from_file(const.DATA_DIR + '/yumex.ui')

(yumex-dnf:25773): Gtk-CRITICAL **: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
/usr/lib/python3.5/site-packages/dnfdaemon/client/__init__.py:291: PyGIDeprecationWarning: GObject.G_MAXINT is deprecated; use GLib.MAXINT instead
  user_data=data, timeout=GObject.G_MAXINT)

Yumex-dnf work, but may-be that help you for the future.
Comment 28 Tim Lauridsen 2015-12-07 04:11:16 EST
Every new version of gtk/pygi add some new deprecation warnings.

I will fix the ones with MAXINT.

It think the other ones is fixed in the current development version
https://copr.fedoraproject.org/coprs/timlau/yumex-dnf/

You should check them out, there has been a lot of improvments in the UI

https://github.com/timlau/yumex-dnf/issues/74
Comment 29 Tim Lauridsen 2015-12-11 03:56:24 EST
"GObject.G_MAXINT is deprecated; use GLib.MAXINT instead" fixed upstream

https://github.com/timlau/dnf-daemon/commit/19d524da7a62319a8c3a3346b1178c6b16daa5bb
Comment 30 dominique 2015-12-11 05:30:48 EST
Hello Tim
I test yumex-dnf 4.3.1-1 on my F23, and that work.
But I don't know if it's a new feature, when I launch yumex-dnf the gui appear after dnf update the cache (or other thing).
For me it's not a problem, I can see that work in my monitor, but other users can think that yumex-dnf don't work.

It's just for info.
Comment 31 Tim Lauridsen 2015-12-14 05:18:32 EST
I am aware of this issue, will be fixed in next devel release
Comment 32 Jan Kurik 2016-02-24 08:56:33 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 33 Fedora Update System 2016-05-11 05:02:20 EDT
dnfdaemon-0.3.15-1.fc24 yumex-dnf-4.3.3-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-aa868f02e4
Comment 34 Fedora Update System 2016-05-12 05:41:26 EDT
dnfdaemon-0.3.15-1.fc24, yumex-dnf-4.3.3-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-aa868f02e4
Comment 35 Fedora Update System 2016-05-16 12:22:18 EDT
dnfdaemon-0.3.15-1.fc24, yumex-dnf-4.3.3-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
Comment 36 Lawrenc Graves 2016-05-23 19:28 EDT
Created attachment 1160832 [details]
The results of trying to install from yumex-dnf

g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/dbus/service.py", line 707, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 83, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 537, in RunTransaction
    result = self.run_transaction()
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 550, in run_transaction
    self._check_gpg_signatures(to_dnl)
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 699, in _check_gpg_signatures
    result, errmsg = self.base.sigCheckPkg(po)
  File "/usr/lib/python3.4/site-packages/dnf/util.py", line 79, in __getattr__
    % (C.__name__, name))
AttributeError: 'Base' object has no attribute 'sigCheckPkg'
 (36)
Comment 37 Alec 2016-05-26 12:44:27 EDT
(In reply to Lawrenc Graves from comment #36)
> ...
> AttributeError: 'Base' object has no attribute 'sigCheckPkg'

I have suddenly started getting this same error as Lawrence posted above.

Luckily command-line DNF update is still working - it only seems to be yumex-dnf with the problem.  

(I still consider myself a Linux noob, but happy to learn)
Comment 38 Tim Lauridsen 2016-05-27 02:13:48 EDT
Dont update on an already closed bug report.

The one you are looking for is 

https://bugzilla.redhat.com/show_bug.cgi?id=1338564
Comment 39 Donald O. 2017-02-18 07:40:06 EST
I can confirm this bug for Fedora 25 too, at least after this weeks updates(kernel 4.9.9), and I suppose it occurs only a couple of hours after a systemctl suspend returned.

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