| 1 |
hasufell schrieb: |
| 2 |
> When I sum that up again... |
| 3 |
> - we are on gentoo and need as much information as possible for |
| 4 |
> backtracing, resolving bugs, checking whether CFLAGS and such have been |
| 5 |
> respected |
| 6 |
> - no need to tell the user to recompile with |
| 7 |
> EXTRA_ECONF="--disable-silent-rules" or similar just to be able to help him |
| 8 |
> - some QA checks might depend on verbose build log and are not yet |
| 9 |
> implemented therefor |
| 10 |
> - if people want nice build _output_ (not log), they can use --quiet-build |
| 11 |
|
| 12 |
Sorry that I am late to the party, but I would add some concerns to this |
| 13 |
discussion. |
| 14 |
|
| 15 |
Verbose build logs are can be several times as large as non-verbose |
| 16 |
ones, which can run into our Bugzilla's attachment size limit. When a |
| 17 |
user is unable to attach the build.log file, typically one of the |
| 18 |
following happens: |
| 19 |
|
| 20 |
1. User compresses build.log with a common compressor like gzip, bzip2 |
| 21 |
or xz and manually sets the attachment MIME type correctly (best case). |
| 22 |
2. User makes a compressed tarball, containing a single file |
| 23 |
3. User cuts off the build.log somewhere in the middle, supplies the |
| 24 |
bottom part |
| 25 |
4. User uploads build.log to a public file hoster or his own private web |
| 26 |
server, the link expires / 404s after some time (IMO worst case). |
| 27 |
|
| 28 |
In my opinion, build verbosity should not be dictated by policy, but |
| 29 |
rather left to the discretion of the maintainer. After all, he is the |
| 30 |
one who needs to deal with the bug reports. |
| 31 |
|
| 32 |
Having verbose build logs by default (with the possibility for the |
| 33 |
maintainer to override) would be ok with me though. |
| 34 |
|
| 35 |
|
| 36 |
Best regards, |
| 37 |
Chí-Thanh Christopher Nguyễn |
Archives