[lmi] winediag:getaddrinfo Failed to resolve your host name IP

[Greg Chicares]

Since upgrading from DSL to fiber the other day, I get this
when running any command that involves 'wine':
  002c:err:winediag:getaddrinfo Failed to resolve your host name IP
after a delay of twenty seconds per 'wine' command. That happens even
in pure GNU/Linux builds, and even for
  $ make $coefficiency LMI_COMPILER=gcc LMI_TRIPLET=x86_64-pc-linux-gnu 
check_concinnity
which has as a prerequisite 'custom_tools:', whose recipe contains:
        @[ "$$LMI_TRIPLET" = "x86_64-pc-linux-gnu" ] \
          || ($(ECHO) "'$@' requires x86_64-pc-linux-gnu." && false)
        @$(MAKE) test_coding_rules
In that command:
 - first, 'make' reads 'GNUmakefile', which causes 'set_toolchain.sh'
   to set the triplet to 'gcc_x86_64-w64-mingw32', so it invokes
   'winepath' to set $WINEPATH;
 - then, after the 'winediag:getaddrinfo' timeout, a recursive 'make'
   recognizes the intended triplet and does the right thing.

There are two problems here.

(1) The 'wine' error is due to a change in the last octet of the
new router address. The GNU/Linux host adapted automatically--both
thunderbird and firefox work--but not 'wine'. Let's try restarting:

/opt/lmi/bin[0]$wineboot --restart
002c:err:winediag:getaddrinfo Failed to resolve your host name IP
00fc:err:winediag:getaddrinfo Failed to resolve your host name IP

/opt/lmi/bin[0]$wineboot --shutdown
002c:err:winediag:getaddrinfo Failed to resolve your host name IP

The same problem occurs in a freshly-entered instance of the same
chroot. And it's not actually specific to 'wine': 'curl' is also
affected, inside the chroot:

  $ curl https://git.savannah.nongnu.org:443           
  curl: (6) Could not resolve host: git.savannah.nongnu.org

though it works fine for the host system:

  $ curl https://git.savannah.nongnu.org:443
  [...] <h1>This is GNU Savannah's GIT repository server</h1> [...]

Editing the chroot's '/etc/hosts', I add a line taken from the
host system's '/etc/hosts':

 127.0.0.1       localhost
+127.0.1.1       $(hostname).$(dnsdomainname)        $(hostname)

[using literal values instead of variable names like $(hostname)]

and now 'wine' commands work as expected, with no delay and without
the subject error message. However, the 'curl' command above still
fails as before. In the chroot, as root, I try this, to no avail:

  # service network-manager restart
  network-manager: unrecognized service

Let's see if 'wget' works:

  # wget -N -nv 
https://github.com/let-me-illustrate/lmi/raw/master/lmi_setup_00.sh
  wget: unable to resolve host address ‘github.com’

It doesn't. Let's copy the host system's 'hosts' file:

  # cp -a /etc/hosts /srv/chroot/lmi_bookworm_5/etc/hosts

and then try 'wget' again in the chroot:

  # wget -N -nv 
https://github.com/let-me-illustrate/lmi/raw/master/lmi_setup_00.sh
  wget: unable to resolve host address ‘github.com’

So, even though the 'wine' problem seems to have been fixed, in the
chroot I can't even do this:

  $ git fetch
  fatal: unable to look up git.savannah.nongnu.org (port 9418) (Temporary 
failure in name resolution)

For the record, here's the complete but somewhat obfuscated '/etc/hosts':

$< /etc/hosts sed -e"s/$(hostname)/HOST/g" -e"s/$(dnsdomainname)/DNSDOM/g"
127.0.0.1       localhost
127.0.1.1       HOST.DNSDOM     HOST

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I guess my next step will be to create a new chroot.

I think I've solved the second problem, though:

(2) When $LMI_TRIPLET is specified on the 'make' command line, e.g.:
  $ make $coefficiency LMI_COMPILER=gcc LMI_TRIPLET=x86_64-pc-linux-gnu 
check_concinnity
the overridden variables are intended to be passed along this chain:
  GNUmakefile --> transume_toolchain.sh --> set_toolchain.sh
but they actually aren't passed to the initial instance of 'make',
and never have been:

  $ unset LMI_COMPILER
  $ unset LMI_TRIPLET
  $ make LMI_COMPILER=gcc LMI_TRIPLET=x86_64-pc-linux-gnu show_env
  Internal make variables particular to lmi:

  LMI_COMPILER    = "gcc"
  LMI_TRIPLET     = "x86_64-pc-linux-gnu"
  coefficiency    = "--jobs=32"
  PATH            = 
"/opt/lmi/local/gcc_x86_64-w64-mingw32/bin:/opt/lmi/local/gcc_x86_64-w64-mingw32/lib:/usr/bin:/bin:/usr/sbin:/sbin"
  WINEPATH        = 
"Z:\opt\lmi\local\gcc_x86_64-w64-mingw32\bin;Z:\opt\lmi\local\gcc_x86_64-w64-mingw32\lib"

Here, $WINEPATH should be empty, and $PATH should not contain
"/opt/lmi/local/gcc_x86_64-w64-mingw32". With this change:

 LMI_ENV_FILE := /tmp/lmi_env_$(shell date -u +'%s_%N').eraseme
-$(shell $(srcdir)/transume_toolchain.sh > $(LMI_ENV_FILE))
+$(shell \
+  LMI_COMPILER="$(LMI_COMPILER)" \
+   LMI_TRIPLET="$(LMI_TRIPLET)" \
+  $(srcdir)/transume_toolchain.sh > $(LMI_ENV_FILE) \
+ )
 include $(LMI_ENV_FILE)

they are passed as has always been intended:

  PATH            = 
"/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin:/opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib:/usr/bin:/bin:/usr/sbin:/sbin"
  WINEPATH        = ""

That defect affected only the first instance of 'make', but not
any submakes. That's why it was never noticed before--binaries
are actually built in submakes--even though it had always been
reproducible with the 'show_env' target, which executes no
submake.