Hide Forgot
Description of problem: To reproduce a gcc bug I need full local rebuild to find out the compilation line. rpm build.log could+should provide all the info. Version-Release number of selected component (if applicable): kernel-2.6.35.13-91.fc14.x86_64 How reproducible: Always. Steps to Reproduce: wget -O - http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.13/91.fc14/data/logs/x86_64/build.log Actual results: Nothing seen. Expected results: Compilation lines seen. Additional info: The rpmbuild output is only useful to be stored into various log files anyway.
In fact it is already there, it just does not work: make -s ARCH=$Arch V=1 %{?_smp_mflags} $MakeTarget %{?sparse_mflags} -> + make -s ARCH=x86_64 V=1 -j16 bzImage
my guess is that the build system isn't capturing stdout, just stderr ? reassigning to koji to start, even though it might be some other part of the buildsys.
s/make -s /make / fixes it as I found later.
It is mock that generates build.log, and it does capture stderr (see the do() function in mock/util.py). I suppose there could be a bug in python's subprocess module. Also rpmbuild (or some other process in the chain) could be killing stderr. If nothing else captures it, then stderr will then be captured in mock_output.log by koji. Your theory is easy to test. Just make some explicit writes to stderr in your spec and see if you get the output.
As the problem+fix is reproducible with rpmbuild (Comment #3) i find Koji to be offtopic here.
oh, duh. yeah that'll do it. I'll make the change in git.
I thought we were intentionally hiding make output so that warnings stood out. They get lost in the noise otherwise, unless you make all warnings fatal compile errors.
It is dangerous to ship code with warnings.
with the rate that new warnings appear (and old ones stick around), I'm not sure it's that big a deal. I think that most people don't read the build logs unless something fails. We could add yet another magic variable to config this on or not, but I'm not sure it's really worth it.
(In reply to comment #9) > We could add yet another magic variable to config this on or not, but I'm not > sure it's really worth it. This Bug is request the default Fedora build.log files contain the flags. New .spec flag not in use by default is not useful, I can remove "-s" in that case if I have to do a rebuild anyway. This request is in direct conflict with Comment 7.
We're going to close this as wontfix. Those needing to fix warnings or determine the build flags are likely already doing local builds anyway. For the rest of people, it just grows the build logs unnecessarily.
(In reply to comment #15) > Those needing to fix warnings or > determine the build flags are likely already doing local builds anyway. FYI Comment 13 explains why this is not applicable.
Reopening as this behavior is now decided as global Fedora policy. [PATCH] macros: Globally add --disable-silent-rules to configure http://lists.fedoraproject.org/pipermail/devel/2011-August/155444.html redhat-rpm-config-9.1.0-16.fc17 * Wed Aug 10 2011 Colin Walters <walters> - 9.1.0-16 - Globally disable silent rules
Re-closing as this is still painfully excessive for the kernel.