Hello,
My RAM went bad and, in spite of my efforts to repair the damage, took several unknown pieces of my software and trashed them (the trashed packages include at least gcc).
I've tried reinstalling them without success.
I looks like I will have to rebuild my whole system. I do have backups, but not of the whole system.
The problem is that when I tried this before (I tried to setup a test environment), I bind mounted the distfiles dir and portage rejected every single one of the distfiles in the dir.
I checked the sha256/512 whirlpool sums with my then functional system and they were fine. I also tried altering the time stamps with touch to no avail. Eventually, I set up lighttpd and had the test system download from the real one.
I will not have lighttpd for my new setup.
How can I tell portage to try the distfiles that I've already got?

What do you mean by rejected? What is the error message you got?

Maybe this idea using local copy or nfs will work.

"Use nfs (network file system) to mount the /usr/portage/distfiles (or better yet /usr/portage) from one machine on the other. This means that the whole portage tree will be shared -> you only have to emerge sync on one machine too"

https://forums.gentoo.org/viewtopic-...3-start-0.html

I received no error message or warning. Portage just started redownloading all selected packages. At first I thought it was me.
I could setup the environment and then try further debugging from there. I have the space.
As for nfs, that's not the problem. The files are visible from ls.

Where your $DISTDIR is pointing to?

Portage has the option to store copies of the installed binaries in an arbitrary location, using the buildpkg and quickpkg tools. See the corresponding entries in the Gentoo handbook. This will speed up future re-installs, if stored securely away from the machine.

If the file are there, can be read, and the sums match, there shouldn't be a problem. So, I guess it's one of these three things that's failing.

I'd start by checking $DISTDIR

If the sums are not ok, I think the merge process should tell you when initiating each ebuild, if my memory serves correctly. Another possibility is that the UIDs of the new portage user is broken, you can check that with ls when chrooted in the new system. A typical ls -l $DISTDIR will output all the files as owned by user portage, group portage, and permissions like rw-rw-r-- for files and rwxrwxr-x for directories. If you see UIDs instead, the problem could be that the UIDs for the portage user and/or group differ from one install to the other.

/usr/portage/distfiles is a symlink. I did this to myself. By mounting things differently, I solved the issue.
Next time do:
instead of
Thanks