All the versions of the mm-sources in the portage tree are currently masked. If the new versions are going to be masked, then the last stable released should be left in portage instead of being deleted. There was no point in fixing the bug of about masking RC kernels and other unstable releases of the kernel, if the last unmasked "stable" version of the kernel is not left in portage for people to install. Reproducible: Always Steps to Reproduce: 1. emerge mm-sources 2. 3. Actual Results: Doesn't install anything due to no unmasked packages being found. Expected Results: Installed the last stable release.
I have the same problem and it is keeping me from updating ati-drivers easily: root@nemo ckdake # emerge -p mm-sources ati-drivers These are the packages that I would merge, in order: Calculating dependencies !!! all ebuilds that could satisfy "mm-sources" have been masked. !!! possible candidates are: - sys-kernel/mm-sources-2.6.6_rc1-r1 (masked by: -* keyword) - sys-kernel/mm-sources-2.6.6-r2 (masked by: -* keyword) - sys-kernel/mm-sources-2.6.6-r4 (masked by: -* keyword) - sys-kernel/mm-sources-2.6.6-r1 (masked by: -* keyword) - sys-kernel/mm-sources-2.6.6_rc3-r1 (masked by: -* keyword) - sys-kernel/mm-sources-2.6.6_rc2-r1 (masked by: -* keyword) !!! Error calculating dependencies. Please correct. (added as comment on original bug 47406 earlier)
I'm sure the answer will be something like "mm-sources are testing, you don't understand what they are and shouldn't be using them" but, FWIW, I agree with the original poster -- deleting unmasked ebuilds and leaving only -* ebuilds is wrong.
Zeek, the problem with this is that people need to relealize that mm-sources is the bleeding edge in kernel development right now. What should be marked stable for mm-sources if vastly different than for development-sources or gentoo-sources. However, the problem here was an over zelous deletion of the last reasonably stable e-build and then not unmasking the stable releases of the mm-sources drivers. Then you now have the problem with the fact that how the e-builds are being masked (that is if the 2.6.6 mm-sources don't have some serious problems that should require them to be masked for most users). If I have to alter my /etc/portage/packages.keywords to accept "~x86" for mm-sources then the bug #47406 may as well be re-opened because this defeats the purpose of marking the RC ebuils as "~x86" if we mark every e-build ~x86.
Can one of the older ebuilds for a non-rc release of mm-sources be added back in? I'm not as familiar with portage as I would like, but that seems like something that would be pretty straightforward to do. In the future, I'm happy as long as there is atleast one "stable" ebuild in portage. How about a warning in the ebuild that says "Hey! This is for development purposes only and will most likely make your computer burst into flames!"?
The e-builds don't really need any warnings though. People need to read the documents to choose which kernel they want, and I believe the handbook would steer you towards info on the different kernel sources. The thing is that some of the RC releases have been fairly broken in the past. Those breaks have been fixed before they release the final version of the kernel. What they should have been doing, as posted in a bug report elsewhere, is masking the release canidates with "~x86" while the stable releases should have been unmasked.
Not a bug, sorry.
How is it not a bug? It is a bug to bump out stable e-builds out of portage when the new ones are not yet stable.
