app-crypt/truecrypt-4.3a ebuild was marked as testing on amd64 and x86 probably by mistake since it was in stable for a long time before. Changelog for this change is saying just "Version bump (bug #245322).". No mention of moving 4.3a from stable to testing. Please mark version 4.3a as stable again.
It was intentional. app-crypt/truecrypt will never be marked stable due to its license, RESTRICT and the fact that upstream doesn't provide older tarballs for download after releasing a new version.
Sorry for reopening. I see there are licence issues, however I believe this should not be the reason for moving already stable ebuild to testing (also it should not prevent stabilizing future versions). Quoting from comment #20 in bug #241650 (https://bugs.gentoo.org/show_bug.cgi?id=241650#c20) "per the Trustees meeting of May 17th, 2009, you're free to include the ebuild, however it should have RESTRICT="mirror fetch bindist" as well as an ewarn in the ebuild that the user must accept the license and should be aware of the distribution restrictions from upstream." There is no mention of keeping ebuilds in testing forever. Same for RESTRICT. Values in RESTRICT does their job pretty well. Thanks to them user knows that package has to be downloaded manually and that binary can not be distributed. So I see no reason to force testing keyword here. Upstream does provide older tarballs on http://www.truecrypt.org/pastversions. However not forever (for Linux the 5.1a and 6.1a are currently available). Unfortunatelly 4.3a is not already there but we must admit that gentoo is way too behind with stabilizing truecrypt and 4.3a is pretty old (no offence to anybody, we all could help :-) ). If however you believe that RESTRICT and ewarn is not enough to get user attention then hard mask the ebuild and explain the reasons in package.mask file but keep it in stable. This has several advantages: - Users will see the reasons for hard mask when trying to emerge it. They can decide then to unmask it after proper consideration. - Stable users does not loose quality of the ebuilds. Ebuilds (although hard masked) will still be processed in normal testing -> stable procedure so stable users gets properly tested and stabilized ebuilds. In opposite for keeping in testing forever: - Users will not know the reason for keeping in testing. They will wonder why we still testing that well tested ebuild and file stabilization bugs for nothing. - Stable users are forced to use lower quality testing ebuilds.