Intro: I don't know if I filed this against the right component. Please forward to the appropriate product/component as necessary. Description of problem: As of today (26-Feb-2003), the AS2.1 and AW2.1 RHN channels for IPF/IA64 are out of synchronization; not packages available for AW2.1 are available for AS2.1 -- this is an issue. See data below. Version-Release number of selected component (if applicable): RHN channels for AS2.1/ia64 and AW2.1/ia64 as of 26-Feb-2003. How reproducible: 100% (always) Steps to Reproduce: 1. Perform an everything install on IPF box w/ RHAS 2.1 2. Register with RHN 3. Get all available errata package updates (SRPMS, too), download-only 4. Perform steps 1 through 3 with RHAW2.1 on IPF box 5. Compare rpms downloaded from RHN server Actual results: ... caveat: I copied all RPMs from /var/spool/up2date on both systems (as2.1 and aw2.1) to a server in "as2.1" and "aw2.1" directories. I also created sub- directories "as2.1/SRPMS" and "aw2.1/SRPMS* and moved *.src.rpm packages to those sub-directories. # ls aw2.1/*.rpm | wc 159 159 6047 # ls as2.1/*.rpm | wc 157 157 5960 # ls aw2.1/SRPMS/*.rpm | wc 59 59 2295 # ls as2.1/SRPMS/*.rpm | wc 59 59 2290 # diff -r --brief as2.1/ aw2.1/ Only in as2.1/SRPMS: clumanager-1.0.19-2.src.rpm Only in aw2.1/SRPMS: tcpdump-3.6.2-12.2.1AS.1.src.rpm Only in aw2.1/: arpwatch-2.1a11-12.2.1AS.1.ia64.rpm Only in as2.1/: clumanager-1.0.19-2.ia64.rpm Only in aw2.1/: libpcap-0.6.2-12.2.1AS.1.ia64.rpm Only in aw2.1/: tcpdump-3.6.2-12.2.1AS.1.ia64.rpm Expected results: Packages for AW2.1 to be a subset or equivalent to AS2.1 Additional info: The clumanager packages are AS2.1-only, so they are not a concern. However, the AS2.1 release should offer the tcpdump, libpcap, and arpwatch packages that are available to AW2.1...
Glen, try: up2date --list --showall I can see the packages there.
Created attachment 90387 [details] AW2.1 output of "up2date --showall --list"
Created attachment 90388 [details] AS2.1 output of "up2date --showall --list"
The packages you mention missing in AS do show on the list. Am I missing something?
I'm not sure if you're missing anything. Nevertheless, when I run the following command on a text console on an Advanced Server 2.1 everything install: # up2date --update --download --src --nox ... I do not get the tcpdump errata packages. I do get them on a similarly-configured Advanced Workstation install.
Can you please run (on the AS box): rpm -q tcpdump Is the tcpdump package installed? Is the output the same on the AS box? Trying to narrow it down...
[root root]# rpm -q tcpdump tcpdump-3.6.2-11.7.2.0 [root root]# rpm -q tcpdump tcpdump-3.6.2-11.7.2.0 ... I'll attach an 'rpm -qa | sort' for both AS and AW. The only mods I made to each was to add dante to _both_ distros.
Created attachment 90401 [details] AW2.1 output of "rpm -qa | sort"
Created attachment 90402 [details] AS2.1 output of "rpm -qa | sort"
OK, so here's today's version of what's going on: On my workstation (which is 7.3, but up2date didn't change that much), doing: rpm -q tcpdump tcpdump-3.6.2-12 up2date --update --download --src --nox tcpdump [snip] None of the packages you requested were found, or they are already updated. rpm -e tcpdump up2date --update --download --src --nox tcpdump [snip] tcpdump-3.6.2-12.i386.rpm: ########################## Done. tcpdump-3.6.2-12.src.rpm: ########################## Done. So, if you have the package installed, it won't download it again, neither the binary nor the source. I believe the source rpm got into /var/spool/up2date prior to the package being installed - but I am not sure. Does this make sense? (my explanation, not up2date's behaviour :-) Otherwise, I was able to download the source rpm for tcpdump from the 2.1AS ia64 channel without any problem - the channels seem to be as identical as they were meant to be by looking at the database.
I can't tell what the next action item is for diagnosing this. I'm under the impression you're effectively saying "it should just work"... I'll try to re- install AS and AW on machines today and try it again to reproduce it and report back either way.
The next time I tried this experiment, the only diffs were AS2.1-specific, namely "im" and "clumanager". I can't seem to re-create this defect, so I'm closing it. Sorry for the red herring. :(