I was following these instructions for installing gentoo prefix: http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-macos.xml I had EPREFIX=/gentoo and CHOST=x86_64-apple-darwin9 I got until before code listing 1.9 with no problems. But when running $ env FEATURES="-collision-protect" emerge --oneshot portage I got the traceback below: Traceback (most recent call last): File "/gentoo/usr/bin/emerge", line 37, in <module> from _emerge.main import emerge_main File "/gentoo/usr/lib/portage/pym/_emerge/main.py", line 17, in <module> import portage File "/gentoo/usr/lib/portage/pym/portage/__init__.py", line 8782, in <module> from portage.dbapi.vartree import vardbapi, vartree, dblink File "/gentoo/usr/lib/portage/pym/portage/dbapi/vartree.py", line 29, in <module> from portage.data import portage_gid, portage_uid, secpass File "/gentoo/usr/lib/portage/pym/portage/data.py", line 91, in <module> writemsg("\n") File "/gentoo/usr/lib/portage/pym/portage/proxy/objectproxy.py", line 31, in __call__ result = object.__getattribute__(self, '_get_target')() File "/gentoo/usr/lib/portage/pym/portage/proxy/lazyimport.py", line 110, in _get_target _unregister_module_proxy(name) File "/gentoo/usr/lib/portage/pym/portage/proxy/lazyimport.py", line 61, in _unregister_module_proxy object.__getattribute__(proxy, '_get_target')() File "/gentoo/usr/lib/portage/pym/portage/proxy/lazyimport.py", line 106, in _get_target target = getattr(sys.modules[name], attr_name) AttributeError: 'module' object has no attribute 'userpriv_groups' Then I decided to restart the whole process from scratch. I did "rm -rf /gentoo" then did the bootstrap, which seemed OK. However, when running "emerge" I got the same traceback as above. However this time it happened much earlier, i.e., at code listing 1.5 right after the bootstrap (which worked before).
Actually I've just solved the mystery (but not the underlying problem). The traceback is a red herring. The actual problem is a at pym/portage/data.py:85: portage_gid=grp.getgrnam(portagegroup)[2] portagegroup is '5000' in my case, when I'm connected to the LDAP network in the company, then this group has a name, and this line works, when I'm not connected to the intranet then this group does not have a name, and so calling grp.getgrnam('5000') raises a KeyError. The traceback happens at 'write("\n")' in the exception handling code, which does not print anything and fail. This explains why it worked the first time. I started the process at work and executed code listing 1.9 at home, which then failed!
Ok, yea. Not such an easy bug to fix since portage hardcodes the UID/GID.
So, what I noticed is that portage harcodes the name of the user and the name of the group. And at runtime it tries to get the UIDs / GIDs from the names, that's where it fails. If I install portage at work (or using the VPN), then the hardcoded group name is the actual group name. If I install portage at home, then the hardcoded group name is the string of the group id, that is, `str(portage_gid)`. In the later case it fails right away. If portage tried to hardcode the UIDs and GIDs too, then it would solve it. An additional fault tolerance measure could be added by doing: try: portage_gid = int(portagegroup) except ValueError: # do other tries. This would solve the case when the name of the group is the UID itself (if portage was last installed at home). I don't know why it stores the name of the group if what portage ultimately wants is the group id...
Portage needs those to be able to detect in certain cases if you're root or not. Your situation is ultimately strange, to say the least, and I doubt we can do much to help you to get Portage resistant against it.
But why can't you store the group id too, along with the group name? I don't see "portagegroup" being used anywhere else other than the place where it crashes. It can't be so uncommon too. A lot of users have macs connected to an ldap network.
IMHO, portage better should store user- and group-id's only indeed and query their names at runtime for display only. It is fine to accept names as user input (cmdline), but these should be converted to the numeric ids asap. Much like the filesystem does (ls -l, chown, chgrp).
I do't recall off the top of my head, but it some places it needed the name, but the code may have changed. I thought it was something with install not coping with ids but only names.
I think that storing only the ID and computing the name when (if) needed may be even better. If converting the ID to a name fails for some reason, then portage can use str(id) as a fallback, which is what linux does in general.
let's face it, it's unlikely this will get fixed
