After upgrading from portage-2.2_rc11 to _rc12 emerge -vup world gives: !!! Problems have been detected with your world file !!! Please run emaint --check world !!! Ebuilds for the following packages are either all !!! masked or don't exist: virtual/baselayout #---------------------------------------------- emaint --check world does not fix it and the message persists. I have nothing that depends on virtual/baselayout Downgrading to portage-2.2_rc11 fixes the problem. Reproducible: Always Steps to Reproduce: 1. emerge portage 2. emerge -vup world 3.
Created attachment 168030 [details] emerge info My emerge --info output, in case is needed
FWIW, virtual/baselayout is normally part of system, with the default package to fill the virtual normally being sys-apps/baselayout on most profiles, so is required even if it's not in the world file (and it shouldn't be in world). I had some (different, due to customization) issues with virtuals here after upgrading to -rc12, but I thought it was my customization and handled them a different way. Apparently, it wasn't my customization, but portage, thus this bug. It's also possible (but unlikely) that if you've upgraded to baselayout-2.0/openrc (as I have), that might affect things. But I think it's portage.
(In reply to comment #2) Thanks for the info re. virtual/baselayout. I have no portage customizations and I confirm that I have openrc installed. It must caused by something in -rc12 since the problem disappears when I go back to -rc11.
You shouldn't have any references to virtual/baselayout anymore. If you still do, the reference must be somewhere in your local configuration. Once you find it, you should remove it. You might be able to find it with this command: grep -r virtual/baselayout /etc/portage /var/lib/portage/world
(In reply to comment #4) > You shouldn't have any references to virtual/baselayout anymore. If you still > do, the reference must be somewhere in your local configuration. I looked for this and I find no reference to "virtual/baselayout" anywhere in my system (/varlib/portage/ /etc/portage/) Any other suggestions? And in any case, what is the difference between -rc11 and -rc12 that causes this warning to suddenly appear? Thanks
(In reply to comment #5) > Any other suggestions? No suggestions yet. I'll check the code and see if I can figure out why you'd get the warning even though it's something that emaint doesn't fix. > And in any case, what is the difference between -rc11 and -rc12 that causes > this warning to suddenly appear? It's might be related to this commit: http://sources.gentoo.org/viewcvs.py/portage?view=rev&rev=11622 Anyway, the virtual/baselayout atom must be coming from somewhere, and we need to track that down so that you can remove it. The only bug on the portage side is that the solution suggested by the error message doesn't solve the problem.
(In reply to comment #6) > It's might be related to this commit: > > http://sources.gentoo.org/viewcvs.py/portage?view=rev&rev=11622 I can confirm that commit as what affected my customized config. I've a single computer config, so don't need ssh, even tho it's in system. Similarly with an mta. Back some time ago I used /etc/portage/profile/virtuals to point virtual/ssh and virtual/mta at sys-apps/baselayout, something that /was/ installed, so the stupid system dependencies I didn't need would be filled and I'd not have to have on my system (and continue updating unnecessarily as well, Gentoo's a great motivator for keeping off the unnecessary stuff =:^) However, since baselayout didn't actually /provide/ them (despite what virtuals said), after this patch, they wanted to install again. This time I solved it properly, using a "-*" entry in profile/packages (which I don't think I knew about back when I did the virtuals thing) instead of faking it with profile/virtuals. So I'm now using the correct method and it works like it's supposed to here. But I've something else that may or may not be related. So I'll see how this plays out and then bug the other if it continues after that. (FWIW, --depclean is spitting out a strange message relating to kde-4 packages, so it could be any of several things at this point. But it's not hurting anything so I'll just wait until both KDE and portage settle down a bit, for now.)
I tried the following: -- In portage tree I symlinked virtual/baselayout --> sys-apps/baselayout It didn't work. I greped the whole portage tree for refrerences to virtual/baselayout hopping to find any depends in packages I have installed. I found nothing. I hope this helps.
In svn r11691 it's fixed so that it won't suggest to run `emaint --check world` when it's not appropriate. However, I'd still like to add some more code to find out which set the atom really came from. (In reply to comment #8) > I found nothing. It must be coming from a set that's nested inside the world set. What is the content of /var/lib/portage/world_sets?
(In reply to comment #9) > It must be coming from a set that's nested inside the world set. What is the > content of /var/lib/portage/world_sets? > @system
If @system is the only set that you've got nested in world then the virtual/baselayout must either come from a "packages" file that's inherited via /etc/make.profile or else /etc/portage/profile/packages.
(In reply to comment #11) > virtual/baselayout must either come from a "packages" file that's inherited via > /etc/make.profile or else /etc/portage/profile/packages. > Thank you for your last remark for it served as a pointer to the cause of this problem. (entirely my fault) Here it goes. About a year ago I had transfered the portage tree to a central server. From there several workstations mounted the portage tree via nfs. Everything was set up correctly but I had overlooked the link /etc/make.profile still pointing to the old location: /usr/portage/profiles/default-linux/x86/20007.0, instead of the one in the nfs mounted tree. Thus the profiles progressively became older and older until portage complained. I fixed the link and everything is working correctly. Than you very much for your help, and please accept my apologies for troubling you with something entirely my mistake. Keep up the good work.
This is fixed in 2.2_rc13. I still intend to add additional code for troubleshooting set problems but at least now it won't tell you to run emaint --check world when it's not appropriate.
