Centos – yumdownloader vs repotrack

This seems to be a bug in yum-utils, nothing that you're doing wrong.

I did a little crude "print" debugging between my RHEL 6 server, and My Fedora 14 workstation. Right after line 47 & 48 in /usr/bin/yumdownloader:

(n,v,r,e,a) = rpmUtils.miscutils.splitFilename(pkg.sourcerpm)
src = self.pkgSack.searchNevra(name=n, ver=v, rel=r, arch='src')

I added a couple of debugging statements and found the following:

From my RHEL 6 server (indented areas following "Debug:" being the areas of interest):

# yumdownloader --source gcc
Loaded plugins: presto, rhnplugin
Enabling epel-source repository
Debug: 
    pkg.sourcerpm = gcc-4.4.4-13.el6.src.rpm
    n = gcc
    v = 4.4.4
    r = 13.el6
    src = []
No source RPM found for gcc-4.4.4-13.el6.x86_64
Debug: 
    pkg.sourcerpm = gcc-4.4.5-6.el6.src.rpm
    n = gcc
    v = 4.4.5
    r = 6.el6
    src = []
No source RPM found for gcc-4.4.5-6.el6.x86_64
Nothing to download

From my Fedora 14 workstation:

# yumdownloader --source gcc
Loaded plugins: presto, refresh-packagekit
Enabling updates-source repository
Enabling rpmfusion-nonfree-updates-source repository
Enabling rpmfusion-nonfree-source repository
Enabling rpmfusion-free-updates-source repository
Enabling fedora-source repository
Enabling rpmfusion-free-source repository
Debug: 
    pkg.sourcerpm = gcc-4.5.1-4.fc14.src.rpm
    n = gcc
    v = 4.5.1
    r = 4.fc14
    src = [<YumAvailablePackageSqlite : gcc-4.5.1-4.fc14.src (0xe5e150)>]
gcc-4.5.1-4.fc14.src.rpm                                 |  52 MB     00:38

So we know what src "should" be, based off of Fedora 14. /usr/bin/yumdownloader is identical between RHEL6, and Fedora 14 (md5sums match). However the yum-utils libraries that yumdownloader is leveraging are different between RHEL6 and Fedora 14, and that is likely the culprit.

I'd file a bug with Redhat against the yum-utils package.

First things first: a very well-done, systematic and thorough debugging, good job.

On my RHEL 5.6 box I always get a return code of 1 if I try to kill a non-existing pid. I tried as both root and a non-privileged user, both with full path and a with just the command name. I also get only terse kill XXX: No such process, with no elaborate error messages.

It may be a good idea to run rpm -Vv util-linux and see if somebody didn't replace /bin/kill with a new and improved version. Even if rpm verification says the file is pristine, I'd try renaming /bin/kill and copying over a binary from a working machine. If the file replacement helps and you don't uncover a legitimate the source of the change, then regardless of output of rpm verification I'd assume the machine was compromised.