yum-3.2.24-9.fc12.noarch PackageKit nags me on a regular basis that: Cannot retrieve repository metadata (repomd.xml) for repository: rpmfusion-free. Please verify its path and try again It doesn't tell me what's wrong with it, doesn't tell me where to verify the path, and seems to be fatal when running on the command-line as well. I'd like to tell it: it's not there, do without
You can do --disablerepo=rpmfusion\* ... the API to turn a repo. off forever is about 2 lines of code, and we even have test scripts to do it for you: http://james.fedorapeople.org/yum/commands/yum-repo-mgr.py ...we'd need to be convinced a lot to ask this kind of question at the cmd line though, so from what I can tell you just filed against the wrong component.
The error message is the same one I see on the command-line. Instead of just skipping the repo it errors out. Completely.
Since repos can impact one another disabling an errored repo is not wise. The hard and fast rule is: if a repo that is enabled is down then we abort. your options are: 1. fix the problem with the repo being inaccessible 2. disable the repo with --disablerepo
(In reply to comment #3) > Since repos can impact one another disabling an errored repo is not wise. The Unless it is taken temporarily offline...or forever. It would be helpful if the error message generated made it clear what is going on, with suggested solutions. At the moment, in the gui desktop, the user sees just a popup notification (that disappears even if they never actually saw it!) That's what I noticed. It's not clear that you can get more details. Perhaps it is reasonable for yum to automatically (temporarily) disable inaccessible mirrors, and do updates/installs regardless. (Resilience). Examples might be: - repo that is moving URL etc - repo that is having some technical difficulty Neither should stop me getting an important security update or installing new software/updates (as long as I don't have something installed from the inaccessible repo, that blocks the transaction from occurring). In fact, let's say a possible security scenario: - an important security update is released - as soon as he sees the secupdate, attacker takes out a popular third party repo. - no user of the third party repo can get the important security update, and won't even be notified that the update(s) exist. I won't be so annoying as to reopen, but what do you think of the above scenario ?
(In reply to comment #4) > - an important security update is released ... (in a working repo eg fedora-updates)
The error only happens if you have no cache on disk already to revert to. The fact that PK gives a temporary popup, and doesn't let you deal with it sanely isn't a yum bug. We've discussed changing the yum client to do something like: "Repo rpmfusion-updates is not available, do you want to: [fail] [disable] [[temp. disable]]" ...and we aren't opposed to doing something like that, HOWEVER there are at least 4 reasons why this isn't at the top of anyone's list: 1. As I said, this problem only happens if someone did "yum clean all" or has never accessed a particular repo. ... don't do that. 2. Because of #1 yum is _much_ more likely to fail when downloading _packages_, so we'd need to handle that too (which is a much bigger problem). 3. PK, which is in a much easier position to do the right thing here is happily doing worse than yum (message disappears) and from what I've heard is about to do _even_worse_ by just auto. disabling repos. 4. It's really easy to work around on the cmd line already, using --disablerepo etc. ...obviously if you have an idea for a better message, or want to work on #2 for the yum cmd line client ... patches accepted.
Reopening. I've seen that on a newly installed machine without network access, when trying to install a local rpm file using yum. Here's the backtrace from PK: Traceback (most recent call last): File "/usr/share/PackageKit/helpers/yum/yumBackend.py", line 2577, in simulate_install_files txmbr = self.yumbase.installLocal(inst_file) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3296, in installLocal tx_return.extend(self.install(po=po)) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 2803, in install if self.tsInfo.exists(pkgtup=po.pkgtup): File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 729, in <lambda> tsInfo = property(fget=lambda self: self._getTsInfo(), File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 111, in _getTsInfo pkgSack = self.pkgSack File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 720, in <lambda> pkgSack = property(fget=lambda self: self._getSacks(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 549, in _getSacks self.repos.populateSack(which=repos) File "/usr/lib/python2.6/site-packages/yum/repos.py", line 277, in populateSack sack.populate(repo, mdtype, callback, cacheonly) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 164, in populate if self._check_db_version(repo, mydbtype): File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 222, in _check_db_version return repo._check_db_version(mdtype) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1244, in _check_db_version repoXML = self.repoXML File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1408, in <lambda> repoXML = property(fget=lambda self: self._getRepoXML(), File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1404, in _getRepoXML raise Errors.RepoError, msg RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: rawhide. Please verify its path and try again Looks to me that the whole problem stack here belongs to yum.
Actually - it stats in yumbackend which is PK's - and it looks to me like PK is not catching the RepoError exception when there is no metadata available and should do so.
commit 17cf7c2bfadef59690c0c96a6af18ae2fb3430a2 Author: Richard Hughes <richard> Date: Tue Oct 20 15:47:36 2009 +0100 yum: disable repos that are not contactable :100755 100755 8632e53... 5625089... M backends/yum/yumBackend.py I'll do a build with this fix in a few minutes.
This is the patched build: http://koji.fedoraproject.org/koji/buildinfo?buildID=138834 tag request is: https://fedorahosted.org/rel-eng/ticket/2936 Bastien, can you please test and confirm that it does the trick for you? Thanks! It's on the F12 blocker list so if you could do it ASAP that would be really good. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This was tagged and will be in tomorrow's rawhide (20091103) - please test.
I've tested and confirmed the fix for this, here. I installed a new VM from F12 Beta live CD with no network adapter. Dumped a test RPM (nedit) and the updated PackageKit RPMs into it with guestfish (neat tool). Booted the VM. Without upgrading PackageKit, attempted to install the nedit RPM by double-clicking on it in Nautilus. Got a nasty 'an internal system error has occurred' dialog with the 'cannot retrieve repository metadata' message at the bottom. Upgraded PackageKit to the patched build, tried the nedit test again. The process goes further, there's no 'internal system error has occurred' dialog, instead it fails at dependency resolution because a few of nedit's dependencies aren't installed, which is what I'd expect. So this looks fixed, to me. Closing. Please re-open if you still hit problems, Bastien or any other reporter. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers