all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: 白い熊 <help-guix_gnu.org@sumou.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: help-guix@gnu.org
Subject: Re: Guix on Android, getaddrinfo, failure in name resolution
Date: Fri, 15 Feb 2019 13:06:35 +0000	[thread overview]
Message-ID: <FA9E9267-D5C1-49C8-A8D1-AE84530C96D0@sumou.com> (raw)
In-Reply-To: <C64D6FBF-EFF0-4D7B-A57A-ED1A6AC44D19@sumou.com>



On February 14, 2019 9:20:52 PM UTC, "白い熊@相撲道" <help-guix_gnu.org@sumou.com> 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. 
--
白い熊

      reply	other threads:[~2019-02-15 13:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7DD810A8-FBFF-4609-981B-AD6169C384AB@sumou.com>
2019-01-15 14:39 ` Guix on Android, getaddrinfo, failure in name resolution 白い熊
2019-01-15 15:30   ` Julien Lepiller
2019-01-15 17:13     ` 白い熊
2019-01-15 17:24       ` Julien Lepiller
2019-01-15 17:53         ` 白い熊
2019-01-15 18:03           ` Julien Lepiller
2019-01-15 19:43             ` 白い熊
2019-01-16 18:33               ` 白い熊
2019-01-15 17:26       ` 白い熊
2019-01-19 22:34     ` Ludovic Courtès
2019-01-20 14:21       ` 白い熊@相撲道
2019-02-12 16:16         ` Ludovic Courtès
2019-02-13 18:19           ` 白い熊@相撲道
2019-02-14 13:54             ` 白い熊@相撲道
2019-02-14 13:55               ` 白い熊
2019-02-14 21:20               ` 白い熊@相撲道
2019-02-15 13:06                 ` 白い熊 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FA9E9267-D5C1-49C8-A8D1-AE84530C96D0@sumou.com \
    --to=help-guix_gnu.org@sumou.com \
    --cc=help-guix@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.