Created attachment 1672135 [details] Output of trying mock init without repos in baseurl and mock init with variables in baseurl Description of problem: bind_mount performed on local paths appears to only work when explicitly referenced rather than using variables present through rest of .tpl file (e.g. $releasever and $basearch do not appear to work when used in a baseurl=file:/// path) Version-Release number of selected component (if applicable): How reproducible: every time Steps to Reproduce: 1. create mock template file that specifies a local repo (e.g. baseurl=file:///) and use variables (e.g. $releasever and/or $basearch) 2. perform: mock --scrub=all; mock clean; mock init 3. Actual results: local repo causes mock init to fail with "Curl error (37): Couldn't read a file:// file" Expected results: mock successfully bootstraps and builds environment that incorporates packages from local repo Additional info: first suspected NFS issue, possible root_squash interference, SELinux. setenforce 0; rsync'd repo from NFS server to local path (e.g. in /srv), used absolute repo paths in local repo definitions, then moved onto trying it against an NFS path, then tried with NFS path with root_squash re-enabled, then finally tried with setenforce 1. Each change saw mock complete successfully, but *only* when I did not use variables in the baseurl path. Also, I think this is the first bug I've ever formally submitted on here (that wasn't automatically submitted via abrt or whatever the automated bug reporting utility is... Please excuse any deviation from accepted decorum on my part, will try to be as helpful, thorough, and patient as possible. Here's an fpaste I made demonstrating the problem: https://paste.centos.org/view/4da7b163
Forgot to include mock version info: bender@head0:~$ rpm -qa | grep mock mock-core-configs-32.4-1.fc31.noarch mock-2.1-1.fc31.noarch bender@head0:~$
Thanks for the report. Interesting, is this blocking some real use-case? Please disable bootstrap chroot for now, use fully expanded paths or use jinja like: http://example.com//{{ releasever }}/{{ target_arch }}/os/
Pavel, Not blocking anything pressing or urgent, was just tinkering with trying to build the new v20 release of Slurm on Fedora 31 and came across this problem. I'm able to get around it by using expanded paths like you said. I tried jinja syntax and it worked just fine: https://paste.centos.org/view/8671d4f2 Wasn't sure how to disable bootstrapping, but it appears to have worked with expanded paths or jinja syntax.
Created attachment 1672306 [details] Output of mock init using jinja syntax on local repos
https://github.com/rpm-software-management/mock/pull/552
FEDORA-2020-fba9845e22 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fba9845e22
FEDORA-2020-6b7c342fb4 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b7c342fb4
FEDORA-2020-85df0014c1 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-85df0014c1
FEDORA-2020-fba9845e22 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fba9845e22` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fba9845e22 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-85df0014c1 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-85df0014c1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-85df0014c1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-6b7c342fb4 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6b7c342fb4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b7c342fb4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-fba9845e22 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-6b7c342fb4 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-85df0014c1 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.