On Tuesday 29 June 2010, Petter Reinholdtsen wrote: > [Frans Pop] > > So, one wget results in a 404. As choose-mirror tries various > > possible suites and codenames and wgets are used for other purposes > > as well, a 404 is always a possibility. > > Sure, but all the URLs listed in the log are working, so it seem > strange that one of them give 404.
So either it's due to a temporary mirror issue (which you'd want to know about), or it's from an unlogged wget. Or it's from a wget from a subprogram called by choose-mirror, in which case you patch won't even help. > > It's not bogus. It's a useful message for troubleshooting and > > debugging. The only thing that is a pity is that logging of the > > error messages to stderr gets delayed until the component completes. > > It is bogus, as all the URLs in the log are working when I test them > manually, and it is close to impossible to figure out what URL was > failing. No, it's not bogus. There *is* a wget that's failing. Whether it affects the end result of the install or not is another matter. wgets in choose-mirror can fail for various valid reasons. Most of them you want to know about for troubleshooting purposes. Examples are: (temporarily) broken mirrors, incomplete mirrors, broken proxies. I've seen 403s and 404s that have helped a lot tracing the cause of failed installs. Removing valid information from logs for cosmetic reasons is wrong. > > > The URLs in the log seem to work, so I do not understand why wget is > > > complaining. Is there some other wget calls that are not reported > > > to the log? > > > > Did you check the code? > > Yes. Only found the two mentioned in the patch, and neither seem to > use a non-existing URL. :/ So, you'll need to look a bit deeper. Usually we fix the *cause* of errors. We don't suppress errors for cosmetic reasons. > >> The only wget calls I find in choose-mirror do not throw away error > >> messages. Perhaps they should? If so, this untested patch should > >> implement it: > > > > NACK. The errors are too useful to suppress. > > I disagree. The error in question is almost useless. There is no way > to see which URL was missing, and the message show up in the wrong > location in the log. A useful error message would make it possible to > figure out what is wrong. This one do not. :( But it's currently all we have! And, as mentioned before, it *has* helped me a number of times in the past, both while tracing issues from installation reports and while debugging. Improving the error handling is valid. Simply removing the messages without replacing them with something else (better) is plain wrong. > If the error message continue to come from d-i, we need to filter it > out in debian-edu, but I thought it best to try to get rid of it > first. If you can't come up with a proper solution for choose-mirror then that is the correct way to go. The primary purpose of the syslog is to help users and developers to find the cause of issues. Removing real error messages for cosmetic reasons does not improve the installer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
