[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix on Android, getaddrinfo, failure in name resolution
From: |
白い熊 |
Subject: |
Re: Guix on Android, getaddrinfo, failure in name resolution |
Date: |
Fri, 15 Feb 2019 13:06:35 +0000 |
On February 14, 2019 9:20:52 PM UTC, "白い熊@相撲道" <address@hidden> wrote:
>>Anything else I can debug?
>
>I ran guix's ncsd on another terminal in debug mode. This is what
>happens when guix fails on the letsencrypt name resolution:
>
>Thu Feb 14 21:16:54 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15460
>Thu Feb 14 21:16:54 2019 - 15215: GETFDPW
>Thu Feb 14 21:16:54 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15460
>Thu Feb 14 21:16:54 2019 - 15215: GETPWBYUID (10224)
>Thu Feb 14 21:16:54 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15589
>Thu Feb 14 21:16:54 2019 - 15215: GETFDGR
>Thu Feb 14 21:16:54 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15589
>Thu Feb 14 21:16:54 2019 - 15215: GETGRBYNAME (guixbuild)
>Thu Feb 14 21:16:56 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15595
>Thu Feb 14 21:16:56 2019 - 15215: GETFDHST
>Thu Feb 14 21:16:56 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15595
>Thu Feb 14 21:16:56 2019 - 15215: GETFDSERV
>Thu Feb 14 21:16:56 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15595
>Thu Feb 14 21:16:56 2019 - 15215: GETSERVBYNAME (https/tcp)
>Thu Feb 14 21:16:56 2019 - 15215: handle_request: request received
>(Version = 2) from PID 15595
>Thu Feb 14 21:16:56 2019 - 15215: GETAI (letsencrypt.org)
>
>So, it seems it's resolving. What could be the problem?
It must be something peculiar with respect to some library I guess — that
should be linked and provide something to guix, which doesn't happen in the
Android terminal.
I'm led to this conclusion based on the following testing I did:
I chrooted in the Android terminal to a Debian armhf rootfs — ran the guix pull
from a clean Guix install there — and it pulls everything, doesn't fail on this
letsencrypt step — so it's not that the network would be inaccessible…
What is causing this? I have nscd running with /etc/nsswitch.conf present, so
that's not it… :@(
As a side note — in the chroot the pull fails on building curl as curl bombs on
tests. Many substitutes before that are pulled. I have ci.guix.info authorized
for substitutes — is it possible that curl isn't available yet? — it's kind of
a base package. Is there a way around this? I was hoping to finish “guix pull”
in the chroot — then copy /gnu and /var/guix to the Android FS and then go from
there — as the blocker with letsencrypt would be gone. Now I can't advance past
the failed build of curl.
--
白い熊
- Re: Guix on Android, getaddrinfo, failure in name resolution, Ludovic Courtès, 2019/02/12
- Re: Guix on Android, getaddrinfo, failure in name resolution, 白い熊@相撲道, 2019/02/13
- Re: Guix on Android, getaddrinfo, failure in name resolution, 白い熊@相撲道, 2019/02/14
- Re: Guix on Android, getaddrinfo, failure in name resolution, 白い熊, 2019/02/14
- Re: Guix on Android, getaddrinfo, failure in name resolution, 白い熊@相撲道, 2019/02/14
- Re: Guix on Android, getaddrinfo, failure in name resolution,
白い熊 <=