Red Hat Bugzilla – Bug 219336
Pirut package group tab blank in RHEL 5 beta
Last modified: 2013-01-10 05:15:33 EST
Description of problem:
When running pirut, the Browse tab is blank. It should show screens similar to
package customization during Anaconda (similar to FC6).
Version-Release number of selected component (if applicable):
Start pirut, click Browse tab
Steps to Reproduce:
1. On the GNOME desktop, click Applications -> Add/Remove Software
2. Click Browse tab
Package selection options similar to Anaconda's package customization screens.
seems related to bug 217165; e.g. if I use the FC6 fedora-core.repo file in the
/etc/yum.repos.d directory, I get full FC6 customization screens in RHEL 5 b2.
This is because RHN isn't providing the group information.
> This is because RHN isn't providing the group information.
Is that going to be fixed?
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
If we don't have package group support through RHN in RHEL5 it is a really serious
problem for Language support package configuration in RHEL5, since it makes it
much harder for ordinary users to add or remove support for Languages
on an installation. I presume the same holds for other groups of packages too.
It works just fine for yum repositories which is why it was not
Please refer to Release Criteria Secion 8.K.1
8.I18N-> K.Comps-> 1.Language Support for ALL supported languages and updated
Created attachment 143724 [details]
screenshot of reported bug - no group info
This is not i18n specific, it affects the whole system. Raising Severity.
Grepping the source for "groups" brings up:
./rhnplugin.py:167: # No support for package groups
./rhnplugin.py:168: self.groups_enabled = False
./rhnplugin.py:298: Return the location of the package group. We don't
support groups so we
Does this requires changes on the RHN server side too?
(In reply to comment #9)
> Does this requires changes on the RHN server side too?
Yes. Quite a large change, actually.
This bug requires massive changes. Not enough resources to work on it at the
moment. Re-aligning to RHN-RHEL5.1
Ironically this is not a regression for i18n (lang support) actually
since RHEL4 did not support post installation of language groups.
Re-aligning to RHEL5 since this bug will be fixed in this release.
yum-rhn-plugin-0.4.2-1.el5 Contains the client-side changes required for this.
We also have a sub-optimal solution in place for RHN 500 (hosted only) that
should be on webqa this week.
As the reporter, I'd like to test the changes. How do I get a copy of
yum-rhn-plugin-0.4.2-1.el5, or the "sub-optimal solution"? I don't see it in
ftp.redhat.com, and the version available from my RHN account is
Tested the bug with yum-rhn-plugin-0.4.3-1.el5 on RHEL5-Client-20070203.nightly
with the following steps:
1. Register rhn in firstboot or rhn_register after installation. (we used
rhn.webqa.redhat.com by modifying some config files to make it point to
2. In the system click Application->Add/Remove Software.
3. Click Browse tab.
Result: there is still empty screen in this tab.
According to the above test result put the bug back.
QA Verified against webdev, using the code that is in QA
Backend changes are missing in QA for this to be resolved in the QA environment,
but connecting to webdev, I was able to see the fix. I will mark this verified
for now, but if people are uncomfortable doing such until the backend code is
also in QA, I will return them to the previous state.
14:41 <fmoquete> Yes please. I need to be able to tell them wether these bugs
are verfied against the client or not