Bug 554240 – Enable compress-build-logs FEATURE by default

• Product: Portage Development
• Status: CONFIRMED ---

[Description Pacho Ramos 2015-07-08 13:51:08 UTC]

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

[Comment 1 Mike Gilbert 2020-08-09 03:26:24 UTC]

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.

[Comment 2 Pacho Ramos 2020-08-09 12:49:41 UTC]

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

[Comment 3 Zac Medico 2020-08-09 23:56:06 UTC]

(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).

[Comment 4 Fabian Groffen 2020-08-10 06:47:53 UTC]

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.