Description of problem: The problem is that the output of a non-interactive command is only printed to stdout after the command has been executed. This can be troublesome for cases where the command is executed within a CI system (where output indicates progress) and the command takes a long time to execute. It would be nice if the output of the command could be spliced to the standard streams, perhaps in addition to the being sent to the log files. This could be a matter of passing stdout/stderr as some kind of logger to doChroot/logOutput, but without adorning the output. Version-Release number of selected component (if applicable): 1.1.15 Expected results: See the output of a --chroot command in real time.
The main routine for running things inside the chroot is in py/mockbuild/util.c and is named 'do'. It's used all over in mock so throwing a hack at it is almost guaranteed to break something. This will require a bit of thought due to the way we currently slurp up output from a command running in the chroot.
Agreed, there is even a bug in older Python versions where subprocess.Popen fails when passed stdio/stderr. I hacked around this issue by introducing a new spliceOutput parameter to 'do', which causes it to duplicate stdout/stderr and to wait() synchronously for the child to die.
Created attachment 528063 [details] First attempt at unbuffering output of commands from --chroot This patch modifies the routines involved in running a command inside the chroot, such that a 'printOutput' parameter may be passed into logOutput to tell the routine to print any output from the command immediately.
Davi, I've attached my first cut at attempting to unbuffer --chroot output. Not sure I have it right yet but thought you might want to look at it.
Works for me.
That actually added tons of output for my regression tests which was unexpected. I need to go over it some more and figure out why I'm getting more output from my tests than I expected. I'm going to release 1.1.16 without this patch and then work a bit at figuring out what's going on.
Created attachment 533178 [details] Second attempt at unbuffering --chroot output I believe this one will do the trick and will not flood my test case log files with output. Please review for next release
Looks good.
mock-1.1.18-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mock-1.1.18-1.el6
mock-1.1.18-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc15
mock-1.0.25-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mock-1.0.25-1.el5
mock-1.1.18-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc14
mock-1.1.18-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/mock-1.1.18-1.fc16
Package mock-1.0.25-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mock-1.0.25-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-5097/mock-1.0.25-1.el5 then log in and leave karma (feedback).
mock-1.1.18-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.18-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.18-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
mock-1.1.18-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.0.25-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.