Bug 1447627

I've got similar issue. Trying to install the build result into the buildroot:

~~~
$ mock -r fedora-rawhide-x86_64 --offline -i /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm

... snip ...

Can not load RPM file: /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm.
Could not open: /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm
ERROR: Command failed: 
 # /usr/bin/systemd-nspawn -q -M 00eb4933abce482f881ca683351bd53b -D /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$  --setenv=LANG=cs_CZ.utf8 --setenv=LC_MESSAGES=C --setenv=LD_PRELOAD=/var/tmp/tmp.mock.qoq2oou5/$LIB/nosync.so /usr/bin/dnf --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 27 -C --disableplugin=local --setopt=deltarpm=false install /var/lib/mock/fedora-rawhide-x86_64/result/nuvolaplayer-3.1.3-2.fc27.x86_64.rpm
~~~

Obviously the boostrap buildroot doesn't have access to the outer world, so this fails.

Switching off systemd-nspawn doesn't seem to make any difference, although I had expected it to...

This workaround seems to work:

srpm=cockpit-138.x-1.wip.fc25.src.rpm

mock --clean
mock --init

root=/var/lib/mock/fedora-26-x86_64-bootstrap/root
mkdir -p "$root/$PWD"
cp "$srpm" "$root/$PWD/"

mock --installdeps "$PWD/$srpm"

Actually, you can disable the "bootstrap" thingy either by `--no-bootstrap-chroot` command line option or set:

```
    config_opts['use_bootstrap_container'] = False
``` 

in your mock config.

(In reply to Vít Ondruch from comment #4)
> Actually, you can disable the "bootstrap" thingy either by
> `--no-bootstrap-chroot` command line option or set:
> 
> ```
>     config_opts['use_bootstrap_container'] = False
> ``` 
> 
> in your mock config.

Thanks, that works as well and is of course much cleaner as a workaround.

Would it make sense to disable the bootstrap chroot by default, until it works?

Urgh I wondered why my mockchain and mock -i attempts were failing on trying to build a package with dependencies ...

Downgraded to 1.3.4 and it was fine ...

This was causing me pain in doing a review too ...

I've manually put that in all my mock configuration files for now.

I agree that really the bootstrap chroot needs to be set to False until it works to install packages in the mock chroot.

I've updated the subject to make it clear it affects --install as well so it's easier for the next person to find :)

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

BTW I have this repo configured to be able to consume the build output immediately into the mock:

~~~
... snip ...

config_opts['plugin_conf']['sign_enable'] = True
config_opts['plugin_conf']['sign_opts'] = {}
config_opts['plugin_conf']['sign_opts']['cmd'] = 'createrepo_c'
config_opts['plugin_conf']['sign_opts']['opts'] = '-o %(resultdir)s %(resultdir)s'

... snip ...

[result]
name=result
baseurl=file:///var/lib/mock/ruby/result
enabled=1
skip_if_unavailable=1
metadata_expire=0
cost=1

... snip ...
~~~

and obviously neither this works ...

Duplicate on github with some more info:
https://github.com/rpm-software-management/mock/issues/72

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

I don't think this has been addressed.

Most of these 'access to local rpm'-issues should be able to be addressed via the bind_mount-plugin.
Of course it would be favorable not to have to create these mounts manually but having them setup automatically at least in some situations where it is obvious for mock what has to be done.

Anyway there is still an issue that stays:

If you want to install local rpms during bootstrapping that will still fail as the bind-mounts are not gonna be setup then.
https://github.com/rpm-software-management/mock/pull/184
tries to address this issue.

Unfortunately the workaround mentioned - disabling the container - isn't applicable in situations when building on a yum-based release/distribution for a more modern dnf-based release/distribution that has rpms that aren't compatible with yum anymore.

I'm running into this as well.

(In reply to Orion Poplawski from comment #13)
> I'm running into this as well.

Meanwhile this bz has a list of similar issues that all have to do with the lack of being able to access the local filesystem from inside the systemd-container.
Which one are you running into?
Are you in a situation where disabling the container-build is applicable (and solves the issue)?

I cannot install local rpms into the buildroot.  I need bootstrap-chroot because I'm building for Rawhide on EL7.

(In reply to Orion Poplawski from comment #15)
> I cannot install local rpms into the buildroot.  I need bootstrap-chroot
> because I'm building for Rawhide on EL7.

Yep that is my scenario as well.
My pull-request referenced above should work for you and it would of course be cool if you find the time to make it recognize the file:// references automatically so that you don't have to manually create the bind-mount specifications.
But I personally would still keep the possibility to specify bind-mounts that are effective in the bootstrap as well manually. In my case for instance all the local repos are in one subtree so that it is sufficient to bindmount the top-level directory into the container.

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

My current workaround is to copy the rpms first to the boostrap root builddir, e.g.: /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/builddir/ and then use the /builddir/ patch to the rpms.

I'm affected too. I have the exact same use case as described in comments 12 through 15. I need to build in a Fedora 28 mock environment on RHEL 7, and that doesn't work without a bootstrap chroot (see bug 1578942 comment 0). I'll try to use the "manually copy the SRPM into the bootstrap chroot" workaround.

(In reply to Laszlo Ersek from comment #19)
> I'm affected too. I have the exact same use case as described in comments 12
> through 15. I need to build in a Fedora 28 mock environment on RHEL 7, and
> that doesn't work without a bootstrap chroot (see bug 1578942 comment 0).
> I'll try to use the "manually copy the SRPM into the bootstrap chroot"
> workaround.

As an alternative you can give this a try:
https://github.com/rpm-software-management/mock/pull/184

Didn't have the time to make it more user-friendly but maybe still better
than other solutions.

The workaround in comment 3 doesn't function for me. Even though I run both the mkdir and cp commands, and make sure the file is referenced by the correct pathname in the bootstrap chroot, the "dnf builddep" command, launched by systemd-nspawn, cannot find the file, when invoked from "mock --installdeps".

Klaus, re: comment 20, thanks for the suggestion, but for this use case I can't consume anything that's not in EPEL7 or RHEL7.

My next approach will be:
- disable the bootstrap container again
- replace the "mock --installdeps" command with "mock --chroot", and in
  the normal (build) chroot environment, install dnf, plus run "dnf
  builddep", manually

Nah, doesn't work; without the bootstrap container, the process breaks almost immediately due to bug 1578942.

The following *does* work however:

MOCK_CONF=fedora-28-x86_64
MOCK="mock -r $MOCK_CONF"
MOCK="$MOCK --config-opts=use_bootstrap_container=True"
MOCK="$MOCK --config-opts=rpmbuild_networking=True"

$MOCK --copyin -- "$SRPM_DIR/$SRPM_NAME" /
$MOCK --install dnf dnf-plugins-core
$MOCK --chroot -- dnf builddep "/$SRPM_NAME"
$MOCK --chroot -- rpm -i -v -h "/$SRPM_NAME"
$MOCK --chroot -- rpmbuild -bp "$MOCK_RPM_ROOT/SPECS/foobar.spec"

(For my use case, only the %prep stage is necessary.)

In other words,
- the bootstrap container is enabled, working around bug 1578942,
- the SRPM is copied into the *build* (not bootstrap) environment,
- the "--installdeps" mock action is replaced with
  - the "--install" action on "dnf" and "dnf-plugins-core"
    (note that for this, networking in the bootstrap container must be enabled!),
  - manual invocation of "dnf builddep" on the SRPM file in the *build* env.

Thanks.

PR: https://github.com/rpm-software-management/mock/pull/372

Can be tested with mock-1.4.20-1.git.7.e59e7e9 from:
$ dnf copr enable praiskup/mock-fixes

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

FEDORA-2019-ad7ecf205b has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ad7ecf205b

FEDORA-EPEL-2019-0549ec172d has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0549ec172d

FEDORA-EPEL-2019-3687ce895a has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3687ce895a

FEDORA-2019-755583cbdf has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-755583cbdf

mock-1.4.21-1.fc30 has been pushed to the Fedora 30 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-2019-c6079af90e

mock-1.4.21-1.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2019-0549ec172d

mock-1.4.21-1.el8 has been pushed to the Fedora EPEL 8 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-EPEL-2019-3687ce895a

mock-1.4.21-1.fc29 has been pushed to the Fedora 29 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-2019-ad7ecf205b

mock-1.4.21-1.fc31 has been pushed to the Fedora 31 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-2019-755583cbdf

mock-1.4.21-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

mock-1.4.21-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

mock-1.4.21-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

mock-1.4.21-1.el8 has been pushed to the Fedora EPEL 8 stable repository. If problems still persist, please make note of it in this bug report.

mock-1.4.21-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.