Bug 759253 - Disabling ccache breaks mock
Summary: Disabling ccache breaks mock
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 16
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-01 19:03 UTC by Jan Kratochvil
Modified: 2011-12-10 22:49 UTC (History)
4 users (show)

Fixed In Version: mock-1.1.18-1.fc16.noarch
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-10 22:49:31 UTC
Type: ---


Attachments (Terms of Use)

Description Jan Kratochvil 2011-12-01 19:03:42 UTC
Description of problem:
I disable ccache as it has zero or negative effect on my i7-920 with HDD.
But such configuration completely breaks mock when used from the beginning.
(I use ccache and it has positive effect on i7-2620M with SSD.)

Version-Release number of selected component (if applicable):
mock-1.1.18-1.fc16.noarch

How reproducible:
Happened now for all my repositories on the system.
IIRC I already had to workaround it before.

Steps to Reproduce:
Disable ccache in /etc/mock/site-defaults.cfg
mock -r fedora-16-x86_64 --init
Upgrade mock to mock-1.1.18-1.fc16 which overwrites /etc/mock/site-defaults.cfg and re-enables ccache there.
and:
mock -r fedora-16-x86_64 --update

Actual results:
INFO: mock.py version 1.1.18 starting...
State Changed: init plugins
INFO: selinux disabled
State Changed: start
Mock Version: 1.1.18
INFO: Mock Version: 1.1.18
State Changed: lock buildroot
WARNING: Command failed. See logs for output.
 # umount -n /var/lib/mock/fedora-16-x86_64/root/tmp/ccache
ERROR: Command failed. See logs for output.
 # mount -n --bind /var/cache/mock/fedora-16-x86_64/ccache/  /var/lib/mock/fedora-16-x86_64/root/tmp/ccache

Expected results:
Working mock.

Additional info:
mock -v -r fedora-16-x86_64 --update
[...]
DEBUG: mount -n --bind /var/cache/mock/fedora-16-x86_64/ccache/  /var/lib/mock/fedora-16-x86_64/root/tmp/ccache
DEBUG: Executing command: mount -n --bind /var/cache/mock/fedora-16-x86_64/ccache/  /var/lib/mock/fedora-16-x86_64/root/tmp/ccache
DEBUG: mount: special device /var/cache/mock/fedora-16-x86_64/ccache/ does not exist
DEBUG: Child returncode was: 32
DEBUG: Executing command: umount -n /var/lib/mock/fedora-16-x86_64/root/tmp/ccache
DEBUG: umount: /var/lib/mock/fedora-16-x86_64/root/tmp/ccache: not mounted
DEBUG: Child returncode was: 1
WARNING: Command failed. See logs for output.
 # umount -n /var/lib/mock/fedora-16-x86_64/root/tmp/ccache

Comment 1 Jan Kratochvil 2011-12-01 19:10:50 UTC
I am using in /etc/mock/site-defaults.cfg:
config_opts['plugin_conf']['ccache_enable'] = False

Not sure why it got lost /etc/mock/site-defaults.cfg is marked as a config file.

Comment 2 Ville Skyttä 2011-12-02 21:59:51 UTC
BTW ccache in mock is almost completely useless in mock 1.1.16-1.1.18 as the ccache results are not saved to the correct dir but to one that gets destroyed between mock chroot inits.  Fix for this is already in mock git but there's no release out with it yet:
https://fedorahosted.org/mock/changeset/9149d2661347e6ed43737f0217057715a675b334
https://fedorahosted.org/mock/changeset/70c38cb1b36da1301f7d3df23d788d49d70c6371


Regarding site-defaults.cfg being overwritten on 1.1.18 update, I could not reproduce.  I set up a new fedora-16-x86_64 chroot, did a "mock install mock" on it, modified /etc/mock/site-defaults.cfg in the chroot to disable ccache, then upgraded mock in the chroot with "mock --install http://kojipkgs.fedoraproject.org/packages/mock/1.1.18/1.fc16/noarch/mock-1.1.18-1.fc16.noarch.rpm" and got this in the output:

warning: /etc/mock/site-defaults.cfg created as /etc/mock/site-defaults.cfg.rpmnew

...and site-defaults.cfg was not overridden.

Comment 3 Jan Kratochvil 2011-12-02 22:44:56 UTC
(In reply to comment #2)
> Regarding site-defaults.cfg being overwritten on 1.1.18 update, I could not
> reproduce.

I also cannot reproduce it now, thanks for testing it.

(Maybe that I am testing btrfs which has some file problems such as Bug 759426.)

Comment 4 Clark Williams 2011-12-10 18:50:28 UTC
Is this still broken with 1.1.18?

Comment 5 Jan Kratochvil 2011-12-10 22:49:31 UTC
Not with 1.1.18, thanks.


Note You need to log in before you can comment on or make changes to this bug.