Bug 1190763 - RFE: Can Koji be made to grab logs from a tree it has just built or failed to build?
Summary: RFE: Can Koji be made to grab logs from a tree it has just built or failed to...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1217465
TreeView+ depends on / blocked
 
Reported: 2015-02-09 15:29 UTC by David Howells
Modified: 2015-06-20 21:13 UTC (History)
9 users (show)

Fixed In Version: mock-1.2.10-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1217465 (view as bug list)
Environment:
Last Closed: 2015-05-01 16:50:35 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1219432 None CLOSED Default chroot_scan plug-in config, if uncommented, doesn't exclude procfs files 2019-11-06 10:45:23 UTC

Internal Links: 1219432

Description David Howells 2015-02-09 15:29:52 UTC
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.

Comment 1 Dennis Gilmore 2015-02-09 15:46:44 UTC
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.

Comment 2 David Howells 2015-02-16 13:17:37 UTC
Apparently, it might be possible to use a mock plugin to capture the logs:

http://fedoraproject.org/wiki/Projects/Mock/Plugin/ChrootScan

Comment 3 Miroslav Suchý 2015-02-16 13:58:38 UTC
Reassigning back to koji per #2
However I highly recommend to first standardize (FPC?) which paths should be grabbed.

Comment 4 Miroslav Suchý 2015-02-16 15:30:31 UTC
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

Comment 5 David Howells 2015-03-31 15:05:38 UTC
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?

Comment 6 Dennis Gilmore 2015-04-01 03:10:33 UTC
the requested behaviour should be mocks default behaviour on a failure. reassigning back to mock.

Comment 7 Miroslav Suchý 2015-04-22 15:08:16 UTC
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.

Comment 8 Dennis Gilmore 2015-04-23 00:16:42 UTC
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.

Comment 9 Fedora Update System 2015-04-29 13:16:25 UTC
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

Comment 10 Fedora Update System 2015-04-29 13:16:51 UTC
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

Comment 11 Fedora Update System 2015-04-29 13:17:44 UTC
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

Comment 12 Fedora Update System 2015-04-29 13:18:51 UTC
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

Comment 13 Fedora Update System 2015-04-29 13:25:43 UTC
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

Comment 14 Dennis Gilmore 2015-04-29 13:47:23 UTC
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.

Comment 15 Fedora Update System 2015-04-29 19:18:34 UTC
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).

Comment 16 David Howells 2015-04-30 10:34:59 UTC
Do the saved logs just appear through koji now?

Comment 17 Miroslav Suchý 2015-04-30 10:56:47 UTC
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

Comment 18 David Howells 2015-04-30 11:38:16 UTC
Should I dup this bz for koji?

Comment 19 Miroslav Suchý 2015-04-30 12:18:17 UTC
Yes, please.

Comment 20 Dennis Gilmore 2015-04-30 18:11:52 UTC
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.

Comment 21 Clark Williams 2015-04-30 18:30:29 UTC
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.

Comment 22 Miroslav Suchý 2015-05-01 13:40:35 UTC
> 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.

Comment 23 Fedora Update System 2015-05-01 16:50:35 UTC
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.

Comment 24 Fedora Update System 2015-05-02 18:08:15 UTC
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.

Comment 25 David Howells 2015-05-06 09:17:37 UTC
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?

Comment 26 Miroslav Suchý 2015-05-06 11:06:27 UTC
> Should the plugin exclude procfs files?

Can you file it as new BZ?

Comment 27 Fedora Update System 2015-05-12 20:46:58 UTC
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.

Comment 28 Fedora Update System 2015-06-04 11:42:07 UTC
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

Comment 29 Fedora Update System 2015-06-04 11:42:53 UTC
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

Comment 30 Fedora Update System 2015-06-20 21:10:31 UTC
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.

Comment 31 Fedora Update System 2015-06-20 21:13:28 UTC
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.


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