Description of problem: API call system.listLatestUpgradablePackages suggests not newest only packages. Both `yum list updates` and WebUI -> system -> Software -> Packages -> Upgrade shows only newest one. Version-Release number of selected component (if applicable): SWnightly as of yesterday spacewalk-java-1.8.107-1.el5 How reproducible: always Steps to Reproduce: 1. wget 3 versions of some package, I had: drupal7-7.12-1.el5.noarch.rpm drupal7-7.14-1.el5.noarch.rpm drupal7-7.14-2.el5.noarch.rpm 2. push them to some channel your system is subscribed to 3. Install oldest one (7.12-1.el5 in my case) 4. Confirm that `yum list updates | grep drupal7` and WebUI -> system -> Software -> Packages -> Upgrade only recommends newest (7.14-2.el5) 5. Check API call recommends two: # python Python 2.4.3 (#1, Dec 22 2011, 12:12:24) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib, pprint >>> client = xmlrpclib.Server('https://<fqdn>/rpc/api', verbose=0) >>> key = client.auth.login('<user>', '<password>') >>> pprint.pprint(client.system.listLatestUpgradablePackages(key, 1000010366)) Actual results: [{'arch': 'noarch', 'from_epoch': ' ', 'from_release': '1.el5', 'from_version': '7.12', 'name': 'drupal7', 'to_epoch': ' ', 'to_package_id': 7761, 'to_release': '2.el5', 'to_version': '7.14'}, {'arch': 'noarch', 'from_epoch': ' ', 'from_release': '1.el5', 'from_version': '7.12', 'name': 'drupal7', 'to_epoch': ' ', 'to_package_id': 7760, 'to_release': '1.el5', 'to_version': '7.14'}] Expected results: [{'arch': 'noarch', 'from_epoch': ' ', 'from_release': '1.el5', 'from_version': '7.12', 'name': 'drupal7', 'to_epoch': ' ', 'to_package_id': 7761, 'to_release': '2.el5', 'to_version': '7.14'}] Additional info: If this is expected, would it be possible to enhance documentation for the function so it warns about that?
This was first reported by Prakash Velayutham in the mailing list: https://www.redhat.com/archives/spacewalk-list/2012-July/msg00029.html
Just wanted to know if there has been any status updates to this bug. Thanks, Prakash
Hello, Any updates please? Thanks, Prakash
spacewalk.git: 4823565b2e634bc73010d366ff82c432630bca85
The same API call also shows packages with the same name from channels the system is not subscribed to. This is the case where people have e.g. redhat and centos packages in spacewalk, both using the same name+version (like the kernel package). I don't think the system is allowed to install packages from another channel, but it is not very "pretty" ... Is this also resolved with this new query? If not, I'll to open a new bug report for this. Also, can this fix be backported somehow to 1.7? Since this caused me quite some troubles when first updating servers (where older kernel packages were installed after newer versions when feeding the resulting list from this API call to system.schedulePackageInstall() )
To answer my own question: it still gives package id's from channels the system isn't subscribed to as well.
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
make the query work on PG ... spacewalk.git: 594781171402e28f85cdcb9fe7e838e35288a505 Moving back to MODIFIED ...
list upgradable packages from server channels only (fix for issue described in Comment#6) ... spacewalk.git: 1168f61a9d16b42b533a21513c8538529862e745
This problem is also in the API for RHN Satellite 5.5 (and probably earlier then). Should a separate bug be filed for that?
Yes, current Bug is filed against Spacewalk. If you want to track the issue against any other Product, please, create a separate BZ.
Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.
Spacewalk 1.9 has been released. https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19