Description of problem: It would be really handy if koji grabbed logs from a failed build (and even successful builds) and put them somewhere they could be accessed - even if it was only available for a day or so. As to how to find the logs, just scraping all files matching *.log from the build tree into a tarball would probably be a good start. I have two examples of where this might be useful: (1) gcc-5 dumps a whole chunk of tar'd, bzip'd and uuencoded testing logs to stdout because it has nowhere else to put them. (2) I'm seeing a config failure building cross-gcc on ARM that doesn't occur on x86_64 or i686 - but it happens in koji where I can't get at the config.log to see what happened. Ideally, rpmbuild would gather the logs and put them somewhere koji or someone running rpmbuild by hand could get them, perhaps in a tarball.
koji takes the output of mock. so to fix this we would need mock to output things like config.log or the files generated by gcc when it gives an ICE. I am reassigning the bug to mock as that is where the change will need to happen.
Apparently, it might be possible to use a mock plugin to capture the logs: http://fedoraproject.org/wiki/Projects/Mock/Plugin/ChrootScan
Reassigning back to koji per #2 However I highly recommend to first standardize (FPC?) which paths should be grabbed.
I just find that this plugin was missing in mock due stupid mistake (missing line in Makefile). It will be included in mock-1.2.8
Could the build tree just be scanned for files matching a "*.log" pattern for starters? That'd pick up the stuff left behind by configure sripts?
the requested behaviour should be mocks default behaviour on a failure. reassigning back to mock.
Done in commit: * 134820a chroot_scan: implement "only_failed" option [RHBZ#1190763] chroot_scan is now extended by option 'only_failed' # config_opts['plugin_conf']['chroot_scan_enable'] = False # config_opts['plugin_conf']['chroot_scan_opts'] = { ## Regexp of files which should be copied from buildroot to resultdir. # 'regexes': [ "core(\.\d+)?", "\.log$",], ## If set to True files are copied only if build failed. # 'only_failed': True, #} If plugin is enabled (I keep it disabled by default, no change here) and you set "only_failed" to True (the default), then all regexes are coppied from chroot to resultdir. It is up to Koji owners if they enable this plugin and set up regexes. Please clone this BZ for Koji product if still interrested in.
There is a lot of benefit to getting the logs for all mock builds. getting config.log and .out files from /tmp when gcc gies internal compiler errors etc. it should be the default behaviour of mock and koji would just inherit it.
mock-1.2.8-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/mock-1.2.8-1.fc22
mock-1.2.8-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mock-1.2.8-1.fc21
mock-1.2.8-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mock-1.2.8-1.fc20
mock-1.2.8-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/mock-1.2.8-1.el7
mock-1.2.8-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.2.8-1.el6
Plugin should be enabled by default. It should be mocks default behaviour and you shoudl find .out files in /tmp also as that is what is output when gcc has a internal compiler error.
Package mock-1.2.8-1.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.2.8-1.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-6057/mock-1.2.8-1.el7 then log in and leave karma (feedback).
Do the saved logs just appear through koji now?
No. Koji have to enable it. It is disabled by default for those reasons: * I hesitate to enable it by default as it is brand new code and not widely tested * lots of mock users are not interested in those logs, I would guess that majority of them
Should I dup this bz for koji?
Yes, please.
I am going to close the cloned bug as wontfix, this really needs to be the default behaviour in mock, there has been requests for it going back the last 10 years. It must be fixed in mock.
I suppose the question I have is: what is the downside to scanning the chroot and pulling log files of interest into the results dir? Does it take an extraordinary amount of time? Tons of space eaten up? If not, I'm ok with turning the plugin on by default. If lots of mock users get bent out of shape because of it, we can revisit.
> there has been requests for it going back the last 10 years. In fact this is first time I seen such request. However I must say I track the mock development only last 5 years, not ten.
mock-1.2.8-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.8-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Hmmm... I would suggest that the following is *not* correct: 16724 pts/0 S+ 0:00 | \_ /usr/bin/python /usr/bin/fedpkg mockbuild 16748 pts/0 S+ 0:04 | \_ /usr/bin/python -tt /usr/sbin/mock -r fedora-20-x86_64 --resultdir /data/fedora/cross-binutils/results_cross-binutils/2.25/3.fc20 --rebuild /data/fedora/cross-binutils/cross-binutils-2.25-3.fc20.src.rpm 9142 pts/0 R+ 0:10 | \_ cp --parents /var/lib/mock/fedora-20-x86_64/root/proc/kcore /data/fedora/cross-binutils/results_cross-binutils/2.25/3.fc20/chroot_scan All I did was to uncomment the lines in site-defaults.cfg: config_opts['plugin_conf']['chroot_scan_enable'] = True config_opts['plugin_conf']['chroot_scan_opts'] = { # Regexp of files which should be copied from buildroot to resultdir. 'regexes': [ "core(\.\d+)?", "\.log$",], # If set to True files are copied only if build failed. 'only_failed': False, } Should the plugin exclude procfs files?
> Should the plugin exclude procfs files? Can you file it as new BZ?
mock-1.2.8-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.10-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/mock-1.2.10-1.el7
mock-1.2.10-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.2.10-1.el6
mock-1.2.10-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.2.10-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.