emerge needs a line explicitly instructing the user to look above the first instance of "ERROR:" for reporting a problem. New users always assume the highlighted red * section reported after the word "ERROR" as relevant to resolving emerge errors, even though portage says "post the topmost build error" It would greatly help if different colours could be used to move the emphasis to where the probable error is (please see the forum thread URL) Reproducible: Always Steps to Reproduce: Do something ridiculous to create an emerge package compile error =D Actual Results: n00b unfriendly error message Expected Results: Intuitive suggestion to scroll up to first instance of the word "error" on terminal, and to post output from there on for support. ,%%%, ,%%%` % ,%%`( '| ,%%@ /\_/ ,%.-"""--%%% " \___ %%/ |__\ .%'\ | \ / // ,%' > .'----\ | [/ < <<` || `\\\ || )\\ )\ ^^"""^^^^^^""^^^^^^^^^
What the fsck is with the horse? Was that really necessary?
I didn't mean it as an offensive/bloat signature or something ...just thought the horse was quite nice and it would brighten someone's day, heh
Doesn't work for several reasons: a) not every error is labeled with "error" b) most people who don't understand "post the topmost build error" aren't going to actually read the new message anyway, after all, I rarely/never see anyone asking what the "topmost build error" is, so I doubt that it's going to change much to explain it in the error message c) colorization would be the job of the build system (e.g. Makefile), not the package manager (bug #43046, and also see point a) d) instead of trying to include a "error reporting howto" in one or two sentences I'd rather just link to a real howto that can explain these things in more details
>> I'd rather just link to a real howto that can explain these things >> in more details Agreed. I've created one such page on the gentoo-wiki that could do the job: http://gentoo-wiki.com/FAQ_Troubleshooting_Emerge_Errors Somewhere down the line I hope it can be included in portage ^_^ >> c) colorization would be the job of the build system >> (e.g. Makefile), not the package manager (bug #43046, >> and also see point a) >> a) not every error is labeled with "error" Ok, then instead of messing with compiler output colors, we can still provide a more intuitive, meaningful error *summary* (in addition to the call stack) by parsing the error log file, as SLBMEH suggests in the discussion thread (URL linked above) Like you said in point a) it will be a little tricky - it's not an instant fix - so a reliable if-else/case structure would have to be developed to summarize the key error data. Btw I'm not dismissing the idea of bug #43046, I think it will help a little too. >> b) most people who don't understand "post the topmost build error" >> aren't going to actually read the new message anyway, after all, >> I rarely/never see anyone asking what the "topmost build error" >> is, so I doubt that it's going to change much to explain it in >> the error message That's no longer a problem if an error summary is created. Of course a summary is more trouble that colorization... but it would make errors more uniquely identifiable. It would be easier for us as users (and perhaps also developers) to understand what the error means straight off instead of going back and forth.
(In reply to Marius Mauch (RETIRED) from comment #3) > Doesn't work for several reasons: > a) not every error is labeled with "error" > b) most people who don't understand "post the topmost build error" aren't > going to actually read the new message anyway, after all, I rarely/never see > anyone asking what the "topmost build error" is, so I doubt that it's going > to change much to explain it in the error message > c) colorization would be the job of the build system (e.g. Makefile), not > the package manager (bug #43046, and also see point a) Agreed to close this. Additionally, the ERROR output advises posting the build log for support- I don't remember if this was the case in 2008, but in any case I think message improvements have made this suggestion less relevant and obsolete. > d) instead of trying to include a "error reporting howto" in one or two > sentences I'd rather just link to a real howto that can explain these things > in more details It appears this would be the howto on the new wiki: https://wiki.gentoo.org/wiki/Troubleshooting
