RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 604973 - repo file saving error when in repo id is $basearch
Summary: repo file saving error when in repo id is $basearch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: yum
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: Karel Srot
URL:
Whiteboard:
Depends On:
Blocks: 582655
TreeView+ depends on / blocked
 
Reported: 2010-06-17 07:39 UTC by Jiri Kastner
Modified: 2014-01-21 06:18 UTC (History)
3 users (show)

Fixed In Version: yum-3.2.29-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: yum would interpret repoids and then just use the interpreted value (Eg. foo$arch => fooi686) Consequence: yum would lose the original, uninterpreted, data Fix: use the original data, when saving Result: will now save as foo$arch
Clone Of:
Environment:
Last Closed: 2011-05-19 13:33:25 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0602 0 normal SHIPPED_LIVE yum bug fix and enhancement update 2011-05-19 09:37:29 UTC

Description Jiri Kastner 2010-06-17 07:39:16 UTC 
Description of problem:
i'm not able using 'Add/Remove Software': 'System'->'Software sources' disable or enable repositories, having in id $basearch

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. define/change some repo to have $basearch instead of x86_64|i386 in id
2. try e.g. yum repolist --disablerepo=latest-x86_64-ws-6
3. passed
4. run gnome 'Add/Remove Software'
5. try disable/enable same repo as above using 'System'->'Sotfware sources'
  
Actual results:
Traceback (most recent call last):
  File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2502, in repo_enable
    repo.disablePersistent()
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 411, in disablePersistent
    config.writeRawRepoFile(self,only=['enabled'])
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 1008, in writeRawRepoFile
    ini[repo.id][name] = option.tostring(value)
  File "/usr/lib/python2.6/site-packages/iniparse/ini.py", line 468, in __getitem__
    return self._sections[key]
KeyError: 'latest-x86_64-ws-6-opt'

Expected results:
repo is disabled

Additional info:
[latest-$basearch-ws-6]
name=latest-$basearch-ws-6
baseurl=http://download.englab.brq.redhat.com/nightly/latest-RHEL6.0/6/Workstation/$basearch/os/
gpgcheck=0
enabled=1
metadata_expire=1h
[latest-$basearch-ws-6-opt]
name=latest-$basearch-ws-6-opt
baseurl=http://download.englab.brq.redhat.com/nightly/latest-RHEL6.0/6/Workstation/optional/$basearch/os/
gpgcheck=0
enabled=1
metadata_expire=1h
Comment 1 Richard Hughes 2010-06-17 08:54:41 UTC 
PK is just doing repo.disablePersistent() -- I think this must be a yum bug.
Comment 2 seth vidal 2010-06-17 13:56:33 UTC 
The problem here is the $basearch value in the [repoid]

We're not converting back to it so it can't find it in the list of repos it knows.

I'm looking for a nice fix now.
Comment 3 James Antill 2010-06-17 14:47:48 UTC 
I would have beta  lot that this didn't work (becase $ is not allowed in a repoid) ... but it turns out that ConfigPreProcessor() is doing the substitution before we even see it.
Ie. what we get from parser.sections() has already had the replacements done.
Comment 6 seth vidal 2010-06-17 15:30:16 UTC 
patch that fixes this problem sent upstream.
Comment 11 Karel Srot 2011-02-21 15:28:34 UTC 
I have filed a new bug 679098 regarding yum-config-manager since the GUI variant seems to be fixed with yum-3.2.29-5.el6.noarch but yum-config-manager tracebacks in a similar way.
Comment 13 James Antill 2011-05-12 19:05:35 UTC 
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: yum would interpret repoids and then just use the interpreted value (Eg. foo$arch => fooi686)
Consequence: yum would lose the original, uninterpreted, data
Fix: use the original data, when saving
Result: will now save as foo$arch
Comment 14 errata-xmlrpc 2011-05-19 13:33:25 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0602.html
Note You need to log in before you can comment on or make changes to this bug.