It seems the cache entry for gcc-3.2.2-r3 is being generated incorrectly. The -r3 ebuild uses gcc-3.2.2-tls-update2.patch.bz2, but the cache entry seems to want to use gcc-3.2.2-tls-update.patch.bz2, even though this file is not referenced at all in the ebuild. When trying to merge gcc-3.2.2-r3, you will get the error: >>> No message digest entry found for file "gcc-3.2.2-tls-update.patch.bz2." !!! Most likely a temporary problem. Try 'emerge rsync' again later. !!! If you are certain of the authenticity of the file then you may type !!! the following to generate a new digest: !!! ebuild /usr/portage/category/package/package-version.ebuild digest If you edit /var/cache/edb/dep/sys-devel/gcc-3.2.2-r3 and change the reference from tls-update to tls-update2 the package will merge as expected. I'm not very familiar with how the cache is generated, but the entry in /usr/portage/metadata/cache also contains this same error. Is it correct that the /var/cache entries are generated from this? The strangest part of this issue is that it seems to occur almost randomly. Sometimes you will get this tls-update issue, other times you will have the correct cache entry and not have any problem. This appears to be a bug in portage's cache generating. Any ideas?
The SRC_URI code is completely illegal. You cannot use bash to set a portage variable.
It stays static, and last time I checked bash is used to return the variables to portage. The reason why it keeps borking, is because they did not add a new revision when they updated like I usually do, but just went and changed it. Best thing IMHO, is to remove that ebuild and add a -r4, or give preference to 3.2.3.
no big deal, -r3 is gone anyway.. this bug is moot, closing
