Bug 1332067

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

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.

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

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.

Hi Hawkey devs.

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

*** Bug 1332244 has been marked as a duplicate of this bug. ***

arbt infomation is located in 1332067

Ups, wrong bug num.

abrt info is in 

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

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?

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.

btw. the error message is very misleading.

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?

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.

Created attachment 1155625 [details]
script to reproduce

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.

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

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.

Thanks very much.

Your temporary fix works here, thanks very much

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.

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

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

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.

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)

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

$ 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()

(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

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?

I don't see how it's related.

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.

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?

(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.

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!!!!!

[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.

Thanks that you will take a care of the bug

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

hawkey-0.6.3-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-175432a09e

hawkey-0.6.3-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-355b0013d5

hawkey-0.6.3-6.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-355b0013d5

hawkey-0.6.3-6.fc25 has been pushed to the Fedora 25 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-175432a09e

hawkey-0.6.3-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

hawkey-0.6.3-6.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.