[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. > 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. > > 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. :/ >> 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. :( 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. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
