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 |