Dne 1.2.2017 v 22:18 Vit Ry napsal(a):
I didn't test `--new-chroot` itself because it doesn't fit my
use-cases. How do you use `--new-chroot` ?
It is the same as
config_opts['use_nspawn'] = True
I'm using `--shell` for some general purposes because it splits
stdout and stderr of command, which is desired and expected behaviour.
For example:
$ mock -q -r epel7.cfg --shell 'rpmspec -P somespec.spec' > spec-parsed.spec ,
or `rpmspec -q ` and so on.
rpmspec will output smth like
> warning: bogus date in %changelog: Thu May 26 2006 Tim Waugh
<twaugh(a)redhat.com> 3.1-13
on most of specs to stderr. But in case of --*-chroot or systemd-nspawn I'll get
broken spec with mixed output and so on.
It looks for me as systemd's bug now, not mock's. Isn't it?
Really? With mock-1.3.3 I run:
mock --shell --new-chroot ">&2 echo 'error'" >/tmp/o
2>/tmp/e
and /tmp/o is empty end /tmp/e contains:
INFO: mock.py version 1.3.3 starting (python version = 3.5.2)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: skipping root_cache aging check
INFO: enabled dnf cache
Start: cleaning dnf metadata
Finish: cleaning dnf metadata
INFO: enabled HW Info plugin
Finish: chroot init
Start: shell
error
Finish: shell
First of all, I can't mount_bind to /tmp inside chroot. It looks
odd.. (I'll report it on BZ tomorrow).
Please do.
Second - using of `use_nspawn` breaks `--shell` option also :(
It mixes stderr and stdout. Does it hard to fix..?
See above.
Would 'Make --new-chroot default' affect `--shell` behaviour
?
Definitely yes.
Third. I faced with a bit strange behaviour while mock processing
changes in config files.
When I change
* config_opts['macros']['%_smp_mflags']
* config_opts['chroot_setup_cmd']
* config_opts['plugin_conf']['root_cache_enable']
and so on, I expect that changes would be affected immediately and cache would be
rebuilded.
But it doesn't have any effects until I manually run
# rm -rf /var/lib/mock* /var/cache/mock/*
Is it "by design"..? Is it possible to force root rebuilding on changes that
would affect build process..?
Unless you have
config_opts['plugin_conf']['root_cache_opts']['age_check'] =
False
then root cache should be deleted when timestamp of config change.
See:
https://github.com/rpm-software-management/mock/wiki/Plugin-RootCache
If you experience something else, then it is bug.
Not in my TODO list for near future.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys