Created attachment 334930 [details] diff on RHN + `rpm -q acl aide at` on client Description of problem: I have created a profile in the webqa, removed and added few packages and then compared system state to the stored profile and I see too many rows in the diff. I would expect count of the rows in the resulting diff == number of (un)installed packages - is that right? https://rhn.webqa.redhat.com/rhn/systems/details/packages/profiles/CompareProfiles.do?sid=1014485848&prid=8441 user: jhutarqa, pass: redhatqa (I have removed pdksh,ash,acl and installed aide,ksh - but in the linked diff I see probably all packages - e.g. autofs, it says it is only in the profile, but I see it installed as well - I have not touched it) Version-Release number of selected component (if applicable): webqa 5.0.9 How reproducible: 2 of 2 (x86_64 and ia64 systems with RHEL4-U6 recently updated to RHEL4-U7) Steps to Reproduce: 1. Create profile 2. remove pdksh,ash,acl and install aide,ksh 3. up2date -p 4. compare stored profile with current system state Actual results: See attached screenshot Expected results: pdksh,ash,acl - only in the profile aide,ksh - only on the system no other changes in the diff Additional info: May be related to the bug 457423 and bug 458166
This appears to be caused by the client side, and how it sends up a package profile during registration. During registration the client does rpmUtils.getInstalledPackageList(getInfo=1) All other times the client does rpmUtils.getInstalledPackageList(getArch=1) getArch checks that the package has an arch field and if not, ignores it (for gpg keys, for instance). getInfo checks that the package has both an arch and a cookie field, and if not, ignores it. A lot of packages don't have a cookie, so they are ignored during registration, but added on further profile syncs. afaik the cookie field is never used server side, so it should be safe to just have the client use getArch vs getInfo.
This has been mistakenly assigned to RHEL-5 client component, although the initial comment says up2date (RHEL-4). Clone of the problem for RHEL-4 is available at bug #543942
Following the advice from comment #1, using getArch=1 during client registration. spacewalk.git master: 77c7e858bebe5812f8565ef1fe995f1ab4c473fc
Sending src/bin/rhnreg_ks.py Sending src/up2date_client/rhnregGui.py Sending src/up2date_client/tui.py Transmitting file data ... Committed revision 189258.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0270.html