- 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.
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
It still happens on Fedora-20-Beta-TC3-x86_64-netinstall.iso
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
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
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
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
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.
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.
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
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 #
*** Bug 1040753 has been marked as a duplicate of this bug. ***
*** Bug 1039348 has been marked as a duplicate of this bug. ***
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
$ 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
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.
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
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.
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.
Filed the case I think I have pinned down as https://bugzilla.redhat.com/show_bug.cgi?id=1043202 .
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.
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.
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".
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.
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'.
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.
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.
Haven't figured it out yet, but that code was touched in April:
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_.
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.
you just yum clean all and then go to yum update again that's work for me
(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.
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
(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.
(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
(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
*** Bug 1044632 has been marked as a duplicate of this bug. ***
yum-3.4.3-127.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/yum-3.4.3-127.fc20
$ root yum update Loaded plugins: langpacks, refresh-packagekit, verify adobe-linux-x86_64 | 951 B 00:00 google-chrome | 951 B 00:00 google-earth | 951 B 00:00 google-musicmanager | 951 B 00:00 google-talkplugin | 951 B 00:00 livna | 1.3 kB 00:00 rpm-sphere | 1.6 kB 00:00 rpmfusion-free-updates | 3.3 kB 00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00 updates/19/x86_64/metalink | 9.0 kB 00:00 updates | 4.7 kB 00:00 (1/2): rpm-sphere/primary | 1.4 MB 00:04 (2/2): updates/19/x86_64/primary_db | 9.9 MB 00:05 (1/3): google-chrome/primary | 1.9 kB 00:00 (2/3): updates/19/x86_64/updateinfo | 904 kB 00:00 (3/3): updates/19/x86_64/pkgtags | 748 kB 00:01 google-chrome 3/3 rpm-sphere 7344/7344 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. Resolving Dependencies --> Running transaction check ---> Package yum.noarch 0:3.4.3-120.fc19 will be updated ---> Package yum.noarch 0:3.4.3-122.fc19 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: yum noarch 3.4.3-122.fc19 updates 1.2 M Transaction Summary ================================================================================ Upgrade 1 Package Total download size: 1.2 M Is this ok [y/d/N]: y Downloading packages: Not downloading deltainfo for updates, MD is 1.9 M and rpms are 1.2 M yum-3.4.3-122.fc19.noarch.rpm | 1.2 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : yum-3.4.3-122.fc19.noarch 1/2 Cleanup : yum-3.4.3-120.fc19.noarch 2/2 Verifying : yum-3.4.3-122.fc19.noarch 1/2 Verifying : yum-3.4.3-120.fc19.noarch 2/2 Updated: yum.noarch 0:3.4.3-122.fc19 Complete! $ 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 Same thing.
Note the fixed update http://koji.fedoraproject.org/koji/buildinfo?buildID=485831 has not yet been pushed to updates-testing repo of f20. Either download it from koji and update it or wait till it appears in the repo.
Rick: you need -127 to get the fix, -122 was still broken. The update only went out for F20 at first, but it will go out for F19 today. Thanks for being patient!
yum-3.4.3-127.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/yum-3.4.3-127.fc19
Package yum-3.4.3-127.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing yum-3.4.3-127.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23627/yum-3.4.3-127.fc20 then log in and leave karma (feedback).
yum-3.4.3-128.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
yum-3.4.3-128.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.