Unable to build fc25 chroots with mock

Description

Mock fails when trying to build the chroot for fedora25, on installing '@buildsys-build' group(with dnf) stage.

Open bug: https://bugzilla.redhat.com/show_bug.cgi?id=1360781
Temporarily workaround: add the 'libcrypt' package to '.packages.fc25' file.
Possible solution: patch mock-fc25.cfg file in Jenkins repository to always install 'libcrypt' first.

Until fixed this will block us from building anything with mock on fc25(hit it when trying to build fc25 RPMs for lago).

Error logs:

DEBUG util.py:502: Executing command: ['/usr/bin/yum-deprecated', '--installroot', '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/', '--releasever', '25', 'install', '@buildsys-build', 'git', 'python', 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils', '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', .... DEBUG util.py:421: Yum command has been deprecated, use dnf instead. DEBUG util.py:421: See 'man dnf' and 'man yum2dnf' for more information. DEBUG util.py:421: Error: libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64 DEBUG util.py:421: Error: libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64 DEBUG util.py:421: You could try using --skip-broken to work around the problem DEBUG util.py:421: You could try running: rpm -Va --nofiles --nodigest DEBUG util.py:557: Child return code was: 1 DEBUG util.py:180: kill orphans

Activity

Show:

Barak Korren February 2, 2017 at 7:40 AM

probably not worth the effort at this point. "If it works don't touch it". Test see about this when we try to introduce fc26 in a few months.

Looking at the bug, it seems we may be getting this for "free" though, by just doing "yum update mock".

Nadav Goldin February 1, 2017 at 8:01 PM

If we want to give it a try, according to https://bugzilla.redhat.com/show_bug.cgi?id=1405783, it might be possible to use el7.3+dnf+mock now.

Barak Korren January 1, 2017 at 2:23 PM

This patch resolved the issue for now: https://gerrit.ovirt.org/#/c/69077/

Anton Marchukov December 20, 2016 at 3:55 PM

Another solution as I see would be to check the current status of "dnf" in epel, here are some references:

"EL6 and EL7 does not have DNF available (well there is DNF in EPEL7, but not dnf-plugins-core, which are crucial for for Mock)." and in comments there is a reference to some old dnf-plugins-core build:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-6436

it might be that everything needed is already in EPEL and this potentially may mean that we can install dnf and everything needed on CentOS7 vms we use and use "dnf" only for Fedora mocks while keeping "yum" for CentOS mocks. Not sure if they can work together and if it is possible to make it work, but this is another direction to explore.

Anton Marchukov December 20, 2016 at 3:52 PM

Official information:

https://github.com/rpm-software-management/mock/wiki#mock-on-el-6-and-el-7-yum-and-dnf
http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not_work_on_el_6_and_el7_and_how_to_fix_it/index.html

the later says:

"This is something which you may want to do, when you are building some packages for personal usage. However you should avoid that if you are operating some build system. In such case migration to some recent Fedora is your only option." and "Change Mock settings that EL6 and EL7 users will continue to use Yum for building Fedora rawhide (and F23+). While this option seems to be good trade-off, there is big risk that you end up with different binary compared to the same process on Fedoras. For example there was issue that Rubygems requires ruby(release), which Yum resolved to normal ruby, however DNF resolved that to jruby. And that is big difference."

and all the workarounds proposed as I see for the opposite - use yum enabled mocks on fedora.

Upgrading Fedora seems to me standard and supported procedure and business as usual. If we do it manually we can automate it so it scales.

Inserting hacks into "yum" to work with Fedora composes is not standard and not supported. Hence it is not possible to automate and it will always be manual work on its own and thus I do not think it is sustainable solution for future. Especially since we do have Fedora slaves already and have to support them anyway.

Fixed

Details

Assignee

Reporter

Priority

Created December 12, 2016 at 5:05 PM
Updated February 2, 2017 at 7:40 AM
Resolved January 1, 2017 at 2:23 PM

Flag notifications