This update made openQA happy but introduced regression https://bugzilla.redhat.com/show_bug.cgi?id=1696963
[root@70994cb94028 ~]# yum update --enablerepo=epel-testing -y Loaded plugins: fastestmirror, ovl Loading mirror speeds from cached hostfile * base: tux.rainside.sk * epel: download.eng.brq.redhat.com * epel-testing: mirror.nextlayer.at * extras: tux.rainside.sk * updates: ftp.upjs.sk Resolving Dependencies --> Running transaction check ---> Package distribution-gpg-keys.noarch 0:1.28-1.el7 will be updated ---> Package distribution-gpg-keys.noarch 0:1.29-1.el7 will be an update ---> Package mock.noarch 0:1.4.13-1.el7 will be updated ---> Package mock.noarch 0:1.4.14-1.el7 will be an update --> Processing Dependency: python2-jinja2 for package: mock-1.4.14-1.el7.noarch ---> Package mock-core-configs.noarch 0:29.4-1.el7 will be updated ---> Package mock-core-configs.noarch 0:30.1-1.el7 will be an update --> Finished Dependency Resolution Error: Package: mock-1.4.14-1.el7.noarch (epel-testing) Requires: python2-jinja2 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
[root@70994cb94028 ~]# repoquery --whatprovides python2-jinja2 [root@70994cb94028 ~]# repoquery --whatprovides python-jinja2 python-jinja2-0:2.7.2-2.el7.noarch
Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 31, in <module> import dnf.base File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module> from dnf.module.metadata_loader import ModuleMetadataLoader File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module> gi.require_version('Modulemd', '1.0') File "/usr/lib64/python3.6/site-packages/gi/__init__.py", line 134, in require_version (namespace, version)) ValueError: Namespace Modulemd not available for version 1.0
Sure, but I think calling this a "weird error" is acceptable as you just pointed out: we're doing a bad thing, and the error we see isn't that we're doing a bad thing, its that something else, later, way down the line, is broken.
Are you sure that you are not doing a bad thing? OpenQA do the same as normal user would do. Just call
dnf update and the result is combination of packages which cause failures to install freeIPA.
And it is obviously caused by this bodhi update because it pass without updates-testing.
Sure; error reporting could be better. But assumption about
$CURRENT_VERSION+1 is difficult. You can obsolete some packages; replace ... So it is would be a challenge to guess which set of packages should be installed.
I would appreciate if you could either un-push this update from updates-testing or add freeipa-4.7.2 to this update. I am not sure whether you have permissions for that.