1 |
On Sunday 04 December 2011 23:17:55 Patrick Lauer wrote: |
2 |
> On 12/05/11 11:52, Mike Frysinger wrote: |
3 |
> > On Sunday 04 December 2011 22:42:46 Patrick Lauer wrote: |
4 |
> >> On 12/05/11 10:49, Rich Freeman wrote: |
5 |
> >>> On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer wrote: |
6 |
> >>>> And spend much more time trying to find them silly logfiles now that |
7 |
> >>>> we hide the output. I really enjoy having to fix yet another bad |
8 |
> >>>> default everywhere just so I see *why* things fail ... |
9 |
> >>> |
10 |
> >>> Unless something has changed the logfile name including full path is |
11 |
> >>> printed when there is an error. So, it is just a matter of copy/paste |
12 |
> >>> into a cat and you can watch the whole thing scroll by and even |
13 |
> >>> pretend it is compiling really fast while it is doing it. :) |
14 |
> >> |
15 |
> >> So one useless step added, which might give extra funny output because |
16 |
> >> of escaped escape sequences and such funnies, with no benefit for me |
17 |
> > |
18 |
> > uhh, no. cat on the log files works perfectly fine in any sane terminal. |
19 |
> |
20 |
> Unless the build system became extra happy ... |
21 |
|
22 |
i have no idea wtf you're talking about. i'm just going to go with "you have |
23 |
no real examples". |
24 |
|
25 |
> >>> It seems like a pretty sane default to assume that most packaged build |
26 |
> >>> without issues - after all, that is basically the goal, right? |
27 |
> >> |
28 |
> >> And for those I don't care about the output at all, but when things fail |
29 |
> >> I want to see it. |
30 |
> > |
31 |
> > it's hard to have a conversation when you don't even verify your |
32 |
> > statements. when a build fails, it outputs the entire log. thus your |
33 |
> > statement here makes no sense at all. |
34 |
> |
35 |
> Not all failures are errors, only errors are shown |
36 |
|
37 |
all failures as characterized by "ebuild called `die`" get shown -- portage |
38 |
dumps the entire log, thus your need to copy & paste the log file to `cat` is |
39 |
garbage. |
40 |
|
41 |
all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc on |
42 |
missing file) will get "missed". many of those are logged as QA warnings, but |
43 |
it seems default --quiet-build=y will not include these in the log summary. |
44 |
this might be useful to fix -- i'll poke Zac about it if he doesn't see this e- |
45 |
mail. |
46 |
|
47 |
otherwise, your statement is really way too zen to get anything meaningful out |
48 |
of it. post actual examples of what you're talking about. |
49 |
|
50 |
> So I'm still left wondering why things didn't go as planned, but at that |
51 |
> point the log has already been removed and I have to rebuild things |
52 |
> after remembering to change defaults ... not that this happened to me or |
53 |
> anything like that, just that it has happened to me twice now and I'm |
54 |
> getting tired of spending time on changing defaults that should be sane. |
55 |
|
56 |
the defaults are not aimed at developers. if you're complaining about the |
57 |
defaults in that role, then any arguments along those lines don't really |
58 |
belong here. |
59 |
|
60 |
> >> So for me the proper default is "show everything, let me ignore what I |
61 |
> >> don't want" |
62 |
> > |
63 |
> > then change your defaults |
64 |
> |
65 |
> One machine at a time I am ... one chroot at a time ... |
66 |
|
67 |
this is crap |
68 |
-mike |