Created attachment 1024556 [details] terminal output while running yumex-dnf Description of problem:yumex-dnf is locking up when run from MATE Control Center. It gets stuck while refreshing package metadata. The subject line may not be the issue but that is the point it is freezing at as you will see from the attached terminal output Version-Release number of selected component (if applicable):yumex-dnf-4.1.2-1.fc22 How reproducible:Consistently Steps to Reproduce: 1. Start MATE 2. Open Control Center 3. Run yumex-dnf Actual results: Process freezes shortly after rendering GUI Expected results: Refresh package metadata from servers and load a list of updates if any available Additional info:Nothing is showing in the dnf.log when yumex-dnf is executed. I have tried adding ip_resolve=4 to the dnf.conf file in case it was a DNS issue. It made no difference. traditional yumex is responding as normal and working fine on the same system and there are no issues in the browser either with DNS or server pings.
Could you try running yumex-dnf -d and attach the output
This message is not a issue, I comes when Gtk is importing the UI from a builder xml file. Gtk-CRITICAL **: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
Created attachment 1024979 [details] yumex-dnf -d output as requested Hi Tim, as requested please find the attached. I've just let the program run this morning while I've got on with other stuff. As you will see the program did not freeze as I thought it had. It is just taking an exceedingly long time to process the repo and meta data. Either way, to the average user it appears to be frozen due to the apparent lack of activity. Thanks for the information about the GTK+ error.
Looks very strange 07:30:56: Lock the DNF root daemon 07:30:56: Refresh system cache 08:01:23: on_RepoMetaDataProgress (root): ('Fedora 22 - x86_64 - Test Updates', 0.0) 08:31:35: on_RepoMetaDataProgress (root): ('Fedora 22 - x86_64 - Test Updates', 0.011401439288502666) 30 min for requesting refresh of dnf cache to repo meta data starts downloading 30 min from metadata download starts til the first data starts to download. There must be something wrong with the networks connection, normally it only takes a coulple seconds to repo metadata download starts and the user see the progress in the dialog.
On my system (F21), with a no cache (dnf clean all, before running yumex-dnf) 13:49:00: Lock the DNF root daemon 13:49:02: on_RepoMetaDataProgress (root): ('RPM Fusion for Fedora 21 - Free', 0.0) 13:49:03: on_RepoMetaDataProgress (root): ('RPM Fusion for Fedora 21 - Free', 0.01950218500863144)
As much as I could I already checked the network configuration to try and rule that out before opening this ticket. I really wish it was that simple. The old non-dnf yumex in F22 MATE on the same system responds and performs normally. there are no 30 minute delays. do you want me to run a verbose output on yumex for comparison? I've tried yumex-dnf with IPv6 enabled and disabled in dnf.conf and Network Manager. Also DNS server settings (google - 8.8.8.8 and OpenDNS 208.67.222.222) are checking out okay. There are no delays or issues looking up sites or downloading data in Firefox. even wget from the command line can access the fedora, updates and updates-testing servers okay if I try downloading an rpm just to test the connection to servers. I will do dnf clean all and run it again this evening but I would expect the same results.
try to run dnf clean all dnf makecache to see if also takes very long time to complete
If you can reproduce the issue, then try to run sudo LIBREPO_DEBUG=1 /usr/share/dnfdaemon/dnfdaemon-system -d -v --notimeout in one terminal window and run yumex-dnf -d in another windows and attach the output from both. this can be related to bug 1219283
Created attachment 1025126 [details] sudo LIBREPO_DEBUG=1 /usr/share/dnfdaemon/dnfdaemon-system -d -v --notimeout Okay, so dnf clean all followed by dnf makecache caused the same behaviour. I've run the commands you posted in your last post and the process seems to have completed as it should this time. yumex-dnf -d output to follow
Created attachment 1025127 [details] yumex-dnf -d output as requested - 18:00 GMT To go with https://bugzilla.redhat.com/attachment.cgi?id=1025126
*** This bug has been marked as a duplicate of bug 1219283 ***