Re: [gentoo-amd64] Re: Some weird issues with portage

[Tonko Mulder]

Op donderdag 20-11-2008 om 13:08 uur [tijdzone +0000], schreef Duncan:
> "Tonko Mulder" <tonko.mulder@×××××.com> posted
> 43ba12950811200057t7d6ad5fehbe03184c6f56b006@××××××××××.com, excerpted
> below, on  Thu, 20 Nov 2008 08:57:17 +0000:
>
> >> This looks very strange to me.  Empty shared-object libs?
> >>
> >> FWIW, I have gmime-2.2.23 (only, no 2.4.x) merged here, with USE=-mono,
> >> and equery b libemeraldengine.so returns nothing, so those
> >> libemeraldengine.so* files must be mono related.
> >>
> > It's not just pan/gmime, it's for every ebuild. I now also get 'compiler
> > cannot create executable' and I forgot what the solution for that was.
>
> Now /that/ might explain the empty *.so* libs as well.  If it can't
> create executables, it likely can't properly create libraries either.
> That might have been when it started, right there.
>
> If you're getting compiler can't create executables on top of the other
> thing, it could mean whatever was the problem has caused other problems
> and your systems getting more and more screwed up.  Tread carefully, or
> you may end up having to reinstall from a stage tarball and effectively
> start over (but without having to repartition and all that, starting from
> the stage tarball).
>
> If you've been using FEATURES=buildpkg, you probably have a working gcc
> package you and remerge over top of the old one, to fix gcc if it becomes
> necessary.  If not, you can unpack a stage tarball into a testing area,
> chroot into it, quickpkg up the gcc version that's there thus creating a
> binary package, then back outside the chroot again, emerge -K the binary
> package you created.  That's the usual emergency procedure to restore a
> working gcc.  Of course, that gcc will be the one from the stage tarball,
> and you'll have to use it to remerge a normal system gcc with your own
> USE flags, etc.
>
I emerged gcc with the -k option and all seems to be well. 
My world file was also empty, but using regenworld that's kinda back to
it's old self.
Portage seems to install everything fine, there some quircks from trying
to install compix-fusion. But I'll try that later.

> If portage or python (which portage needs to work) is screwed, the
> emergency procedure for replacing it starts the same way (unpack a stage
> tarball, chroot into it, use quickpkg to create a binpkg of whatever you
> need), but once out of the chroot, you have to do something different as
> the portage you'd merge the binpkg with is broken.  In that case, first
> backup config files such as make.conf that the package will include and
> thus will overwrite if you use this procedure, then untar the binary
> package (which is a tar.bz2 with some extra data glued on the end) to /,
> directly over top of your working system.  That should get you a working
> portage or python or whatever again, but as I said, any config files that
> the package would have normally updated will be directly overwritten with
> the default versions.  Thus the backups, which you can now restore over
> the default versions.  Of course, if the brokenness was in your config
> files, that will break it again, but you'll already have the package
> available to untar over / again, and you'll /know/ it's in the config the
> second time around and can be more careful restoring your backup config.
> At this point you should be working again, but since you bypassed
> portage, its idea of what's installed will be out of sync with what's
> really installed.  Thus, you'll need to remerge a working package once
> again to get portage back in sync, and you may have a few stale files to
> cleanup by hand as well, if the filenames changed or the packages
> otherwise didn't install exactly the same files.  Still, that's better
> than having to start from the stage tarball and reinstall
> /everything/.
>
> > I don't see that path in my emerge --info, but FYI the full path is
> > ~/dev/repo/portage and it's my git based portage tree (testing) by
> > Daniel Robbins.
>
> "Oh, well, carry on then." =;^)
>
> FWIW I saw it in your login prompt, but missed the ~ at the beginning,
> which makes /all/ the difference.  Now that you've explained it, pointing
> out my /small/ oversight which wasn't so small after all =:^(, it makes
> perfect sense.  So, um... yeah... carry on!  Don't mind me!  Nothing to
> see here!  =;^)
>