| 1 |
On Monday 05 December 2011 17:13:26 Chí-Thanh Christopher Nguyễn wrote: |
| 2 |
> Mike Frysinger schrieb: |
| 3 |
> >> Not all failures are errors, only errors are shown |
| 4 |
> > |
| 5 |
> > all failures as characterized by "ebuild called `die`" get shown -- |
| 6 |
> > portage dumps the entire log, thus your need to copy & paste the log |
| 7 |
> > file to `cat` is garbage. |
| 8 |
> > |
| 9 |
> > all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc |
| 10 |
> > on missing file) will get "missed". many of those are logged as QA |
| 11 |
> > warnings, but it seems default --quiet-build=y will not include these in |
| 12 |
> > the log summary. this might be useful to fix -- i'll poke Zac about it |
| 13 |
> > if he doesn't see this e- mail. |
| 14 |
> > |
| 15 |
> > otherwise, your statement is really way too zen to get anything |
| 16 |
> > meaningful out of it. post actual examples of what you're talking |
| 17 |
> > about. |
| 18 |
> |
| 19 |
> Attached you will find a build.log of trying to build cdrtools on |
| 20 |
> sparc-solaris prefix. Admittedly a bit exotic, but far from unique |
| 21 |
> incident. |
| 22 |
> |
| 23 |
> A moderately knowledgeable user would notice that something is wrong |
| 24 |
> from watching the build output for a couple of seconds. Portage however |
| 25 |
> proceeds happily because make returns exit status 0. |
| 26 |
|
| 27 |
portage would always proceed. the only thing that would stop it is the user |
| 28 |
hitting CTRL+C. and that requires the user actually be watching the build |
| 29 |
output. perhaps they would be for a single package, but for general upgrades, |
| 30 |
i doubt you can rely on that. what would be more likely is they try to run |
| 31 |
`cdrecord`, find it missing, find the build failed, and then file a bug. that |
| 32 |
workflow really isn't affected by the defaults here. |
| 33 |
-mike |
Archives