Bug 188325 - GUI shows package needs updating yet is at most recent rev
Summary: GUI shows package needs updating yet is at most recent rev
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Solaris   
(Show other bugs)
Version: 500
Hardware: All Linux
Target Milestone: ---
Assignee: Pete Vetere
QA Contact: Clifford Perry
Keywords: Reopened
Depends On:
Blocks: 196477
TreeView+ depends on / blocked
Reported: 2006-04-07 21:02 UTC by Mike McCune
Modified: 2007-06-26 15:11 UTC (History)
4 users (show)

Fixed In Version: rhn410
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-19 22:10:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
CBLTwget (617.90 KB, application/octet-stream)
2006-05-16 13:04 UTC, Pete Vetere
no flags Details

Description Mike McCune 2006-04-07 21:02:23 UTC
1: Creating a Solaris base channel
2: Subscribe a solaris system to this base channel
3: Upload a package to the solaris channel
4: Schedule the package for installation via the GUI
5: Run rhn_check on the solaris host (It will download and install the package)
6: Look at the current state of the db.  It says there's one update available
(the just installed package). 
7. Look at the package list for the system, and it has the package recorded as
installed (which it is)
8.  Wonder if this custom package has a version numbering problem?

Comment 2 Mike McCune 2006-04-07 21:11:10 UTC
(12:05:37) pvetere: blc: interesting problem you found
(12:05:45) pvetere: blc: wouldn't be surprised if it's a bug
(12:13:57) pvetere: blc: i looked at your system... it's definitely a bug. 
can't explain why it happened without some more detailed investigation
(12:14:03) pvetere: blc: but i haven't seen it before
(12:14:54) pvetere: blc: it's possible that for some reason the server has a
different md5 for the pkg in the channel than was computed by the package on the

Comment 5 Shannon Hughes 2006-05-03 15:24:52 UTC
ran through a couple iterations and did not see any isues with pvetere. agreed
to close as worksforme

Comment 6 Shannon Hughes 2006-05-10 18:31:54 UTC
pvetere has a system he can reproduce...opening this one back up

Comment 7 Shannon Hughes 2006-05-10 18:32:27 UTC
shughes blc, k, will open it back up. 
blc shughes: btw, the client system is now solaris10-1.farm.hsv.redhat.com. 
otherwise everything is the same.

Comment 8 Shannon Hughes 2006-05-11 17:50:09 UTC
looks like the rhnServerOutdatedPackages table is not being updated correctly, 

SQL> select sop.package_name_id as name_id, max(pe.evr) evr
  2  from rhnPackageEVR PE, rhnServerOutdatedPackages SOP
  3  where sop.server_id = 1000010019
  4  and sop.package_evr_id = pe.id
  5  group by sop.package_name_id;

EVR_T(NULL, '1.8.2-1', '1')

SQL> select name from rhnpackagename where id = 2681;


Going to pass on to pvetere to take a look at the backend and how it updates
this table after packages are updated. 

Comment 9 Pete Vetere 2006-05-16 13:00:54 UTC
Fixed.  The package revision was incorrectly being built in situations where the
version had the format x-y-z (1.8.2-1-1, in this case).  The bug was that the
version became 'x' and the revision became 'y z'.  However, the server wants the
following format: version='x-y', revision='z'.  I've adjusted the code to
produce the latter.

Comment 10 Pete Vetere 2006-05-16 13:04:09 UTC
Created attachment 129189 [details]

Test package

Comment 13 Beth Nackashi 2006-07-19 22:10:27 UTC
closing -- currentrelease

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