The proposed solution is in the tracker. If this is an autotools based package, and '--disable-silent-rules' doesn't work, you can try to add MAKEOPTS+=" V=1"
you should check yourself if this is autotools based and depending on that do the following - autotools-based: do nothing, it will eventually be upgraded to EAPI-5 at some point - some other build systems controlled by an eclass: file a bug for the whole eclass - packages controlled by a common eclass (like games.eclass) could also be solved in one blow by porting the portage-code of appending --disable-silent rules to "egamesconf" for EAPI lower 5 - custom build system: you provide a patch. There is not much interest about fixing this, so don't expect anything if you don't provide a patch.
(In reply to comment #1) > - custom build system: you provide a patch. There is not much interest about > fixing this, so don't expect anything if you don't provide a patch. Probably we have a different poing of view of a bug. I invite you to revise it. The devmanual says: When writing ebuilds, you should always check the build log, because the build system might ignore CC/CXX/LD/CFLAGS/LDFLAGS and such or add undesired flags by default. In order to analyze this and have complete information, in case someone reports a bug for your package, the build log must always be verbose. This means that when _you_ did the first commit of this ebuild you did not check, then you'd be in 'fault'. So _you_ need to fix this because _you_ are the maintainer. I don't need to post a patch, because is not a personal request.
then I will fix the devmanual
(In reply to comment #3) > then I will fix the devmanual If we need a verbose log, is because we need to see all is respected. So I think we need a verbose log in all possible buildsystem's scenario. It is always a maintainer task. If is autotools-based then is simply, if not, the maintainer need to do more work, but _imho_ does not make sense ask patch only because the task isn't fixable in few minutes.
SHould be fixed now.
