Red Hat Bugzilla – Bug 604973
repo file saving error when in repo id is $basearch
Last modified: 2014-01-21 01:18:03 EST
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):
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
4. run gnome 'Add/Remove Software'
5. try disable/enable same repo as above using 'System'->'Sotfware sources'
Traceback (most recent call last):
File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2502, in repo_enable
File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 411, in disablePersistent
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__
repo is disabled
PK is just doing repo.disablePersistent() -- I think this must be a yum bug.
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.
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.
patch that fixes this problem sent upstream.
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.
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.
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
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.