Description of problem: The recent mock update in EPEL 7 [1] introduced this upstream commit [2] for calling systemd-nspawn with --chdir. But this option does not exist yet in RHEL/CentOS-7. Version-Release number of selected component (if applicable): mock-2.11-1.el7 How reproducible: Always Steps to Reproduce: 1. mock --shell true Actual results: Crashes with [...] Finish: chroot init Start: shell /usr/bin/systemd-nspawn: unrecognized option '--chdir=/builddir' Expected results: Works Additional info: [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1763874 [2] https://github.com/rpm-software-management/mock/commit/707da91681b73398ce11c931c09b1c99004be3be
Thank you Martin for the report. The work-around is to use --isolation=simple. The fix to this is not going to be trivial, the --shell/--chroot code is a can of worms. Perhaps the less painful thing would be to stop using --chdir on el7 only (it never worked before, and still nobody cared?).
Right, I did find out about --isolation=simple, but for our purpose (cockpit CI) it's a bit impractical -- that mock command is in a very central location and applies to all Fedora/RHEL/CentOS builds, we don't want to use plain chroot for all of them (but rather prefer the default). We can apply a hack of course. But isn't this going to bite other users too, and possibly even the official build infra?
Official Koji is using --isolation=simple if I'm informed enough. I also believe that the migration from EL7 to EL8 is accelerating across our userbase. That said, if this has not hurt anyone since now on EL7 - we should be OK without 707da91681b73398ce11c931c09b1c99004be3be on EL7 till it's end.
Right, sounds like reverting that commit for EL7 is the right thing then -- it completely breaks builds, and if nobody explicitly asked for it then there's no urgency for landing that?
FEDORA-2021-c47a3df22d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c47a3df22d
FEDORA-2021-3209d8af9e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3209d8af9e
FEDORA-EPEL-2021-d4503b73f3 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4503b73f3
FEDORA-EPEL-2021-45d010c190 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-45d010c190
FEDORA-2021-3209d8af9e has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3209d8af9e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3209d8af9e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-d4503b73f3 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4503b73f3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-c47a3df22d has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c47a3df22d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c47a3df22d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-45d010c190 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-45d010c190 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-c47a3df22d has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-3209d8af9e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-d4503b73f3 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-45d010c190 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
I'm a bit worried -- the fixed 2.12 got pushed to EPEL 7 4 days ago, but is *still* not visible. Moreover, even "yum info --enablerepo=epel-testing mock" only shows 2.11 still. Are the composes being generated that rarely?
I've just installed 'mock-2.12-1.el7.noarch' into the centos:7 container. I thought that when the update switches to 'stable' it means that it got into a compose (but that's just from my black-box observation). It also takes some time till mirrors pick up that build.
Pavel, did you download the build from koji, or did you actually use yum and the EPEL repo for that? Thanks!
Yes, epel repo: $ yum install -y epel-release $ yum install -y mock