On 12/08/2013 11:45 AM, piruthiviraj natarajan wrote:

On Sun, Dec 8, 2013 at 2:12 PM, Joachim Backes <joachim.backes@rhrk.uni-kl.de mailto:joachim.backes@rhrk.uni-kl.de> wrote:

Hi piruthiviraj,

seeing this on my box too:

Warning: Environment Group mate-desktop-environment does not exist.
Warning: group core does not exist.
Warning: group multimedia does not exist.
Warning: group input-methods does not exist.
Warning: group base-x does not exist.
Warning: group guest-desktop-agents does not exist.
Warning: group fonts does not exist.
Warning: group mate-desktop does not exist.
Warning: group hardware-support does not exist.
Warning: group dial-up does not exist.
Warning: group admin-tools does not exist.
Warning: group printing does not exist.
Warning: group standard does not exist.

Actually: yum-3.4.3-121.fc20.noarch

Kind regards

Joachim Backes

There is similar bug appearing since f20 alphas. But I certainly didn't have in f20 beta.

https://bugzilla.redhat.com/show_bug.cgi?id=1014202

I'm up to date with my F20 updates!

Joachim Backes

On Sun, Dec 8, 2013 at 8:07 PM, Mateusz Marzantowicz < mmarzantowicz@osdf.com.pl> wrote:

Curious, why it blew up right now, just before F20 is released. It should have happened in alpha and not now.

Workaround is to yum group mark remove <group name here> for every group on the list. What a waste of time.

Mateusz Marzantowicz

test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test

Filed an individual bug report for a fix from the devs.

https://bugzilla.redhat.com/show_bug.cgi?id=1039348

On 12 December 2013 06:35, Michael Cronenworth mike@cchtml.com wrote:

On 12/08/2013 08:37 AM, Mateusz Marzantowicz wrote:

...

Curious, why it blew up right now, just before F20 is released. It should have happened in alpha and not now.

Workaround is to yum group mark remove <group name here> for every group on the list. What a waste of time.

Whatever you do - do not run "yum group mark convert". Now one of my systems wants to install every Fedora package with "yum update".

This affects all Fedoras with yum -120. Here's the parent bug: https://bugzilla.redhat.com/show_bug.cgi?id=1014202

It looks like setting upgrade_group_objects_upgrade=0 or group_command=simple sorts that issue out. (FWIW, I went for the big-axe solution and 'yum group mark remove' all the groups yum complained about, ~ 20+ groups).

Honestly I still can't get my head around that yum-groups-as-objects change...

-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test

Adam Pribyl wrote:

There is much more problems with groups in bugzilla, it affects F19 too. You can "fix" this by using "yum mark remove <group>" on all groups you get a warning they are missing (you have to have the latest yum - so yum update yum).

You don't need to bother with this. If you read the bug link you'll find an easier solution.

rm -rf /var/lib/yum/groups

Adam Pribyl wrote:

What happens if yum downloads again the groups info? BTW: I only have two 4bytes long file in this directory, and have the same problem.

The files in the directory are created by yum and are not downloaded from a repository. Removing the files will stop yum from using the group marking code that we're seeing these warnings from. I'm not sure why some systems have these files and some do not, which is what needs more investigation, but removing them will not have any negative side effects.

On Sat, 2013-12-14 at 14:26 -0800, Adam Williamson wrote:

I managed to identify the specific change to yum which made these messages appear, and I think I know the attributes of the groups for which it appears: non-environment groups that are listed as installed in /var/lib/yum/groups/installed (also, possibly, through whatever other mechanisms yum has for listing installed groups; like everyone else, I'm having a lot of trouble grokking this yum-groups-as-objects thing), that exist in comps, but have <uservisible> set to false.

It at least appears the check that was added is being run in circumstances where it wasn't expected to run. I don't know how many (if any) other bugs there are with the logic of the check itself and the /var/lib/yum/groups/installed file and the groups-as-objects change and whatever other goddamned changes are going on here.

One further note - I'm not actually sure if the suggested 'yum group mark remove <group>' is actually a particularly good idea, here, because the groups in question really do exist and you may well 'have them installed' (for whatever value of 'having a group installed' we're using this week), they're just hidden. I don't know precisely what 'group mark remove' *does*, I need to keep reading the docs, but I don't think I'd advise it off-hand, especially since the messages, I _think_, are harmless (just annoying).

On Sat, 2013-12-14 at 16:29 -0800, Adam Williamson wrote:

OK, I think I got as far as I can with this. I was wrong about some things, above - I was reading /var/lib/yum/groups/installed wrong. It's actually rather simpler than I thought.

It was so simple I spent the rest of the day looking into the *other* bugs in this area :) I think I've finally investigated as much as I can. In the end, I think there are possibly four different bugs, many of them inter-related or similar:

https://bugzilla.redhat.com/show_bug.cgi?id=1014202 https://bugzilla.redhat.com/show_bug.cgi?id=1043207 https://bugzilla.redhat.com/show_bug.cgi?id=1043221 https://bugzilla.redhat.com/show_bug.cgi?id=1043231

All of the following is, of course, my fallible QA-monkey deduction, so I might be wrong. But I think I'm right. :)

When you ask them to install an environment group, both different functions that do 'install a group' call out to another function, and if it returns a GroupError, assume that meant the group they were called against doesn't exist. This is an unsafe assumption: for each of these, there are actually cases where getting a GroupError back means something different. This is #1014202. Due to another bug - #1043231 - you actually run into this issue any time you run 'yum groupinstall (installed_environment_group)'.

There's a similar but different bug in one of the two functions when you call it to install a package group: if you call it against an installed package group, it erroneously prints 'group (groupname) does not exist'. The *other* of the two functions doesn't have this problem. You can demonstrate this one trivially: compare the output of 'yum install @installed_group' and 'yum group install installed_group'. The first one prints the warning, the second doesn't. I wasn't able to figure out *why* the check goes wrong, but that's what's going on. This is #1043207.

The reason you often see one or more of these warnings on 'yum update' is that yum calls one of the 'install a group' functions when you run 'yum update' and prints the warnings in that case, even though I think the devs were only thinking about the case where you directly run "yum install @nonexistentgroup" when they added the warnings. I've suggested that the warnings shouldn't be printed when the 'install a group' function is being called indirectly like that: that's #1043221 . yum calls _at_groupinstall, the function that suffers from #1043207 - so if yum believes you have any groups installed, every time you run 'yum update', you get a 'group (groupname) is not installed' warning for every group that is installed.

The most complex bug is #1043231. yum tries to keep track of what package groups were installed as a result of the installation of what environment groups, but this seems to be completely broken: it winds up believing that no package group was ever installed due to the installation of an environment group. (If anyone has a /var/lib/yum/groups/environment with the word 'true' in it anywhere, let me know; it means I might be wrong about this). This is bad in itself, and it's also the ultimate reason why 'yum groupinstall (installed_environment_group)' claims the group doesn't exist: through a dull chain of events described in https://bugzilla.redhat.com/show_bug.cgi?id=1014202#c22 , the fact that no package group is considered to have been installed as a part of that environment group causes a GroupError to be raised, and as we learned earlier (if we were paying attention!), bug #1014202 means that when this happens, yum claims the group doesn't exist.

It's that simple! I'm sure James will have it all cleaned up in ten minutes on Monday morning ;)

Note that all of the above is relevant only when the F19 "Yum groups as objects" feature is active: https://fedoraproject.org/wiki/Features/YumGroupsAsObjects . This is the feature that causes /var/lib/yum/groups/installed and /var/lib/yum/groups/environment to exist at all - it's the feature whereby yum tries to keep track over time of what package and environment groups are installed, instead of only working with them on the fly when you actually run a 'group' command. One of the workarounds that people have been passing around is setting yum's 'group_command' option to 'compat', which you can do directly in /etc/yum.conf or by running 'yum-config-manager --save --setopt=group_command=compat'. All this does is make yum revert to its older behaviour and completely turn off all the 'groups as objects' stuff, which means you'll avoid all of these bugs. The 'groups as objects' stuff is better in theory than the old behaviour, but given how broken it seems to be at present, setting it to 'compat' probably isn't a bad idea.

Oh, and based on reports I've read, I'd strongly recommend against running 'yum group mark convert', as yum apparently suggests to you at times. What this is supposed to do, roughly, is "convert" a legacy system to 'groups as objects' - it tries to figure out from your installed package set and (I don't know what else, unicorn droppings?) which groups you 'have installed', and write that info out to /var/lib/yum/groups/* . However, it seems like in practice, it decides that any group from which you have even a single mandatory or default package is 'installed', and consequently, your next 'yum update' will try to pull in all the other packages from all those groups, which you probably don't want. I need to verify those reports and check if a bug's been filed, though, that's next on my list.

On Sun, 2013-12-15 at 01:10 -0800, Adam Williamson wrote:

Oh, and based on reports I've read, I'd strongly recommend against running 'yum group mark convert', as yum apparently suggests to you at times. What this is supposed to do, roughly, is "convert" a legacy system to 'groups as objects' - it tries to figure out from your installed package set and (I don't know what else, unicorn droppings?) which groups you 'have installed', and write that info out to /var/lib/yum/groups/* . However, it seems like in practice, it decides that any group from which you have even a single mandatory or default package is 'installed', and consequently, your next 'yum update' will try to pull in all the other packages from all those groups, which you probably don't want. I need to verify those reports and check if a bug's been filed, though, that's next on my list.

Tested this, confirmed it is far too aggressive on a couple of test installs, filed https://bugzilla.redhat.com/show_bug.cgi?id=1043237 . Will add commonbugs notes for F19 and F20.