Description: Spacewalk claims available updates, client claims "No Packages marked for Update" Version-Release number of selected component (if applicable): 1.1 How reproducible: Moderate Steps to Reproduce (This is how I came across it anyways). 1. Upload CentOS 5.4 Base to one channel and Updates to child channel. 2. Patch system. 3. Upload CentOS 5.5 Base to the same base channel, and updates to the same child channel. 4. Patch system. 5. This is where Spacewalk claims available updates, but the client just says "No Packages marked for Update" when running yum update. Actual results: No packages available to the client even though Spacewalk says there are updates for the client. Expected results: That the updates get installed correctly with "yum update" Additional info: No change on the client even after running "yum cleam all".
I've reproduced this behaviour another way: Install CentOS 5.4, with the 0.8 Spacewalk-client RPM's from http://spacewalk.redhat.com/yum/0.8-client/RHEL/5/i386/ . Create a Spacewalk-client channel in Spacewalk (as a child channel to the CentOS Base channel) with the RPM's from http://spacewalk.redhat.com/yum/1.1-client/RHEL/5/i386/ . Subscribe the CentOS machine to the CentOS Base channel, including child Centos Updates channel and child Spacewalk-client channel. Try to yum update. Expected behaviour would be that the spacewalk-client RPM's would be updated as well, but I haven't been able to do this on any of my CentOS 5 i386 machines. Instead I get errors like this: --> Processing Conflict: yum conflicts yum-rhn-plugin < 0.5.3-30.el5 --> Finished Dependency Resolution yum-3.2.22-20.el5.centos.noarch from centos5-i386 has depsolving problems --> yum conflicts with yum-rhn-plugin Error: yum conflicts with yum-rhn-plugin
this was probably a cause of the repo files not being properly regenerated after adding additional content to my channels. I followed these directions from jsherrill which sorted my problem out. < jsherrill> 1. verify there are no .new files in /var/cache/rhn/repodata/CHAN_LABEL/ < jsherrill> 2. if not delete all files in there < jsherrill> 3. have a system try to yum update (you'll get an error) < jsherrill> 4. sit back and wait for teh yum repo to be regenereted in /var/cache/rhn/repodata/CHAN_LABEL/
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.
Mass-moving to space13.
This seems to work in current nightly. Setting the BZ to MODIFIED.
Moving ON_QA ...
This bug has been fixed in Spacewalk 1.3.