Everything looks fine here.

Are you behind a proxy of any kind?

Does: 'URLGRABBER_DEBUG=1 yum check-update' show any issues with downloading the metalink?

I don't know if this machine is behind any proxy and I don't have access to the network infrastructure on that lab. If you think this is the case I can just ask the user to use a mirrorlist instead of baseurl for the repo config as this seems to work for him. I just wanted to make sure this isn't an obvious misconfig that we were missing.

yum check-update doesn't show any error. Here is the repomd.xml related snipet from URLGRABBER_DEBUG=1 yum check-update

{{{
2013-08-29 15:08:53,268 MIRROR: trying repodata/repomd.xml -> http://dl.fedoraproject.org/pub/fedora-secondary/updates/19/ppc64/repodata/repomd.xml
2013-08-29 15:08:53,268 combined options: {
'checkfunc' : (>, (), {}),
'copy_local' : 1,
'http_headers' : (),
'range' : None,
'reget' : None,
'size' : 102400,
'text' : ,
'delegate' : {
'delegate' : {
'async' : None,
'bandwidth' : 0,
'cache_openers': True,
'checkfunc' : None,
'close_connection': 0,
'copy_local' : 0,
'data' : None,
'default_speed': 1000000.0,
'delegate' : None,
'failfunc' : ,
'failure_callback': (>, (), {}),
'ftp_headers' : None,
'half_life' : 2592000,
'http_headers' : (),
'interrupt_callback': >,
'ip_resolve' : None,
'keepalive' : True,
'libproxy' : False,
'max_connections': 5,
'max_header_size': 2097152,
'minrate' : 0,
'mirror_group' : None,
'multi_progress_obj': ,
'opener' : None,
'password' : None,
'prefix' : None,
'progress_obj' : ,
'proxies' : None,
'proxy' : None,
'quote' : None,
'range' : None,
'reget' : 'simple',
'retry' : 10,
'retrycodes' : [-1, 2, 4, 5, 6, 7],
'size' : None,
'ssl_ca_cert' : None,
'ssl_cert' : None,
'ssl_cert_type': 'PEM',
'ssl_context' : None,
'ssl_key' : None,
'ssl_key_pass' : None,
'ssl_key_type' : 'PEM',
'ssl_verify_host': True,
'ssl_verify_peer': True,
'text' : None,
'throttle' : 0,
'timedhosts' : None,
'timeout' : 30.0,
'urlparser' : ,
'user_agent' : 'urlgrabber/3.9.1 yum/3.4.3',
'username' : None,
}
}
}
2013-08-29 15:08:53,269 attempt 1/10: http://dl.fedoraproject.org/pub/fedora-secondary/updates/19/ppc64/repodata/repomd.xml
2013-08-29 15:08:53,270 opening local file "/var/cache/yum/ppc64/19/updates/repomdEbvEFWtmp.xml" with mode wb
* About to connect() to dl.fedoraproject.org port 80 (#10)
* Trying 209.132.181.27...
* Connected to dl.fedoraproject.org (209.132.181.27) port 80 (#10)

GET /pub/fedora-secondary/updates/19/ppc64/repodata/repomd.xml HTTP/1.1
User-Agent: urlgrabber/3.9.1 yum/3.4.3
Host: dl.fedoraproject.org
Accept: /

< HTTP/1.1 200 OK
< Date: Mon, 19 Aug 2013 17:08:09 GMT
< Server: Apache/2.2.15 (Red Hat)
< Last-Modified: Tue, 12 Mar 2013 19:11:29 GMT
< ETag: "315883-a7c-4d7bf0e827a40"
< Accept-Ranges: bytes
< Content-Length: 2684
< ProxyTime: D=3318
< ProxyServer: download02.phx2.fedoraproject.org
< Content-Type: text/xml
< Connection: Keep-Alive
< Age: 871244
2013-08-29 15:08:53,275 header ended:
<
* Connection #10 to host dl.fedoraproject.org left intact
updates | 2.6 kB 00:00:00
2013-08-29 15:08:53,278 success
}}}

Odd. Yeah, it could be a transparent proxy somewhere...

I assume 'yum clean all' doesn't change anything?

I tried 'yum clean all' but unfortunately it doesn't change anything.

I notice that a wget on that repomd.xml URL gives me a different version of repomd.xml than a wget on the same URL from a different network, so it is certainly a caching proxy somewhere. If this misbehaving proxy is not in the Fedora infra, I will assume it is somewhere in the user's network and we can close this ticket as invalid.

yeah. ;(

One last thing to suggest: does adding:

http_caching=none

to /etc/yum.conf change anything?

I guess that didn't change anything?

Well, do let us know if there's anything more to look into on our end.

Thanks.