With portage-2.2.00.10760, when I run emerge I often see: Traceback (most recent call last): File "/opt/portage/usr/bin/emerge", line 20, in <module> retval = _emerge.emerge_main() File "/opt/portage/usr/lib/portage/pym/_emerge/__init__.py", line 9525, in emerge_main myopts, myaction, myfiles, spinner) File "/opt/portage/usr/lib/portage/pym/_emerge/__init__.py", line 8795, in action_build mydepgraph.display_problems() File "/opt/portage/usr/lib/portage/pym/_emerge/__init__.py", line 5247, in display_problems msg.append(" %s%s\n" % (colorize("INFORM", arg), ref_string)) File "/opt/portage/usr/lib/portage/pym/portage/output.py", line 304, in colorize return codes[color_key] + text + codes["reset"] TypeError: cannot concatenate 'str' and 'Atom' objects ... but this doesn't happen every time. I thought it was only when the "-p" flag was used, but even this doesn't seem consistent.
The same seems to happen on 10770 for some people. darkside thinks it is related to the file being in the world-file or not. I'm clueless on this one for now. Maybe the Portage gurus have a clue on this one.
(In reply to comment #1) > The same seems to happen on 10770 for some people. darkside thinks it is > related to the file being in the world-file or not. I'm clueless on this one > for now. Background: I wanted to add gcc:4.2 to the world file so emerge --depclean wouldn't remove it. So, I ran: emerge -av --noreplace gcc:4.2 and then I get the same traceback as comment #0. emerge -av --noreplace --color=n gcc:4.2 works and then --color=y works because gcc:4.2 is already in the world file. Not sure what this has to do with it but..there you have it. I can reproduce this traceback with regularity, so let me know if you need anything. Stuart: A valid work around is to add --color=n to default opts or to the command line.
Created attachment 158325 [details, diff] convert to str to avoid TypeError This is in trunk r10771.
Confirmed..r10785 fixes my issue.
10788 is in the tree, should be fixed now, thanks!
