Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 248814 - Portage Upgrade from 2.1.4.4 to 2.1.4.5 removed emerge from system
Summary: Portage Upgrade from 2.1.4.4 to 2.1.4.5 removed emerge from system
Status: RESOLVED OBSOLETE
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-25 19:05 UTC by Dan Farrell
Modified: 2015-06-11 21:03 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Farrell 2008-11-25 19:05:29 UTC
After emerging  sys-apps/portage-2.1.4.5 today I found that I could no longer emerge.  whereis says: 
   dan@pascal /usr/bin $ whereis emerge
   emerge:
I don't have it.  

However, I already have it installed on another box... what happened?  

Reproducible: Didn't try

Steps to Reproduce:
I can't reproduce it because I no longer have the emerge program.  Not sure what I'm going to do about this ...
Comment 1 Dan Farrell 2008-11-26 04:23:54 UTC
i know this sounds crazy, but all I did was emerge --snyc - once from an online source, then again from a local rsync repository I was configuring.  There was an update to portage, and you know how ominous those warnings are, so as a matter of habit I ran an emerge -av portage, which completed successfully.  Afterwords, I tried an emerge -pv world - and no emerge.

I assure you this is a run of the mill system too, and I am an experienced Gentooer - since '02, so this wreaks to me of the dreaded ebuild slip-up.  Maybe some bad luck with the sync tyming?  or an Isolated incident?
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-26 20:40:43 UTC
I would have asked for your `emerge --info', but never mind. :)
Please consult /var/log/emerge.log and tell us what version of sys-apps/portage you upgraded *from*.
Comment 3 Zac Medico gentoo-dev 2008-11-26 21:59:49 UTC
You can recover by following these instructions:

http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml
Comment 4 Dan Farrell 2008-11-26 23:43:18 UTC
I will double check but am pretty sure it was 2.1.4.4, the previous amd64 stable.  
Comment 5 Dan Farrell 2008-11-28 05:57:59 UTC
Yep, from 2.1.4.4.  I last updated in February.  

The system is outdated, but I am still concerned as how this could happen.  Any 
other steps for investigation?

Personally, looks like I'm writing it off as a blip.  
Comment 6 Dan Farrell 2008-11-28 06:07:01 UTC
(In reply to comment #3)
> You can recover by following these instructions:
> 
> http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml
> 

I did that, and checked my work too - but no dice Output at end. Can you provide a suggestion? I could also untar a stage3 (perhaps even selectively) and restore /var files, if necessary... it's about time to rebuild most of the packages anyway.  But I'm so curious as to what might have happened...

`emerge` :

Traceback (most recent call last):
  File "/usr/bin/emerge", line 4049, in ?
    emerge_main()
  File "/usr/bin/emerge", line 3768, in emerge_main
    settings, trees, mtimedb = load_emerge_config()
  File "/usr/bin/emerge", line 3679, in load_emerge_config
    trees = portage.create_trees(trees=trees, **kwargs)
  File "/usr/lib/portage/pym/portage.py", line 6771, in create_trees
    config_incrementals=portage_const.INCREMENTALS)
  File "/usr/lib/portage/pym/portage.py", line 921, in __init__
    addProfile(os.path.realpath(self.profile_path))
  File "/usr/lib/portage/pym/portage.py", line 908, in addProfile
    raise portage_exception.ParseError(
NameError: global name 'parents_file' is not defined
Comment 7 Zac Medico gentoo-dev 2008-11-28 08:47:53 UTC
(In reply to comment #6)
>   File "/usr/lib/portage/pym/portage.py", line 908, in addProfile
>     raise portage_exception.ParseError(
> NameError: global name 'parents_file' is not defined

That's a bug in portage-2.1.4, but it's only triggered if your profile contains an empty 'parent' file, which isn't normal. Try using `eselect profile` to make sure /etc/make.profile is a symlink pointing to a valid profile. There are some instructions here:

  http://www.gentoo.org/doc/en/gentoo-upgrading.xml#doc_chap3
Comment 8 Dan Farrell 2008-11-29 18:45:55 UTC
(In reply to comment #7)
> (In reply to comment #6)
> >   File "/usr/lib/portage/pym/portage.py", line 908, in addProfile
> >     raise portage_exception.ParseError(
> > NameError: global name 'parents_file' is not defined
> 
> That's a bug in portage-2.1.4, but it's only triggered if your profile contains
> an empty 'parent' file, which isn't normal. Try using `eselect profile` to make
> sure /etc/make.profile is a symlink pointing to a valid profile. There are some
> instructions here:
> 
>   http://www.gentoo.org/doc/en/gentoo-upgrading.xml#doc_chap3
> 

Thanks for continued support.  Let me share my results:

   dan@pascal ~ $ eselect profile show 
   Current make.profile symlink:
    /usr/portage/profiles/default/linux/amd64/2008.0 

The parent file in /etc/make.profile is the same on another computer with the same profile.  
Comment 9 Zac Medico gentoo-dev 2008-11-29 19:13:36 UTC
In order to avoid the bug which triggers the traceback shown in comment #6, you can repeat the "Manually fixing broken portage installations" procedure with a different tarball. I'd suggest portage-2.1.6_rc1.tar.bz2 since that's probably easier than applying the portage-2.1.4.5 patch.
Comment 10 Christian Affolter 2009-06-24 15:34:50 UTC
To solve the "NameError: global name 'parents_file' is not defined" situation, proceed with the following steps:

profileSymlinkTarget=`readlink /etc/make.profile`
rm /etc/make.profile
ARCH="x86" ACCEPT_KEYWORDS="x86" emerge portage --nodeps
ln -s $profileSymlinkTarget /etc/make.profile
emerge portage -va