I keep seeing a lot of people (and also me) noticing that build.log is too big for bugs.gentoo.org only when it fails to upload the file :/ Is there any downside on enabling compress-build-logs by default and getting smaller build.log files by default? Thanks a lot
Most build logs that are attached to bug reports are under the 1MB limit. Most browsers will not display a compressed file, which makes reviewing logs slightly more difficult. I would prefer compression to remain off by default.
Maybe it can be done as docompress does. If I don't misremember, only doc files bigger than a specified size are compressed, while others don't
(In reply to Pacho Ramos from comment #2) > Maybe it can be done as docompress does. If I don't misremember, only doc > files bigger than a specified size are compressed, while others don't Since the log file size is unknown when the build begins, we'd have to wait until after the build completes or fails before we decide whether or not the log is supposed to be compressed (and if we toggle compression at this point then it will change the path of the log shown in the die message).
If a pipe is used to send the log-output to file and optionally screen, one could keep track of how much data was transferred, and at a certain treshold, flush the file, create a new compressed file with associated stream, read all from the file to the (compressed) stream, delete the plain file, and continue logging with the new (compressed) stream. It's a tad bit complicated, with perhaps questionable gains.