Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 153189 - rhn_check errors when removing package scheduled through RHN
rhn_check errors when removing package scheduled through RHN
Status: CLOSED DUPLICATE of bug 155569
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Max Spevack
Depends On:
  Show dependency treegraph
Reported: 2005-04-02 06:55 EST by Lee Wilson
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-13 14:08:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lee Wilson 2005-04-02 06:55:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

Description of problem:
When running rhn_check to run a scheduled package removal though Red Hat Network the client produces a traceback as follows (with the -v switch):-

[root@workstation RPMS]# rhn_check -v
packages.remove ([['gaim', '1.1.4', '1.EL4', '1']],)
Traceback (most recent call last):
  File "/usr/sbin/rhn_check", line 174, in run_action
    (status, message, data) = do_call(method, params)
  File "/usr/sbin/rhn_check", line 91, in do_call
    retval = apply(method, params)
  File "/usr/share/rhn/actions/packages.py", line 83, in remove
    up2date.removePackages(pkgList, rpmCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 1009, in removePackages
TypeError: runTransaction() takes at least 4 arguments (2 given)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Login to RHN
2. Bring up the details of a system
3. Select Packages->List/Remove Installed Packages
4. Tick one of the packages (I Tried gaim & firefox seperately)
5. Click Remove Packages
6. Then Confirm
7. Go onto Schedule to confirm it is set to run
8. Run "rhn_check -v" as root from the selected workstation, should get a similar trace back to me.

Actual Results:  Package was not removed.

Expected Results:  Selected package(s) should have been removed from the selected system(s)

Additional info:

Problem seems to be due to the runTransaction call in the removePackages function in the up2date.py file.  It uses the following call to remove the packages:-


This has 2 less arguments that other similar calls to runTransaction.  For example installPackages looks like this:-

runTransaction(ts, added, removed,rpmCallback, rollbacktrans = rollbacktrans)

The severity of this bug could be debated as it may also class as a security issue in certain situation.  For example needed to remove a very buggy bit of software from many systems or one which is not likely to be fixed in the short term and therefore needs to be remove from every system.
Comment 1 Lee Wilson 2005-04-02 07:10:11 EST
Adding the following lines to /usr/share/rhn/up2date_client/up2date.py at line
964 , just after "def removePackages" function definition

 added = []
 removed = []

and then changing the function call at line 1011 to:-

runTransaction(ts, added, removed ,rpmCallback)

Seems to fix the immediate problem, but I don't believe it checks the
dependancies so may need someone with a bit more knowledge to figure out a
complete solution. As long as specify all the deps to be removed as well seems
to work okay.
Comment 2 Max Spevack 2005-04-04 10:49:54 EDT
alikins -- I have reproduced this bug as well.

It exists in the following versions of up2date:

4.4.5-1 (rhel-4 gold) (the version we just released with the other fixes)

Setting this to block rhn400 (though it may need to be fixed faster) and adding
misa to the cc list.
Comment 3 Adrian Likins 2005-05-13 14:08:08 EDT

*** This bug has been marked as a duplicate of 155569 ***

Note You need to log in before you can comment on or make changes to this bug.