| 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 |
Archives