From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 Description of problem: After using up2date to install an RPM fetched from an apt repo and removing the RPM, attempts to re-install the RPM from the same repo hang (CPU near 100%) after message "Fetching RPM headers..." Ctrl-C doesn't kill the process. Ctrl-z followed by kill doesn't kill the process, kill -9 is necessary. Version-Release number of selected component (if applicable): up2date-4.1.16-1 How reproducible: Always Steps to Reproduce: 1. Add "apt macromedia http://ruslug.rutgers.edu/macromedia/apt fedora/1 macromedia" to /etc/sysconfig/rhn/sources. 2. up2date --nosig flash-plugin 3. rpm -e flash-plugin 4. up2date --nosig flash-plugin Actual Results: Infininte loop. Expected Results: flash-plugin RPM should be downloaded and installed. Additional info: After first (successful) install: [root@yankee mjs]# ls /var/spool/up2date/*macro* /var/spool/up2date/macromedia-macromedia.20031122062458 /var/spool/up2date/macromedia-macromedia-obsoletes.1000 /var/spool/up2date/tmp-macromedia-macromedia-20031122062458 If I delete those files, the next install attempt works. The flash-plugin RPM seems to require the --nosig option to up2date (another bug?) If I don't include this option, the install aborts. After that failure: [root@yankee mjs]# ls /var/spool/up2date/*macro* /var/spool/up2date/link-macromedia-macromedia /var/spool/up2date/macromedia-macromedia.20031122062458 /var/spool/up2date/macromedia-macromedia-obsoletes.1000 /var/spool/up2date/tmp-macromedia-macromedia-20031122062458 Note the link-* file, not present after successful install. After the aborted install without --nosig, the next atempt to install succeeds.
hmm, looks like its deleting the headers after installing the package when it shouldnt be. I'll special case it for apt the --nosig is required because the packages are not GPG signed (or signed by a key not on rpms keyring).
Yes, I figured out the --nosig issue. I didn't have the fedora.us key yet. It does work with yum, though.
The procedure above still fails on FC3test1 (up2date-4.3.19-1.1), but in a slightly different way: instead of hanging indefinitely, up2date eventually fails saying it couldn't contact the server, but it didn't even *try* to contact the server. The problem appears to be that the hdr file for flash-plugin was removed after the initial install, and the apt back-end doesn't re-extract the hdr from the apt headers file. strace shows it just stats the various package directories for the flash-plugin*.hdr file and then prints the error. Matthew, I see you filed bug #111041 as well, which looks to me like a different symptom for the same bug. Should we dup it, mark it as depend, or just leave it alone?
IIRC, I really did think these were two separate bugs. The other one had to do with resolving dependencies, possibly in a repository that appeared earlier in the list, and this one had to do with improper handling of the files in /var/spool/up2date. You'd probably know better than I, though. If you think it's the same bug, then linking them is fine with me, whichever you think is best. (As the user, my main objective is to see them both resolved 8^). (It's not really relevant, but the FC2 flash-plugin RPM has a broken GPG sig, so I ended up installing it via synaptic.)
This is still relevant in rawhide, and it's actually more serious that I'd first thought. Here goes a complete description with a recipe to duplicate the problem: 1. install a package using up2date from an apt repository. At the end, up2date removes both the .rpm and the .hdr from /var/spool/up2date 2. install with up2date any other package that requires dep resolution. At this point, up2date will fetch all headers from all repositories, but *not* those from apt repositories. As a result, it won't have headers for the package already installed, and will eventually fail dep resolution. Or does it does for me. Wiping out the contents of /var/spool/up2date actually fixes the problem, but one shouldn't have to do this every time dep resolution is needed, right? ;-)
Err... Just for correctness, I haven't actually observed the problem on rawhide, but rather on boxes that were running FC3. I was confused because I happened to install rawhide yesterday, when I also added apt repo to sources of all my boxes, and today problems showed up on all the FC3 ones. I still haven't updated the rawhide boxes, and now I've switched from apt to yum for the selected repo, so I'm sure I won't observe the problem on rawhide, for now. Oh well...
Note that FC2 is no longer supported even by Fedora Legacy. Also, up2date has been replaced by pirut and pup since FC5. FC3 and FC4 are supported by Fedora Legacy for security issues only. If this still occurs on FC3 or FC4 and is a security issue, please reopen and assign to that version and Fedora Legacy. If it occurs on RHEL 3 or 4, please reassign or refile against that product. The codebase for pirut and pup is quite different, so existing bugs do not apply, but please continue testing them on the still supported versions of Fedora Core and file bugs as necessary.