From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?55m944GE54aK?= Subject: Re: Guix on Android, getaddrinfo, failure in name resolution Date: Fri, 15 Feb 2019 13:06:35 +0000 Message-ID: References: <7DD810A8-FBFF-4609-981B-AD6169C384AB@sumou.com> <7A2A3304-5B19-47D6-91A8-960D60294C3B@sumou.com> <878szgqnsl.fsf@gnu.org> <87wom5htiz.fsf@gnu.org> <3E0B2470-CBB6-4F74-BDA7-8C6DC2B0EAE6@sumou.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:41083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gudCs-0001aH-NB for help-guix@gnu.org; Fri, 15 Feb 2019 08:07:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gudCm-0000Dx-Vz for help-guix@gnu.org; Fri, 15 Feb 2019 08:07:06 -0500 In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Cc: help-guix@gnu.org On February 14, 2019 9:20:52 PM UTC, "=E7=99=BD=E3=81=84=E7=86=8A=EF=BC=A0= =E7=9B=B8=E6=92=B2=E9=81=93" wrote: >>Anything else I can debug?=20 > >I ran guix's ncsd on another terminal in debug mode=2E This is what >happens when guix fails on the letsencrypt name resolution:=20 > >Thu Feb 14 21:16:54 2019 - 15215: handle_request: request received >(Version =3D 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 =3D 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 =3D 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 =3D 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 =3D 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 =3D 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 =3D 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 =3D 2) from PID 15595 >Thu Feb 14 21:16:56 2019 - 15215: GETAI (letsencrypt=2Eorg) > >So, it seems it's resolving=2E What could be the problem?=20 It must be something peculiar with respect to some library I guess =E2=80= =94 that should be linked and provide something to guix, which doesn't happ= en in the Android terminal=2E=20 I'm led to this conclusion based on the following testing I did:=20 I chrooted in the Android terminal to a Debian armhf rootfs =E2=80=94 ran = the guix pull from a clean Guix install there =E2=80=94 and it pulls everyt= hing, doesn't fail on this letsencrypt step =E2=80=94 so it's not that the = network would be inaccessible=E2=80=A6=20 What is causing this? I have nscd running with /etc/nsswitch=2Econf presen= t, so that's not it=E2=80=A6 :@( As a side note =E2=80=94 in the chroot the pull fails on building curl as = curl bombs on tests=2E Many substitutes before that are pulled=2E I have ci= =2Eguix=2Einfo authorized for substitutes =E2=80=94 is it possible that cur= l isn't available yet? =E2=80=94 it's kind of a base package=2E Is there a= way around this? I was hoping to finish =E2=80=9Cguix pull=E2=80=9D in the= chroot =E2=80=94 then copy /gnu and /var/guix to the Android FS and then g= o from there =E2=80=94 as the blocker with letsencrypt would be gone=2E Now= I can't advance past the failed build of curl=2E=20 -- =E7=99=BD=E3=81=84=E7=86=8A