Well, let's stop and think for a moment.

That message is misleading and probably means that portage can't find the binary package. "-K" forces the usage of binary packages, so, if no binary package can be found, it fails. Admittedly the error message is a bit weird.

So, please, do this:

Note down the exact version of the package that portage is trying to emerge, then go to tinderbox and download the same exact version. After that, put it in /usr/portage/packages/sys-apps/ (sys-apps is the portage category where the package "portage" lives). If you have adjusted PKGDIR in your make.conf, then adjust this path accordingly.

After this, the emerge -K command should work.

You could untar them, but I only advice that if portage is broken beyong repair. If emerge is working we should use it instead of randomly throwing files into the fs.

Also, if you need clarification in some step, please, just ask and I'll try to explain more clearly.

shows the requested version is 2.2.7 and that corresponds to the one I'm trying to install.


Anyway. I copied the tbz archive to /usr/portage/packages/sys-apps and now it is there

I've also adjusted the /etc/make/conf PKGBUILD so portage finds the packages

But. If I emerge -K, it fails again:

Just a side note: I notice, there's a subdir under /usr/portage/packages, named "portage" with some ebuilds in it. Just a shoot: Maybe putting the tbz file there will help emerge find it?

Setting PKGDIR is not needed if you are using the default /usr/portage/packages.

Make sure you don't have a duplicated make.conf, both /etc/portage/make.conf and /etc/make.conf are valid. So, double check that.

Besides that, I'd start afresh, and do this:

If that doesn't tell you that it wants to install from binary repo (or fails at all) then something is screwed.

If your package tells you that it's masked because of CHOST, edit /usr/portage/packages/Packages (it's just a plain text file), look for the package "portage", and then for the CHOST line, then change from i486 to i686, and repeat the emerge command.

For this concrete package, this should be fine.

I don't know if it's important, but I've jus realized my portage tree lays directly under /usr/portage, so I adjusted the make.conf accordingly.

Is that correct?

I got rid of /etc/portage/make.conf just at start, so It's not duplicated.
I also noted if it's the case, emerge will notify the user when issuing any command.

Summing up: You want me to remove the whole portage tree under /usr/portage, make a new category-dir and emerge the binary file. Right?

No!

I want you to remove the contents of /usr/portage/packages/

I posted that as fast as I could to avoid a little disaster (nothing compared to the rest though). There's no need to wipe portage. And there's no need for you to put that in make.conf either. As I said, if you are using the defaults, you don't need to put them explicitly in make.conf.

/usr/portage is the default for $PORTDIR, so no need to add it.
Same goes for /usr/portage/packages for $PKGDIR and /usr/portage/distfiles for $DISTDIR.

Please, remove the contents of /usr/portage/packages, then proceed as I told you in the post above, and see if that helps at all

Sorry. I was close to the disaster once again.
Now, I've just adjusted PKGDIR to the default value but it seems there is no directory named packages under /usr/portage.

Under /usr/portage lays my whole "tree".
I hope I'm not missing anything obvious.

No, just create it if it doesn't exist. I have no idea if it comes by default in the standard portage tree.

Maybe it's created the first time you use quickpkg, or when you emerge a package with FEATURES="buildpkg" (or "buildsyspkg").

But you can just create it manually. Just to be sure you can do this and see where it's pointing by default.

OK. Just followed your instructions.
At first emerge would complain about the CHOST, but after changing it in Packages file it went fine (what is that file about BTW?).

Now portage shouts about python.

So I guess, I'll have to download it as binary and emerge in the same way prior to repairing portage.

You can try that. If something fails I can provide native i686 binaries. As long as they don't conflict with my installation.

As for your question, well, I admittedly no speciallist in how Gentoo handles bins, I rarelly needed that, but it seems to register some aspects on how the binaries residing there were compiled. Note that, unlike ebuilds, binary build do have an specific arch, chost, cflags, uses, etc.

Following your strategy I've made it to emerge portage

At first python needed sqlite so I created the right directory under /usr/portage/packages, download sqlite it and emerged. After emerging sqlite, I did the same with python and eventually, portage. All of this required manual changing chost entry in the updating Packages file.

So far so good. Seems to be good strategy to follow with the rest, right?
Hopefully. There won't be many deps to download and install.

Some packages might pose a probles, for example glibc and gcc. If you need to reinstall those let me know. don't install those from tinderbox.

in the previous post, you told me to recover: Portage and python are already ahead. I can start with binutils, coreutils,sanbox,libtool and repair glibc and gcc at the end. What do you think?

Yes, but that was before knowing that the packages in tinderbox differ from your chost.

You should use bin packages only to restore your system to a point where portage can do its job.

So, if you can already emerge packages there's no need to continue that path. Just to test, can portage re-emerge itself now?

Yes, it can . So, is the system in working-stage now?