Bug 1044632

+++ This bug was initially created as a clone of Bug #1014202 +++

- Installed Fedora-20-Alpha
- After the installation, I installed *all* desktop groups with

     sudo yum groupinstall lxde-desktop-environment minimal-environment mate-desktop-environment gnome-desktop-environment xfce-desktop-environment kde-desktop-environment sugar-desktop-environment developer-workstation-environment cinnamon-desktop-environment

“yum -v grouplist” still shows these groups as available:

    [mfabian@Fedora-20-Alpha-release-x86_64-n ~]$ yum -v grouplist | grep Available -A3
    Available environment groups:
       GNOME Desktop (gnome-desktop-environment)
       KDE Plasma Workspaces (kde-desktop-environment)
       Xfce Desktop (xfce-desktop-environment)
    --
    Available Groups:
       3D Printing (3d-printing)
       Authoring and Publishing (authoring-and-publishing)
       Books and Guides (books)
    [mfabian@Fedora-20-Alpha-release-x86_64-n ~]$

(That is already reported as https://bugzilla.redhat.com/show_bug.cgi?id=920055)

But now, when using “yum update”, I get warnings
that theses groups don’t exist:
    
    [mfabian@Fedora-20-Alpha-release-x86_64-n ~]$ sudo yum update
    [sudo] password for mfabian: 
    Loaded plugins: langpacks, refresh-packagekit
    Warning: Environment Group lxde-desktop-environment does not exist.
    Warning: Environment Group minimal-environment does not exist.
    Warning: Environment Group mate-desktop-environment does not exist.
    Warning: Environment Group gnome-desktop-environment does not exist.
    Warning: Environment Group xfce-desktop-environment does not exist.
    Warning: Environment Group kde-desktop-environment does not exist.
    Warning: Environment Group sugar-desktop-environment does not exist.
    Warning: Environment Group developer-workstation-environment does not exist.
    Warning: Environment Group cinnamon-desktop-environment does not exist.
    No packages marked for update
    [mfabian@Fedora-20-Alpha-release-x86_64-n ~]$ 

 I don’t remember seeing this before.

--- Additional comment from Taeyoung Kim on 2013-10-14 00:07:07 EDT ---

Same thing happened to me.

tkim@fedora ~$ sudo yum update
Loaded plugins: fastestmirror, langpacks, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: mirror.web-ster.com
 * rpmfusion-free-rawhide: mirror.web-ster.com
 * rpmfusion-nonfree-rawhide: mirror.web-ster.com
 * updates: mirror.web-ster.com
 * updates-testing: mirror.web-ster.com
Warning: Environment Group mate-desktop-environment does not exist.
Warning: Environment Group kde-desktop-environment does not exist.
Warning: Environment Group cinnamon-desktop-environment does not exist.
Warning: Environment Group xfce-desktop-environment does not exist.
Resolving Dependencies
--> Running transaction check
---> Package eclipse-wtp-common.noarch 0:3.5.0-2.fc20 will be updated
---> Package eclipse-wtp-common.noarch 0:3.5.1-1.fc20 will be an update




I don't know why it happened

--- Additional comment from Mike FABIAN on 2013-10-15 03:00:52 EDT ---

It still happens on Fedora-20-Beta-TC3-x86_64-netinstall.iso

--- Additional comment from Marcel Ribeiro Dantas on 2013-11-05 23:11:11 EST ---

It happens to me in Fedora 19.
I have Cinnamon and MATE installed. When I run `sudo yum update`, the output is:

Warning: Environment Group mate-desktop-environment does not exist.
No packages marked for update

--- Additional comment from Jalal Ahmed on 2013-11-10 17:34:11 EST ---

Me too, with Fedora 19, 64.
I have XFCE4, but I installed KDE, then I removed it, by using yum history undo X.
Since that when I do 'yum update' the output as the following:

* updates: kambing.ui.edu
Warning: Environment Group kde-desktop-environment does not exist.
No packages marked for update

--- Additional comment from Taeyoung Kim on 2013-11-10 17:41:52 EST ---

This happens when you used the traditional install method since Fedora's group install mechanism has been changed.

Refer below url

http://fedoraproject.org/wiki/Features/YumGroupsAsObjects

and if you want to remove the warning message, you can easily do the following command

su -c 'yum group mark remove "Group Object Name"' 

Thanks
TK

--- Additional comment from Jalal Ahmed on 2013-11-10 18:18:08 EST ---

Yeah, When I use
su -c 'yum group mark remove "kde-desktop-environment"
It has removed when I update the system, but if I want to install KDE, as this command:

yum groupinstall kde-desktop-environment

Warning: environment kde-desktop-environment does not exist.
No packages in any requested group available to install or update

--- Additional comment from Taeyoung Kim on 2013-11-11 01:25:48 EST ---

Try to use the following object method.

yum group mark install kde-desktop-environment
yum upgrade

It gives you install KDE 

Give it a try.

--- Additional comment from Jalal Ahmed on 2013-11-11 05:59:10 EST ---

I marked kde-desktop-environment as you type

yum group mark install kde-desktop-environment

Marked install: kde-desktop-environment
, but when I use
yum upgrade the outputs is:

Warning: Environment Group kde-desktop-environment does not exist.
No packages marked for update

Still I cannot install kde,

yum group install kde-desktop-environment

Warning: environment kde-desktop-environment does not exist.
No packages in any requested group available to install or update

But when I add "group_command=compat" to /etc/yum.conf
it works perfectly, and I can install KDE as well.

--- Additional comment from Piruthiviraj Natarajan on 2013-12-08 05:43:51 EST ---

I have this error in latest f20

 yum info yum
google-chrome                                                               3/3
Installed Packages
Name        : yum
Arch        : noarch
Version     : 3.4.3
Release     : 120.fc20

--- Additional comment from Chris Murphy on 2013-12-09 01:24:50 EST ---

Is reproducible with 3.4.3-120.fc20.x86_64 and -121, even after a yum clean all, and even after an rpm database rebuild, so I'm not sure what's going on.


# yum update
Loaded plugins: langpacks, refresh-packagekit
fedora/20/x86_64/metalink             |  20 kB  00:00:00     
fedora                                | 4.2 kB  00:00:00     
updates/20/x86_64/metalink            |  20 kB  00:00:00     
updates                               | 3.4 kB  00:00:00     
updates-testing/20/x86_64/metalink    |  20 kB  00:00:00     
updates-testing                       | 4.6 kB  00:00:00     
(1/5): updates/20/x86_64/primary_db          | 1.2 kB  00:00:00     
(2/5): updates-testing/20/x86_64/group_gz    | 394 kB  00:00:01     
(3/5): fedora/20/x86_64/group_gz             | 394 kB  00:00:01     
(4/5): updates-testing/20/x86_64/primary_db  | 2.8 MB  00:00:03     
(5/5): fedora/20/x86_64/primary_db           |  18 MB  00:00:07     
(1/2): updates-testing/20/x86_64/updateinfo  | 291 kB  00:00:01     
(2/2): updates-testing/20/x86_64/pkgtags     | 737 kB  00:00:01     
Warning: group core does not exist.
Warning: group gnome-desktop does not exist.
Warning: group multimedia does not exist.
Warning: group firefox does not exist.
Warning: group guest-desktop-agents does not exist.
Warning: group base-x does not exist.
Warning: group anaconda-tools does not exist.
Warning: group fonts does not exist.
Warning: group hardware-support does not exist.
Warning: group dial-up does not exist.
Warning: group printing does not exist.
Warning: group virtualization does not exist.
Warning: group libreoffice does not exist.
Warning: group input-methods does not exist.
Warning: group standard does not exist.
No packages marked for update
#

--- Additional comment from Michael Cronenworth on 2013-12-11 23:26:27 EST ---



--- Additional comment from Michael Cronenworth on 2013-12-11 23:28:15 EST ---



--- Additional comment from Michael Cronenworth on 2013-12-11 23:45:40 EST ---

This yum feature reads from /var/lib/yum/groups/. On systems with this directory, I get these warnings. On systems without that directory, the warnings do not appear.

This is also troubling:
$ rpm -qf /var/lib/yum/groups/
file /var/lib/yum/groups is not owned by any package

--- Additional comment from Rick Richardson on 2013-12-12 03:50:29 EST ---

$ cat /etc/issue
Fedora release 19 (Schrödinger’s Cat)
Kernel \r on an \m (\l)

$ root yum update
Loaded plugins: langpacks, refresh-packagekit, verify
Warning: group core does not exist.
Warning: group gnome-desktop does not exist.
Warning: group multimedia does not exist.
Warning: group firefox does not exist.
Warning: group guest-desktop-agents does not exist.
Warning: group base-x does not exist.
Warning: group fonts does not exist.
Warning: group hardware-support does not exist.
Warning: group dial-up does not exist.
Warning: group printing does not exist.
Warning: group input-methods does not exist.
Warning: group standard does not exist.
No packages marked for update

--- Additional comment from dmanley on 2013-12-12 07:28:18 EST ---

Fedora release 19 (Schrödinger’s Cat)
Kernel \r on an \m (\l)

Linux dmanley.wks.liquidweb.com 3.11.10-200.fc19.x86_64 #1 SMP Mon Dec 2 20:28:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

~]# yum update
Loaded plugins: langpacks, refresh-packagekit
Warning: group core does not exist.
Warning: group multimedia does not exist.
Warning: group kde-media does not exist.
Warning: group base-x does not exist.
Warning: group guest-desktop-agents does not exist.
Warning: group anaconda-tools does not exist.
Warning: group fonts does not exist.
Warning: group hardware-support does not exist.
Warning: group dial-up does not exist.
Warning: group kde-apps does not exist.
Warning: group kde-desktop does not exist.
Warning: group printing does not exist.
Warning: group standard does not exist.
Warning: group kde-telepathy does not exist.
No packages marked for update

Sounds like a change needs to be pushed to update older installs to the new group install method has changed.

--- Additional comment from niyasc on 2013-12-14 08:42:10 EST ---

I'm also getting similar error.
Installed Fedora-Live-Desktop-x86_64-20-Beta-5 and has performed all updates sofar.
Now when I use sudo yum update, I get following response

Loaded plugins: langpacks, refresh-packagekit
adobe-linux-x86_64                                                                |  951 B  00:00:00     
rpmfusion-free-rawhide                                                            | 3.3 kB  00:00:00     
rpmfusion-nonfree-rawhide                                                         | 3.3 kB  00:00:02     
updates/20/x86_64/metalink                                                        | 6.9 kB  00:00:00     
Warning: group core does not exist.
Warning: group gnome-desktop does not exist.
Warning: group multimedia does not exist.
Warning: group firefox does not exist.
Warning: group guest-desktop-agents does not exist.
Warning: group base-x does not exist.
Warning: group anaconda-tools does not exist.
Warning: group fonts does not exist.
Warning: group hardware-support does not exist.
Warning: group dial-up does not exist.
Warning: group printing does not exist.
Warning: group libreoffice does not exist.
Warning: group input-methods does not exist.
Warning: group standard does not exist.
No packages marked for update

--- Additional comment from  on 2013-12-14 10:03:49 EST ---

I get the error after I have installed all the updates apart from kdelibs and kdelibs-common, ie all the others are clean and install with no warning.

I realise that its probably not the best way to install updates, but felt I should at least find out which package(s) were giving the waning messages.

this is on a F19 x86_64 machine.

I hope this helps and it isn't too long for a fix to be found.

--- Additional comment from Adam Williamson on 2013-12-14 16:48:52 EST ---

I think there may be more than one issue here. yum's code contains rather a lot of very similar warnings:

cli.py:                self.logger.error(_('Warning: group/environment %s does not exist.'), strng)
cli.py:                    self.logger.critical(_('Warning: environment %s does not exist.'), group_string)
cli.py:                    self.logger.critical(_('Warning: group %s does not exist.'), group_string)
cli.py:                self.logger.error(_('Warning: group %s does not exist.'), group_string)
yum-cron/yum-cron.py:                        self.emitGroupError('Warning: Group %s does not exist.' % group_string)
yum-cron/yum-cron.py:                    self.emitGroupError('Warning: Group %s does not exist.' % group_string)
yum/__init__.py:                    self.logger.critical(_('Warning: Environment Group %s does not exist.'), group_string)
yum/__init__.py:                self.logger.critical(_('Warning: Group %s does not exist.'), group_string)
yum/__init__.py:            self.logger.error(_('Warning: group %s does not exist.'),
yum/__init__.py:                self.logger.critical(_('Warning: Environment Group %s does not exist.'), group_string)

they all do slightly different things in different places, even when they emit identical or almost-identical error messages.

In particular I think the case from c#10 and c#16 is probably not the same as the original bug. That is the single case I think I *can* pin down, so far. It comes from this yum change, which landed in Fedora between -106 and -120 (no updates were submitted between -106 and -119, -119 was broken, so -120 was the next stable build after -106):

http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=ff5416b1532fe43c68bf51ae30751504885a501a

"Give same non-exist msg. for install @foo as group install foo. BZ 1018833."

From that commit message it sounds like the error was supposed to be shown only if you try 'yum install @foo' when "foo" is a group that doesn't exist. But in fact that codepath appears to get hit every time you run 'yum update'.

I think the groups that don't exist are ones listed in /var/lib/yum/groups/installed , and this bug will affect systems that have been installed for a while, and have groups listed in there which have subsequently had their names changed in comps.

I will file a separate bug for this case, since I was able to pin it down quite precisely. But I think there may well be three or four bugs in this area, and it seems quite messy, because there's a whole bunch of intersections between behaviour changes in yum, the groups-as-objects thing, and whether you have an old install with stuff in /var/lib/yum/groups or not. I'm having quite a bit of trouble pinning down all the different issues people are reporting.

--- Additional comment from Adam Williamson on 2013-12-14 17:17:43 EST ---

Filed the case I think I have pinned down as https://bugzilla.redhat.com/show_bug.cgi?id=1043202 .

--- Additional comment from Adam Williamson on 2013-12-14 19:37:12 EST ---

OK, I didn't quite have it pinned down in c#19, but I think I do now =)

I believe the true bug behind the "Warning: group foo does not exist." errors is https://bugzilla.redhat.com/show_bug.cgi?id=1043207 : the check is broken for installed groups.

It looks like the checks for environment groups are broken quite similarly, in fact...but they'd still count as separate bugs, strictly speaking, I think.

--- Additional comment from Adam Williamson on 2013-12-14 19:54:25 EST ---

Okay, man, more data.

I am fairly sure that the following warnings:

cli.py line 1939, "Warning: environment %s does not exist."
yum/__init__.py line 4462, "Warning: Environment Group %s does not exist."

are both incorrectly printed if you call them on a group that exists, but is installed. To reproduce, from a clean system, try:

# yum group install basic-desktop-environment
# yum group install basic-desktop-environment
# yum install @^basic-desktop-environment

The first will install the environment group. The second will incorrectly print "Warning: environment basic-desktop-environment does not exist." - that's the cli.py warning, in the installGroups function. The third will incorrectly print "Warning: Environment Group basic-desktop-environment does not exist." - that's the __init__.py warning, in the _at_groupinstall function.

Also, when you install an environment group, all the package groups it includes are marked as 'installed' by yum. So due to the similar bug #1043207 , if you do "yum group install basic-desktop-environment" followed by "yum update", you get a whole bunch of incorrect warnings - one for the basic-desktop-environment environment group, from yum/__init__.py line 4462 , and several for the package groups on which it depends, from yum/__init__.py line 4474.

I tried to figure out _why_ we're printing these warnings for groups that exist but are installed, but can't figure it out. I'll leave that to the experts.

--- Additional comment from Adam Williamson on 2013-12-14 20:46:08 EST ---

OK, I've traced it out a bit further.

Both installGroups and _at_groupinstall call self.selectEnvironment . self.selectEnvironment, I think, figures out a list of groups in the given environment, then calls self.selectGroup with the 'grpid' parameter set to the list of groups it figured out.

Here's the interesting bit: if we call selectEnvironment on an environment group that is installed, then by the time we get to selectGroup, that list is empty.

I added a line to the very top of selectGroup:

        self.logger.critical(_('Groups: %s'), grpid)

which has the effect that, whenever selectGroup gets invoked, it'll print the list of groups it was invoked with to the console. If I do a simple groupinstall, the list is what you'd expect:

[root@adam yum (master)]# yum install @cinnamon-desktop
...
Groups: cinnamon-desktop

But if I try it on an environment group that is already installed, I get this:

[root@localhost test]# yum install @^basic-desktop-environment
...
Groups: 

If grpid is empty, selectGroup will, I think, raise Errors.GroupsError "No Group named %s exists" (which in itself is _slightly_ inaccurate, here...) almost immediately, at line 3770. And back in installGroups and _at_groupinstall , if we get a GroupsError back when we call self.selectEnvironment, we assume this means the environment group does not exist, and print a warning about it.

So now we wonder, why is selectEnvironment invoking selectGroup with grpid empty?

If I run the environment group install with -v, I see this:

Skipping group core from environment basic-desktop-environment
Skipping group multimedia from environment basic-desktop-environment
Skipping group guest-desktop-agents from environment basic-desktop-environment
Skipping group base-x from environment basic-desktop-environment
Skipping group fonts from environment basic-desktop-environment
Skipping group hardware-support from environment basic-desktop-environment
Skipping group dial-up from environment basic-desktop-environment
Skipping group basic-desktop from environment basic-desktop-environment
Skipping group standard from environment basic-desktop-environment
Groups: 

Those messages look to be coming from lines 3989-3999 of selectEnvironment:

            elif self.conf.group_command == 'objects':
                igroup_data = self._groupInstalledEnvData(evgrp)
 
                grps = []
                for grpid in evgrp.groups:
                    if (grpid not in igroup_data or
                        igroup_data[grpid].startswith('blacklisted')):
                        msg = _('Skipping group %s from environment %s')
                        self.verbose_logger.log(logginglevels.DEBUG_2,
                                                msg, grpid, evgrp.environmentid)
                        continue

Okay, so I stuck in some more debugging to get out the contents of igroup_data. All the groups that are skipped show up as 'blacklisted-installed'.

So to summarize, when you try to install an environment group that's already installed:

1. Whichever of the two 'install a group' functions you used calls selectEnvironment with that environment group name
2. selectEnvironment figures out what package groups are in that environment group
3. selectEnvironment calls _groupInstalledEnvData on the environment group, which tells it whether each package group is installed, available, blacklisted_installed or blacklisted_available. It tells selectEnvironment that all the package groups in the installed environment group are "blacklisted-installed", which seems wrong
4. selectEnvironment skips all those package groups because they're "blacklisted"
5. selectEnvironment winds up calling selectGroup with an empty 'grpid', because all package groups in the environment group were skipped
6. selectGroup raises GroupsError
7. the original 'install a group' function from step 1 catches the GroupsError and prints the "group does not exist" error message

So I think now I'm trying to figure out why groupInstalledEnvData thinks the package groups are "blacklisted-installed", not "installed".

--- Additional comment from Adam Williamson on 2013-12-14 21:10:37 EST ---

Okay, so let's stick some debugging in groupInstalledEnvData too:

--------------

            if igrp.environment == evgroup.environmentid:
                ret[grp_name] = 'installed'
                break
            else:
                ret[grp_name] = 'blacklisted-installed'
                self.logger.critical(_('igrp: %s evgroup: %s'), igrp.environment, evgroup.environmentid)

--------------

it goes through some other crap then gets down to this: if igrp.environment == evgroup.environmentid then it'll say the group is "installed", it it doesn't, it'll say it's "blacklisted-installed". The debugging tells us what those two values are.

Here's what I get - this is the 'igrp.environment' and 'evgroup.environmentid' for all the groups that it considered 'blacklisted-installed':

igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment
igrp: None evgroup: basic-desktop-environment

so this 'igrp.environment' bit looks like it's wrong. I can't yet grok exactly where that's coming from, I don't understand what:

            igrp = self.igroups.groups.get(grp_name)

does exactly.

--- Additional comment from Adam Williamson on 2013-12-14 21:29:09 EST ---

Oooh. oho. Okay. here's a fun thing. On my test system, /var/lib/yum/groups/environment looks like this:

1
1
basic-desktop-environment
22
base-x
false
basic-desktop
false
cinnamon-desktop
false
core
false
dial-up
false

etc etc etc - it's showing, I think, the environment group "basic-desktop-environment", with each package group that environment group contains (22 of them), and a 'true' or 'false' key for each package group. I can't yet quite figure out what 'true' or 'false' is supposed to indicate, but if I flip one of them to 'true', groupInstalledEnvData considers that group to be 'installed', not 'blacklisted-installed'.

--- Additional comment from Adam Williamson on 2013-12-14 22:22:04 EST ---

So, hum. Further investigation indicates there's something badly wrong with yum's tracking of what groups are 'owned' by what environment group(s).

Try this.

1. Clean minimal install of F20 from DVD
2. 'yum group list installed' and 'yum group list installed hidden' will report no groups installed
3. 'yum group install cinnamon-desktop-environment' will do what you'd expect, pulling in all the packages from the package groups in the 'cinnamon-desktop-environment' environment group
4. 'yum group info cinnamon-desktop-environment' will show 11 'Mandatory Groups', none with a '=' to indicate they were installed as part of the environment group, even though all but 'core' clearly were
5. /var/lib/yum/groups/environment lists the cinnamon-desktop-environment group with 13 package groups, each of which has its 'true/false' key set to 'false'
6. 'yum update' will confirm that this bug is now in effect; it claims 'Environment Group cinnamon-desktop-environment does not exist.' (and you'll also hit https://bugzilla.redhat.com/show_bug.cgi?id=1043207 , if you use yum -120)

So assuming that the true/false keys in /var/lib/yum/groups/environment are supposed to indicate which package groups were installed as a part of which environment groups - and that's what groupInstalledEnvData seems to be assuming - something is rotten here. I would expect all the groups except 'core' to have the key 'true', not 'false'.

Also interesting: "yum group list installed environment" returns nothing, whereas I'd expect it to return cinnamon-desktop-environment. But that's probably a separate bug.

--- Additional comment from Adam Williamson on 2013-12-14 22:55:15 EST ---

So right now I'm looking at this:

                if (grpname in self.groups and
                    self.groups[grpname].environment == evgrp.evgid):
                    fo.write("%s\n" % "true")
                else:
                    fo.write("%s\n" % "false")

from _write_grp_grps in igroups.py. I _suspect_ that condition is incorrect. I'm working on checking that now.

--- Additional comment from Adam Williamson on 2013-12-15 01:03:39 EST ---

Haven't figured it out yet, but that code was touched in April:

--- Additional comment from Adam Williamson on 2013-12-15 01:11:41 EST ---

OK, let's tidy this up a bit. I'm knee-deep in the more complex issue here, because it's probably the more important. But let's make this the bug for the superficial issue, and I'll file a new one for the deeper issue.

The superficial issue here is that the installGroups and _at_groupinstall functions assume that any time they call selectEnvironment and get a GroupError back, it means the environment group does not exist, so they print a warning message to that effect.

This assumption is incorrect. The deeper bug here means it's turning out to be incorrect more often than you'd think, but even if we fix the deeper bug, it's still incorrect. There are, I think, valid cases where you'd have an environment group installed, but no package group would be considered to have been installed "because of" that environment group, so you'd hit the same chain I identified above - selectEnvironment finds that all the package groups are 'blacklisted-installed', calls selectGroup with an empty grplist, selectGroup raises GroupError, and yum tells you the group doesn't exist when clearly it does.

I'm also going to file a bug that these warnings should never be printed when these codepaths are hit indirectly from 'yum update', because I don't think the user wants to see these warnings in 'yum update' _even if they're correct_.

--- Additional comment from Adam Williamson on 2013-12-15 03:20:56 EST ---

Filed bug #1043231 for the deeper issue of why yum never seems to write 'true' to /var/lib/yum/groups/environment . I think I have a lead, there.

--- Additional comment from sitita on 2013-12-16 10:11:18 EST ---

you just yum clean all and then go to yum update again
that's work for me

--- Additional comment from Ben Breard on 2013-12-16 17:58:03 EST ---

(In reply to sitita from comment #30)
> you just yum clean all and then go to yum update again
> that's work for me

I realize this is against f20, but I just hit this on F19 after running `yum groupinstall "KDE Plasma Workspaces"` 

Running yum clean all does nothing to fix the groups in F19.

--- Additional comment from Adam Williamson on 2013-12-16 18:00:15 EST ---

Ben: I wouldn't expect it to. I documented various workaround possibilities in the commonbugs note, though: https://fedoraproject.org/wiki/Common_F19_bugs#yum-group-errors

--- Additional comment from Ben Breard on 2013-12-17 10:51:31 EST ---

(In reply to Adam Williamson from comment #32)
> Ben: I wouldn't expect it to. I documented various workaround possibilities
> in the commonbugs note, though:
> https://fedoraproject.org/wiki/Common_F19_bugs#yum-group-errors

Adam, that worked great. Thank you.

--- Additional comment from Nicolas Karmazyn on 2013-12-17 13:19:45 EST ---

(In reply to Ben Breard from comment #33)
> (In reply to Adam Williamson from comment #32)
> > Ben: I wouldn't expect it to. I documented various workaround possibilities
> > in the commonbugs note, though:
> > https://fedoraproject.org/wiki/Common_F19_bugs#yum-group-errors
> 
> Adam, that worked great. Thank you.

Hi all,

Adam, I tried your "safest workaround", and it works fine for my F19. Thank you

--- Additional comment from Marcus Summers on 2013-12-17 18:07:08 EST ---

(In reply to Adam Williamson from comment #32)
> Ben: I wouldn't expect it to. I documented various workaround possibilities
> in the commonbugs note, though:
> https://fedoraproject.org/wiki/Common_F19_bugs#yum-group-errors

Adam, this solution worked for me as well!

+1