Your message dated Thu, 12 Jan 2017 19:54:25 +0000 with message-id <[email protected]> and subject line Re: Bug#479144: libc6-i386: in some 32bit apps, resolving fails when lib32nss-mdns is not installed has caused the Debian Bug report #479144, regarding libc6-i386: in some 32bit apps, resolving fails when lib32nss-mdns is not installed to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 479144: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479144 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libc6-i386 Version: 2.7-10 Severity: important hi This bug was found when trying to use the upstream binary of firefox 3.0 inside a amd64 Debian (or Ubuntu). In some situations, firefox cannot resolve hostnames (and is then completely unusable). Here is the bug, as described by Sylvain Pasche in https://bugzilla.mozilla.org/show_bug.cgi?id=414197 vvvvvvvv I've been seeing this on Ubuntu Hardy 8.04 64bit too. Any trunk or branch 32bit build fails to resolve hostnames. After some debugging I could isolate that the getaddrinfo() libc call is always failing to resolve anything. I turns out I was missing the lib32nss-mdns package. The /etc/nsswitch.conf default configuration contains: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 So without the lib32nss-mdns package, the libc can't load the mdns4_minimal module and aborts the resolution. ^^^^^^^^ Actually, according to the document 'info libc "Actions in the NSS configuration"' if the module mdns4_minimal is not available, then the behaviour should be: `unavail' The service is permanently unavailable. This can either mean the needed file is not available, or, for DNS, the server is not available or does not allow queries. The default action is `continue'. but unfortunately (as reported long ago in bug 365048), the above does not work. I see two ways to solve this bug. 1) libc6-i386 should depend on lib32nss-mdns 2) the affected line in /etc/nsswitch.conf be changed to hosts: files dns mdns4 3) fix bug 365048 Any of the two above changes fix the problem. a. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-i386 depends on: ii libc6 2.7-10 GNU C Library: Shared libraries libc6-i386 recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Wed, 12 Jun 2013 at 10:45:42 +0100, Simon McVittie wrote: > > I turns out I was missing the lib32nss-mdns package. The /etc/nsswitch.conf > > default configuration contains: > > > > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 > > > > So without the lib32nss-mdns package, the libc can't load the mdns4_minimal > > module and aborts the resolution. > > As of current unstable eglibc, this seems to work fine: if I add > "foo [NOTFOUND=return] bar" to my hosts nsswitch configuration > (before mdns* or dns), hosts resolution continues to mdns* and dns, > whereas if I change that to "foo [UNAVAIL=return]", hosts resolution > stops working. > > I think this demonstrates that the missing "foo" module is now interpreted > as UNAVAIL, which means the configuration provided by nss-mdns is OK > with current eglibc, and I think we can close this? There has been no response, so I'm adding an automated test for this to the nss-mdns source package, and closing the bug. S
--- End Message ---
