Bug 1371994

+++ This bug was initially created as a clone of Bug #1332067 +++

Description of problem: Yumex-DNF Exits with error: "DNF Dbus backend is not repsonding"


Version-Release number of selected component (if applicable): yumex-dnf 4.1.6


How reproducible: Launch Yum Extender DNF from Gnome Shell


Steps to Reproduce:
1.
2.
3.

Actual results: The window opens up and displays: Refreshing Repository Metadata, Then stops with the DNF Dbus beackend not responding message. 


Expected results: No error message and program continues.


I think DNF and RPM updated last week but I can't downgrade to previous version to see if those package updates are related to the problem.

--- Additional comment from Colin J Thomson on 2016-05-05 18:20:25 EDT ---

Also seeing this on F24 using yumex-dnf from copr timlau/ 
Doubt it will help but here is a snip of the output when run from a shell:

EXCEPTION : g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying (4) 

(yumex-dnf:3301): Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed

--- Additional comment from Wolfgang Ulbrich on 2016-05-07 15:25:12 EDT ---

Any chance to fix that now after beta freeze is finally over.
Several spins use yumex-dnf and i really don't want include packagekit as working alternative.

--- Additional comment from eddy02 on 2016-05-08 08:48:00 EDT ---

Seems to be because of hawkey-6.0.3  changes.

Output of dnfdaemon :

python3: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:568: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.
Aborted

--- Additional comment from Tim Lauridsen on 2016-05-09 03:36:29 EDT ---

Think this is a problem in hawkey, dont think I can fix that in dnf-daemon
as far as I can find there is no documented API change, I dont use hawkey directly, look like this is triggered indirectly by using the DNF API.

--- Additional comment from Tim Lauridsen on 2016-05-09 03:37:52 EDT ---

Hi Hawkey devs.

Do you have any idea, what is changes in hawkey 6.0.3 there is triggering this issue.

--- Additional comment from Tim Lauridsen on 2016-05-09 03:42:22 EDT ---



--- Additional comment from Tim Lauridsen on 2016-05-09 03:43:17 EDT ---

arbt infomation is located in 1332067

--- Additional comment from Tim Lauridsen on 2016-05-09 03:44:39 EDT ---

Ups, wrong bug num.

abrt info is in 

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

--- Additional comment from Jan Silhan on 2016-05-09 07:37:07 EDT ---

Do you see in `/var/cache/dnf/rpmfusion-free-updates-testing*` primary.xml? Can you please disable rpmfusion-free-updates-testing repo and try it again and report if it works, please?

--- Additional comment from Wolfgang Ulbrich on 2016-05-09 08:36:26 EDT ---

In my case rpmfusion repo config is linked to f23 + skip_if_unavailable=True.

[rpmfusion-free-updates-testing]
name=RPM Fusion for Fedora 23 - Free - Test Updates
#baseurl=http://download1.rpmfusion.org/free/fedora/updates/testing/23/$basearch/
mirrorlist=http://mirrors.rpmfusion.org/mirrorlist?repo=free-fedora-updates-testing-23&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-$releasever
skip_if_unavailable=True

...but after a 'dnf clean metadata' yumex-dnf is working again.

Normal i use yum-deprecated or good old yumex, so it is possible that i never cleaned dnf metadata since several months, and the cache was created with older hawkey versions.

--- Additional comment from Wolfgang Ulbrich on 2016-05-09 08:38:53 EDT ---

btw. the error message is very misleading.

--- Additional comment from Christian Stadelmann on 2016-05-09 11:23:49 EDT ---

I am seeing this issue too, see my duplicate (abrt reported) bug #1332244.

I can confirm that after
1. disabling rpmfusion-free-updates-testing
2. `dnf clean expire-cache`
3. start yumex-dnf and press "Refresh metadata"
this crash is gone.

After following these steps
4. enable rpmfusion-free-updates-testing
5. `dnf clean expire-cache`
6. start yumex-dnf and press "Refresh metadata"
this crash appears again.

As a workaround one could simply disable rpmfusion-free-updates-testing.

Still it is unclear: is this a bug in hawkey or is the rpmfusion-free-updates-testing repodata xml file broken?

--- Additional comment from Wolfgang Ulbrich on 2016-05-09 13:44:46 EDT ---

Well, it depends on fedora version.
For f24 you need to edit the repo file for rpmfusion, otherwise dnf can't find the repodata xml file.
See my post about.
I tested it again in f24, after deleting the dnf cache and rpmfusion-free-updates-testing is enabled, yumex-dnf have no probs to download the data agin.
I will test it later with f23.

--- Additional comment from Tim Lauridsen on 2016-05-10 04:55 EDT ---



--- Additional comment from Tim Lauridsen on 2016-05-10 04:56:53 EDT ---

Digged in a little deeper.

Looks like the issue is releated to when you reset the DNF sack and set it up
again.

See the attached python script.

--- Additional comment from Tim Lauridsen on 2016-05-10 05:03:54 EDT ---

looks like i can work around it by doing

base.read_all_repos()
base.fill_sack()
base.reset(sack=True, repos=True)
base.read_all_repos()
base.fill_sack()

but before 6.0.3, it was possible to just reset the sack without reloading the repository configuration

--- Additional comment from Tim Lauridsen on 2016-05-10 06:09:38 EDT ---

I have added the tempory workaround to dnfdaemon in copr (timlau/yumex-dnf)

So you can run

sudo dnf update dnfdaemon --refresh

To get yumex-dnf up and running again.

--- Additional comment from eddy02 on 2016-05-10 13:21:43 EDT ---

Thanks very much.

--- Additional comment from Colin J Thomson on 2016-05-10 17:29:02 EDT ---

Your temporary fix works here, thanks very much

--- Additional comment from Wolfgang Ulbrich on 2016-05-11 07:17:51 EDT ---

I ran again in this issue today and may repo files are fine.
It looks like the yumex-dnf exists also on local repos.
From my point of view (fedora spin maintainer) adding a temporary fix to corps isn't really a solution.
Why not adding yumex back for f24?
Which works great and yum itself isn't removed from f24.
I'm willing to help out as co-maintainer.
It isn't nice that Mate and Cinnamon spins shipping a broken package-manager GUI for f24.

--- Additional comment from Wolfgang Ulbrich on 2016-05-11 07:18:45 EDT ---

err......and my repo files are fine.

--- Additional comment from Fedora Admin XMLRPC Client on 2016-07-08 05:25:00 EDT ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Jaroslav Mracek on 2016-08-30 08:24:26 EDT ---

I try to test it with yumex-dnf-4.3.3-1 and python3-hawkey-0.6.3-5 on F24 and I was unable to reproduce the bug. I am closing the bug report as the issue was fixed in released version. Please if the problem again appear, don't hesitate to open the bug report.

--- Additional comment from Igor Gnatenko on 2016-08-30 08:27:35 EDT ---

In [2]: import dnf

In [3]: base = dnf.Base()

In [4]: base.read_all_repos()

In [5]: base.fill_sack()
Out[5]: <dnf.sack.Sack at 0x7fb7977efb88>

In [6]: base.read_all_repos()
Repository ignatenkobrain-homu is listed more than once in the configuration
Repository ignatenkobrain-pycryptodome is listed more than once in the configuration
Repository ignatenkobrain-taiga is listed more than once in the configuration
Repository fedora-cisco-openh264 is listed more than once in the configuration
Repository fedora-cisco-openh264-debuginfo is listed more than once in the configuration
Repository rawhide is listed more than once in the configuration
Repository rawhide-debuginfo is listed more than once in the configuration
Repository rawhide-source is listed more than once in the configuration
Repository updates-testing is listed more than once in the configuration
Repository updates-testing-debuginfo is listed more than once in the configuration
Repository updates-testing-source is listed more than once in the configuration
Repository updates is listed more than once in the configuration
Repository updates-debuginfo is listed more than once in the configuration
Repository updates-source is listed more than once in the configuration
Repository fedora is listed more than once in the configuration
Repository fedora-debuginfo is listed more than once in the configuration
Repository fedora-source is listed more than once in the configuration
Repository google-talkplugin is listed more than once in the configuration
Repository koji-rawhide is listed more than once in the configuration
Repository rpm-gitoverlay is listed more than once in the configuration
Repository rpmfusion-free-rawhide is listed more than once in the configuration
Repository rpmfusion-free-rawhide-debuginfo is listed more than once in the configuration
Repository rpmfusion-free-rawhide-source is listed more than once in the configuration
Repository rpmfusion-free-updates-testing is listed more than once in the configuration
Repository rpmfusion-free-updates-testing-debuginfo is listed more than once in the configuration
Repository rpmfusion-free-updates-testing-source is listed more than once in the configuration
Repository rpmfusion-free-updates is listed more than once in the configuration
Repository rpmfusion-free-updates-debuginfo is listed more than once in the configuration
Repository rpmfusion-free-updates-source is listed more than once in the configuration
Repository rpmfusion-free is listed more than once in the configuration
Repository rpmfusion-free-debuginfo is listed more than once in the configuration
Repository rpmfusion-free-source is listed more than once in the configuration

In [7]: base.fill_sack()
python3: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:571: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.
Aborted (core dumped)

--- Additional comment from Jaroslav Mracek on 2016-08-30 08:34:03 EDT ---

Not a bug, you cannot load twice sack!!! You have to call base.reset() with proper flag.

--- Additional comment from Igor Gnatenko on 2016-08-30 08:37:06 EDT ---

$ curl --silent https://bugzilla.redhat.com/attachment.cgi?id=1155625 | python3 -
python3: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:571: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.
Aborted (core dumped)


$ curl --silent https://bugzilla.redhat.com/attachment.cgi?id=1155625 
import dnf

base = dnf.Base()
conf = base.conf

RELEASEVER = dnf.rpm.detect_releasever(conf.installroot)
conf.substitutions['releasever'] = RELEASEVER
conf.read()  # read the dnf.conf
base.read_all_repos()
base.fill_sack()
base.reset(sack=True)
base.fill_sack()

--- Additional comment from Christian Stadelmann on 2016-08-31 03:02:33 EDT ---

(In reply to Jaroslav Mracek from comment #23)
> I try to test it with yumex-dnf-4.3.3-1 and python3-hawkey-0.6.3-5 on F24
> and I was unable to reproduce the bug. I am closing the bug report as the
> issue was fixed in released version. Please if the problem again appear,
> don't hesitate to open the bug report.

Is it possible that you just used a version after [this commit] which includes a workaround?

[this commit] https://github.com/timlau/dnf-daemon/commit/f20ce9c9566b00308af73bb3d0bfb3cc50e666ae

--- Additional comment from Jaroslav Mracek on 2016-08-31 07:43:57 EDT ---

Ok I found dad guy. It is commit ff529e3af66098e5997d86b0152419710aa1d18c that change the spec file. Igor Gnatenko, Please as a expert on spec, can you please provide a patch for your commit?

--- Additional comment from Igor Gnatenko on 2016-08-31 07:48:05 EDT ---

I don't see how it's related.

--- Additional comment from Jaroslav Mracek on 2016-08-31 08:00:57 EDT ---

Just test build it commit before and then with the commit and you will see the difference (working 2x fill_sack and not working). Please can you solve the problem as spec specialist? First version where it fails 0.6.3-1.git.1.ff529e3.fc23. The last version where it works hawkey-0.6.3-1.git.0.08f4354.fc23.x86_64.

--- Additional comment from Jaroslav Mracek on 2016-08-31 08:12:42 EDT ---

After discussion with mluscon it looks like that before your commit, assertions where included only for devel-packages, but it is not true anymore. Again, please can you provide a spec file patch for hawkey and libdnf?

--- Additional comment from Igor Gnatenko on 2016-08-31 09:10:27 EDT ---

(In reply to Jaroslav Mracek from comment #31)
> After discussion with mluscon it looks like that before your commit,
> assertions where included only for devel-packages, but it is not true
> anymore. Again, please can you provide a spec file patch for hawkey and
> libdnf?
I don't see which patch do you want.

Though I did bisect and this bug in hawkey since:
commit 1f6b41fcb318d2262583aa0cec3b586e39b9f903
Author: Jan Silhan <jsilhan>
Date:   Mon Apr 27 15:34:17 2015 +0200

    get rid of yum references

All code before is not possible to test with current DNF.

--- Additional comment from Jaroslav Mracek on 2016-08-31 09:38:26 EDT ---


Investigation:
On f23 VM. RPMs were built with tito.

Test script: 
import dnf

base = dnf.Base()
base.read_all_repos()
base.fill_sack()
print('base.fill_sack()')
base.fill_sack()
print('base.fill_sack()')
base.close()

Test1 condition:
dnf-1.1.10-1.fc23.noarch
python3-hawkey-0.6.3-1.git.0.08f4354.fc23.x86_64
hawkey-0.6.3-1.git.0.08f4354.fc23.x86_64
rpm-4.13.0-0.rc1.13.fc23.x86_64
librepo-1.7.16-2.fc23.x86_64
libsolv-0.6.20-2.fc23.x86_64

Test1: Result
[hrom@localhost ~]$ python2 test.py 
base.fill_sack()
base.fill_sack()

[hrom@localhost ~]$ python3 test.py 
base.fill_sack()
base.fill_sack()

Test2 conditions:
dnf-1.1.10-1.fc23.noarch
python3-hawkey-0.6.3-1.git.1.ff529e3.fc23.x86_64
hawkey-0.6.3-1.git.1.ff529e3.fc23.x86_64
rpm-4.13.0-0.rc1.13.fc23.x86_64
librepo-1.7.16-2.fc23.x86_64
libsolv-0.6.20-2.fc23.x86_64


Test2 result:
[hrom@localhost ~]$ python2 test.py 
base.fill_sack()
python2: /tmp/tito/rpmbuild-hawkeyv95l7v6c/BUILD/hawkey-git-1.ff529e3/src/sack.c:568: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.
Aborted (core dumped)

[hrom@localhost ~]$ python3 test.py 
base.fill_sack()
python3: /tmp/tito/rpmbuild-hawkeyv95l7v6c/BUILD/hawkey-git-1.ff529e3/src/sack.c:568: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.
Aborted (core dumped)

Output from result:
The commit ff529e3af66098e5997d86b0152419710aa1d18c is responsible for the bug. Author Igor Gnatenko <ignatenko>, pushed to master by Igor Gnatenko <ignatenko>. Please can you fix it!!!!!

--- Additional comment from Igor Gnatenko on 2016-08-31 09:39:41 EDT ---

[brain@brain hawkey]$ cat test.sh 
#!/bin/bash
set -xeuo pipefail

rm -rf build
mkdir build
pushd build
  cmake .. -DPYTHON_DESIRED=3
popd
make -j8 -C build

PYTHONPATH=`pwd`/build/src/python/ python3 test.py
[brain@brain hawkey]$ cat test.py 
import dnf

base = dnf.Base()
conf = base.conf

RELEASEVER = dnf.rpm.detect_releasever(conf.installroot)
conf.substitutions['releasever'] = RELEASEVER
conf.read()  # read the dnf.conf
base.read_all_repos()
base.fill_sack()
base.reset(sack=True)
base.fill_sack()




Now you use git-bisect(1). And for each commit you run ./test.sh.

--- Additional comment from Jaroslav Mracek on 2016-08-31 09:57:03 EDT ---

Thanks that you will take a care of the bug

--- Additional comment from Igor Gnatenko on 2016-08-31 11:53:05 EDT ---

Workaround is here: https://github.com/rpm-software-management/hawkey/pull/118

But bug itself is not fixed: https://github.com/rpm-software-management/libhif/issues/186