Description of problem: spacecmd softwarechannel_adderrata again giving error message: ERROR: redstone.xmlrpc.XmlRpcFault: Cloned channel expected: Version-Release number of selected component (if applicable): spacewalk-java-2.5.87-1.el6.noarch spacecmd-2.5.6-1.el6.noarch How reproducible: easily Steps to Reproduce: 1. start with complete, sound centos6-64 repo, with CEFs run complete 2. create channel 'centos6-64-security', no parents 3. spacecmd -y -q -- centos6-64 centos6-64-security CESA-2016:0494 Actual results: Security Errata --------------- CESA-2016:0494 Moderate CentOS kernel Security Update 2016-03-23 Total Errata: 1 ERROR: redstone.xmlrpc.XmlRpcFault: Cloned channel expected: centos6-64-securityerrata Expected results: Successfully copying one erratum into the security channel. Additional info: currently testing on nightly from a week ago. Can test on stock 2.4 or new nightly channel, if the latter will once again install successfully.
this smells like bug 806895 and bug 812053 but I didn't get any usable fixes out of either. Sorry if it's a true dupe.
Oops. Typo in my repro steps. When I say: 3. spacecmd -y -q -- centos6-64 centos6-64-security CESA-2016:0494 I mean 3. spacecmd -y -q -- softwarechannel_adderrata centos6-64 centos6-64-security CESA-2016:0494 In short, I forgot the spacecmd command. Doh!
Hello, I was able to successfully reproduce your issue and made some investigation. Those two bugs you enclosed are not related to this issue, as it uses different API. "softwarechannel_adderrata" from spacecmd expects cloned channel as destination channel, because in other case it might happen that it will clone all the errata packages including packages for different OS. "softwarechannel_adderrata" calls API 'errata.cloneAsOriginal' which does the check described above. To omit this check you should look at 'errata.clone'. Hope this helps
Is there a subcommand in spacecmd to allow regular access to this API call? If so, my issue could be more a documentation issue than a code issue. If not, and if I prepared the centos6-64-security channel via a command like spacecmd -q -- \ softwarechannel_clone \ -s centos6-64 \ -n centos6-64-security \ -l centos6-64-security \ -p something_else \ -o can I then clone my (one, in this example) Erratum from my source channel to its clone? spacecmd -y -q -- \ softwarechannel_adderrata \ centos6-64 \ centos6-64-security \ CESA-2016:0494 I can live with that second solution, I think. If that will work, it could be all I need.
Yeah, that mostly works for my needs. I need to vape the freshly copied payload in order to start fresh and keep the associative link to its parent, but that's it. So, as above, softwarechannel_clone, and then spacecmd -q -y -- \ softwarechannel_removepackages \ centos6-64-securityerrata \ '*' And then we can clone errata by part or by script [1] and we should get the ones we want. Close me up.
(with many thanks for your time, and apologies for the spam)
I'm glad it helped. Closing this one as "not a bug".
This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug.