From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 Description of problem: For some reason, the source packages corresponding to some of the binary rpms appear to be missing, e.g., glibc-2.2.90-2.src.rpm. When up2date attempts to download these, it cannot find them. I've been working around it by linking a dummy .src.rpm under the name, but this requires restarting up2date. It would be preferable to have an option to ignore this particular error. But why are the packages not there? Version-Release number of selected component (if applicable): up2date-2.9.46 How reproducible: Always Steps to Reproduce: 1.up2date --nosig --src -u Actual Results: Dies when a required source rpm is not found. Updating from the original null install, the following are missing: glibc-2.2.92-2.src.rpm up2date-2.9.68-1.src.rpm strace-4.4-8.src.rpm rhnlib-0.9-1.src.rpm pygtk2-1.99.12-6.src.rpm libgnomeui-2.0.3-3.src.rpm libgnome-2.0.2-5.src.rpm gtkhtml2-2.0.1-2.src.rpm gnome-python2-1.99.11-7.src.rpm Expected Results: All source rpms ought to be present. Failing that, the program should be able to proceed gracefully. Additional info: I tried to update up2date first, but it kept generating an (unrelated) backtrace, so I downgraded back to the version from the iso.
beta issue. The src rpms werent pushed along with the bin rpms to the channel. Generally, I consider 404's as fatal errors, since it means that what the user requested be done can not be accomplished.
It still seems to me that one ought to attempt to download all the packages, total up the number of errors, and die with a count of the missing packages. It's a UI bug: if I ask up2date to download a gigabyte of data while I go to dinner, and I come back to find that's it only retrieved 1% of said data when 99+% was available, I'm greatly annoyed. How about a simple flag to continue downloading?