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?
(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 client
ran through a couple iterations and did not see any isues with pvetere. agreed to close as worksforme
pvetere has a system he can reproduce...opening this one back up
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.
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; NAME_ID ---------- EVR(EPOCH, VERSION, RELEASE) -------------------------------------------------------------------------------- 2681 EVR_T(NULL, '1.8.2-1', '1') SQL> select name from rhnpackagename where id = 2681; NAME --------------------------------------------------------------------------------CBLTwget Going to pass on to pvetere to take a look at the backend and how it updates this table after packages are updated.
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.
Created attachment 129189 [details] CBLTwget Test package
closing -- currentrelease