Bug 1043207 - _at_groupinstall check for 'non-existent' package groups, added by upstream commit ff5416b1532fe43c68bf51ae30751504885a501a, reports that installed groups do not exist
Summary: _at_groupinstall check for 'non-existent' package groups, added by upstream c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
: 1039348 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-14 23:33 UTC by Adam Williamson
Modified: 2014-12-22 17:38 UTC (History)
17 users (show)

Fixed In Version: yum-3.4.3-128.fc19
Clone Of:
Environment:
Last Closed: 2013-12-25 02:37:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
/var/lib/yum/groups/installed from the affected system (775 bytes, text/plain)
2013-12-14 23:35 UTC, Adam Williamson
no flags Details
output of 'yum remove @cinnamon-desktop' on affected system (3.07 KB, text/plain)
2013-12-14 23:36 UTC, Adam Williamson
no flags Details
output of 'yum group info cinnamon-desktop' on affected system (1.31 KB, text/plain)
2013-12-14 23:38 UTC, Adam Williamson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1014202 0 unspecified CLOSED Warnings about non-existent environment groups in __init__.py and cli.py assume any GroupError means the group does not ... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1043202 0 unspecified CLOSED Recently-introduced check for 'existent' groups being run too often 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1043221 0 unspecified CLOSED Non-existent group warnings from _at_groupinstall should not be printed when called via yum update 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1043231 0 unspecified CLOSED yum does not succeed in marking package groups installed with an environment group 2021-02-22 00:41:40 UTC

Internal Links: 1014202 1043202 1043221 1043231

Description Adam Williamson 2013-12-14 23:33:46 UTC
So I'm trying to dig into these "Warning: group foo does not exist." errors that people have been seeing on 'yum update' lately.

Bug #1043202 identifies the immediate change to yum which caused the messages to show up - code was added quite recently to print this warning when a check that already existed fails:

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

--- a/yum/__init__.py
+++ b/yum/__init__.py
@@ -4462,6 +4462,10 @@ much more problems).
             except yum.Errors.GroupsError:
                 self.logger.critical(_('Warning: Group %s does not exist.'), group_string)
                 continue
+        else:
+            self.logger.error(_('Warning: group %s does not exist.'),
+                              group_string)
+
         return tx_return
 
     def _at_groupupgrade(self, pattern):

But that's not the whole story. For me and other reporters, the groups that are reported as 'not existing' really do exist. On my production desktop, I'm hit by this bug with regards to the 'cinnamon-desktop' group.

The warning is meant to be printed when you do "yum install @non-existent-group". Indeed, I don't just get the warning on "yum update". I get it here too:

[root@adam yum (master)]# yum install @cinnamon-desktop
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
side                                                                                           | 2.9 kB  00:00:00     
Warning: group cinnamon-desktop does not exist.
Nothing to do
[root@adam yum (master)]# 

But cinnamon-desktop group definitely does exist. In fact, I can do 'yum remove @cinnamon-desktop' or 'yum group info cinnamon-desktop' and get apparently sensible output. 'yum group list hidden' knows the group is 'installed'.

This bug is not easily reproducible on a fresh install. If I do a fresh F20 install and do 'yum install @cinnamon-desktop' then it installs the group, just as you'd expect. If I run the command again, I don't see the bug:

[root@localhost test]# yum install @cinnamon-desktop
Loaded plugins: langpacks, refresh-packagekit
Nothing to do
[root@localhost test]# 

But I don't know what the difference is between my 'dirty' state and the clean install. It may be that if I run 'yum clean all' this would go away, but I don't particularly want to do that, as I don't have any reliable way to reproduce the bug; I want to keep my desktop 'broken' for investigative purposes.

Comment 1 Adam Williamson 2013-12-14 23:35:03 UTC
Created attachment 836852 [details]
/var/lib/yum/groups/installed from the affected system

Comment 2 Adam Williamson 2013-12-14 23:36:11 UTC
Created attachment 836853 [details]
output of 'yum remove @cinnamon-desktop' on affected system

Comment 3 Adam Williamson 2013-12-14 23:38:22 UTC
Created attachment 836854 [details]
output of 'yum group info cinnamon-desktop' on affected system

Comment 4 Adam Williamson 2013-12-14 23:40:27 UTC
Oh, wait, it's much simpler than I thought. I can reproduce it on the clean test system just by updating yum - I forgot it still had yum -106.

So this bug is simply: the check introduced by http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=ff5416b1532fe43c68bf51ae30751504885a501a incorrectly fails for installed groups, and reports that they don't exist.

Comment 5 Adam Williamson 2013-12-14 23:51:22 UTC
Beleaguered plea, while I try and figure out what's wrong with the check: can I just not read python, or are "yum install @foo" and "yum group install foo", even though they're supposed to be synonyms, implemented with entirely separate functions in two different files?! And if I'm right, er, isn't that a bit insane? Shouldn't _at_groupinstall just figure out the group name and then call installGroups, rather than re-implementing it?

Comment 6 Adam Williamson 2013-12-15 00:17:11 UTC
So if my very amateur-level python foo is right, the way this is implemented in installGroups is rather more sophisticated than the way it's implemented in _at_groupinstall. _at_groupinstall incorrectly prints its 'group does not exist' error if you call it on an installed group. installGroups does not. To my amateur eyes, though, I can't see why. The two seem to do pretty much the same thing, just in slightly different ways.

installGroups is in cli.py, lines 1902-1965, the most relevant bit looks like this:

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

            groups = []
            if pkg_grp:
                groups = self.comps.return_groups(group_string)
            for group in groups:
                group_matched = True
            
                try:
                    txmbrs = self.selectGroup(group.groupid, upgrade=upgrade)
                except yum.Errors.GroupsError:
                    self.logger.critical(_('Warning: group %s does not exist.'), group_string)
                    continue
                else:
                    pkgs_used.extend(txmbrs)

            if not group_matched:
                self.logger.error(_('Warning: group %s does not exist.'), group_string)
                continue

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

_at_groupinstall is in yum/__init__.py , lines 4440-4477, the most relevant bit is:

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

        for group in comps.return_groups(group_string):
            try:
                txmbrs = self.selectGroup(group.groupid, upgrade=upgrade)
                tx_return.extend(txmbrs)
            except yum.Errors.GroupsError:
                self.logger.critical(_('Warning: Group %s does not exist.'), group_string)
                continue
        else:
            self.logger.error(_('Warning: group %s does not exist.'),
                              group_string)

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

they're obviously not identical, but to my monkey eyes they look pretty equivalent. I might have to leave it to the experts at this point.

Comment 7 Adam Williamson 2013-12-15 00:32:21 UTC
*** Bug 1039348 has been marked as a duplicate of this bug. ***

Comment 8 Jeffrey Walton 2013-12-18 14:11:51 UTC
Me too....

Comment 9 Fedora Update System 2013-12-19 05:21:35 UTC
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

Comment 10 Leonid Podolny 2013-12-19 06:44:38 UTC
(In reply to Fedora Update System from comment #9)
> 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

It helps.

Comment 11 David 2013-12-19 11:00:14 UTC
Is this fix going to be released for Fedora 19? We are a number of people with this problem (see bug #1039348).

Comment 12 Adam Williamson 2013-12-19 17:27:38 UTC
It should do yes, I think the devs wanted to gauge the feedback from F20 before sending it out to F19 too. It does touch quite a lot of important code.

Comment 13 Adam Williamson 2013-12-19 17:31:17 UTC
James tells me it should be sent out for F19 today, thanks for being patient!

Comment 14 Fedora Update System 2013-12-19 18:41:43 UTC
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

Comment 15 Fedora Update System 2013-12-20 01:50:27 UTC
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).

Comment 16 Fedora Update System 2013-12-25 02:37:39 UTC
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.

Comment 17 Fedora Update System 2014-01-01 03:31:35 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.