Francesco, this is not at all useful without further logs and traces; reopening the bugs you should have seen what information and research we've had to do to find the bug and that it was considered fixed for half a decade.
It is very likely that relevant regressions, if any and not real temporary issues, are caused by changes in the resolver rigging (name server, lwresd, whatever, plus nscd and other daemons used by the libc); and in that situation, I will need API documentation to the extent that it allows me, from fetchmail code, to reinitialize the resolver library. Nico, what is the resolver configuration in the fetchmail build, what daemons is libc supposed to use on the affected systems? Is lwresd involved? Francesco, I will also need further logs to evidence: - please show me the config.h and config.log (perhaps Nico can dig these out from buildd logs, too) - that the bug persists in fetchmail 6.3.26 which is the current upstream version, - the fetchmail configuration and logs per FAQ item #G3 (URL earlier in the bug), - a documentation of resolv.conf, host.conf, nsswitch.conf before/after changes, and how that relates to resolver trouble, - a proof that nscd is not running and providing negative cache entries, or is otherwise having its cache flushed when nsswitch.conf changes, - an ltrace excerpt showing how fetchmail is attempting to resolve the relevant names or reinitializing the resolver library (or not) - proof that other software can resolve the names in the very same instant (a fake poll entry with ssh for its plugin might do that). Best regards Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
