Name resolution failures during build

Name resolution failures during build

[Stephen Scheck]

I'm getting the following error when I try to install a package I'm working
on:

    go: github.com/BurntSushi/toml@v0.3.1: Get "
https://proxy.golang.org/github.com/%21burnt%21sushi/toml/@v/v0.3.1.mod":
dial tcp: lookup proxy.golang.org on [::1]:53: read udp
[::1]:43973->[::1]:53: read: connection refused

It uses `gnu-build-system`. Is there some package that needs to be added to
the build inputs for ordinary name resolution to work?

Re: Name resolution failures during build

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]


Stephen Scheck <singularsyntax@gmail.com> writes:

> I'm getting the following error when I try to install a package I'm working
> on:
>
>     go: github.com/BurntSushi/toml@v0.3.1: Get "
> https://proxy.golang.org/github.com/%21burnt%21sushi/toml/@v/v0.3.1.mod":
> dial tcp: lookup proxy.golang.org on [::1]:53: read udp
> [::1]:43973->[::1]:53: read: connection refused
>
> It uses `gnu-build-system`. Is there some package that needs to be added to
> the build inputs for ordinary name resolution to work?

To ensure that builds don't depend on the network, the build processes
don't have network access.

This could mean you're missing something in the build environment (an
input), or that there's an input being ignored (and the network is being
used to try and fetch it).

Does that make sense?

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Name resolution failures during build

[Stephen Scheck]

Sure - I understand the reasoning - but this is an open-source project with
its own build system that I'm trying to package, and I believe its build
system depends on network access (it's Go-based, and my understanding is
that the Go dependency model relies on access to numerous external Git
repos). Is such a project unsupportable by Guix?


On Fri, Nov 20, 2020 at 3:47 PM Christopher Baines <mail@cbaines.net> wrote:

>
> Stephen Scheck <singularsyntax@gmail.com> writes:
>
> > I'm getting the following error when I try to install a package I'm
> working
> > on:
> >
> >     go: github.com/BurntSushi/toml@v0.3.1: Get "
> > https://proxy.golang.org/github.com/%21burnt%21sushi/toml/@v/v0.3.1.mod
> ":
> > dial tcp: lookup proxy.golang.org on [::1]:53: read udp
> > [::1]:43973->[::1]:53: read: connection refused
> >
> > It uses `gnu-build-system`. Is there some package that needs to be added
> to
> > the build inputs for ordinary name resolution to work?
>
> To ensure that builds don't depend on the network, the build processes
> don't have network access.
>
> This could mean you're missing something in the build environment (an
> input), or that there's an input being ignored (and the network is being
> used to try and fetch it).
>
> Does that make sense?
>
> Chris
>

Re: Name resolution failures during build

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]


Stephen Scheck <singularsyntax@gmail.com> writes:

> Sure - I understand the reasoning - but this is an open-source project with
> its own build system that I'm trying to package, and I believe its build
> system depends on network access (it's Go-based, and my understanding is
> that the Go dependency model relies on access to numerous external Git
> repos). Is such a project unsupportable by Guix?

Not at all, there's a number of examples of software written in Go
packaged for Guix, it's just that you need to build it in a way that
doesn't depend on network access.

Keeping this as a hard requirement is one of the reasons why having Guix
packages is beneficial. If some packages used the network during builds,
you'd end up in the bad situation where packages would be far more
likely to fail to build, now or in the future, and it would be harder to
reason about build reproducibility (due to the interaction with the
network).
Message-ID: <87blfrk912.fsf@cbaines.net>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Name resolution failures during build

[Stephen Scheck]

The project I'm attempting to package is a standalone application, with a
Makefile build system entrypoint - it is not a library, so I don't think
`go-build-system` is of any help here (though presumably the Makefile uses
golang build machinery under the covers).

Do any examples of standalone applications written in Go that are already
packaged for Guix jump to mind?

On Fri, Nov 20, 2020 at 4:34 PM Christopher Baines <mail@cbaines.net> wrote:

>
> Stephen Scheck <singularsyntax@gmail.com> writes:
>
> > Sure - I understand the reasoning - but this is an open-source project
> with
> > its own build system that I'm trying to package, and I believe its build
> > system depends on network access (it's Go-based, and my understanding is
> > that the Go dependency model relies on access to numerous external Git
> > repos). Is such a project unsupportable by Guix?
>
> Not at all, there's a number of examples of software written in Go
> packaged for Guix, it's just that you need to build it in a way that
> doesn't depend on network access.
>
> Keeping this as a hard requirement is one of the reasons why having Guix
> packages is beneficial. If some packages used the network during builds,
> you'd end up in the bad situation where packages would be far more
> likely to fail to build, now or in the future, and it would be harder to
> reason about build reproducibility (due to the interaction with the
> network).
> Message-ID: <87blfrk912.fsf@cbaines.net>
>

Re: Name resolution failures during build

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Fri, Nov 20, 2020 at 05:55:50PM -0500, Stephen Scheck wrote:
> The project I'm attempting to package is a standalone application, with a
> Makefile build system entrypoint - it is not a library, so I don't think
> `go-build-system` is of any help here (though presumably the Makefile uses
> golang build machinery under the covers).
> 
> Do any examples of standalone applications written in Go that are already
> packaged for Guix jump to mind?
> 

Don't look at syncthing, it needs a bunch of hand holding to compile
correctly.

containerd and docker-cli in gnu/packages/docker.scm are two examples of
packages with binaries as outputs. I have a WIP package for keybase but
there's a large number of unpackaged dependencies so I've only gotten
some of them patched out.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Name resolution failures during build

[raingloom]

On Sat, 21 Nov 2020 21:22:09 +0200
Efraim Flashner <efraim@flashner.co.il> wrote:

> On Fri, Nov 20, 2020 at 05:55:50PM -0500, Stephen Scheck wrote:
> > The project I'm attempting to package is a standalone application,
> > with a Makefile build system entrypoint - it is not a library, so I
> > don't think `go-build-system` is of any help here (though
> > presumably the Makefile uses golang build machinery under the
> > covers).
> > 
> > Do any examples of standalone applications written in Go that are
> > already packaged for Guix jump to mind?
> >   
> 
> Don't look at syncthing, it needs a bunch of hand holding to compile
> correctly.
> 
> containerd and docker-cli in gnu/packages/docker.scm are two examples
> of packages with binaries as outputs. I have a WIP package for
> keybase but there's a large number of unpackaged dependencies so I've
> only gotten some of them patched out.
> 

I think Yggdrasil is a pretty clean example. It also uses a Makefile
wrapper, but really it just calls go build a bunch of times.