[bug#54335,14/14] gnu: Add nebula.

  * gnu/packages/networking.scm (nebula): New variable.
---
 gnu/packages/networking.scm | 80 +++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)
  

Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> +    (native-inputs
> +     (list go-gopkg-in-yaml-v3
> +           go-golang-org-x-term
> +           go-github-com-prometheus-common
> +           go-github-com-pmezard-go-difflib
> +           go-github-com-matttproud-golang-protobuf-extensions
> +           go-github-com-davecgh-go-spew
> +           go-gopkg-in-yaml-v2
> +           go-google-golang-org-protobuf
> +           go-golang-org-x-sys
> +           go-golang-org-x-net
> +           go-golang-org-x-crypto
> +           go-github-com-vishvananda-netns
> +           go-github-com-vishvananda-netlink
> +           go-github-com-skip2-go-qrcode
> +           go-github-com-stretchr-testify
> +           go-github-com-songgao-water
> +           go-github-com-sirupsen-logrus
> +           go-github-com-rcrowley-go-metrics
> +           go-github-com-prometheus-procfs
> +           go-github-com-prometheus-client-model
> +           go-github-com-prometheus-client-golang
> +           go-github-com-nbrownus-go-metrics-prometheus
> +           go-github-com-miekg-dns
> +           go-github-com-imdario-mergo
> +           go-github-com-google-gopacket
> +           go-github-com-gogo-protobuf
> +           go-github-com-flynn-noise
> +           go-github-com-cyberdelia-go-metrics-graphite
> +           go-github-com-cespare-xxhash-v2
> +           go-github-com-armon-go-radix
> +           go-github-com-anmitsu-go-shlex))

I doubt that all of these are compile-time tools.  At least most of
them are probably inputs.  (The distinction is important for cross-
compilation.)

Greetings,
Maxime.
  

Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> +  ;; NOTE: does not include nebula-service, which is incompatible with
> +  ;; Shepherd.

What does this mean?  Do you mean there's no corresponding Shepherd
service?  If so, perhaps people can still run the 'nebula-service'
binary directly?

Greetings,
Maxime.
  

Dominic Martinez schreef op do 10-03-2022 om 22:47 [-0500]:
> +     "Nebula is a scalable overlay networking tool with a focus on performance,
> +simplicity and security.  It lets you seamlessly connect computers anywhere in
> +the world.  Nebula is portable, and runs on Linux, OSX, Windows, iOS, and
> +Android.

Android is just a form of Linux with an unusual userspace, so no need
to mention it here.  Also,

>   It can be used to connect a small number of computers, but is also
> +able to connect tens of thousands of computers.")

This description reads like marketing talk (unqualified ‘seamless’,
‘performance’, ‘simplicity’, ‘security’).  The seamless seems factually
incorrect, since there is not corresponding Shepherd service.
 
As requested in (guix)Synopses and Descriptions, could the marketing be
left out, instead staying factual and descriptive?

E.g., you could look at the descriptions of 'yggdrasil', 'gnunet', 'go-
ipfs' and 'wireguard' and see if some things could be reused, or if
some things are out-of-scope or missing in Nebula and mention that.

Also, there are some binaries in 'dist/windows/wintun' -- even non-
free!

Greetings,
Maxime.
  

Maxime Devos <maximedevos@telenet.be> writes:

> I doubt that all of these are compile-time tools.  At least most 
> of
> them are probably inputs.  (The distinction is important for 
> cross-
> compilation.)

I think I'm confused on how to approach this because Go produces 
statically linked binaries. A lot of other Go packages also seem 
to use native-inputs. How does this interact with 
cross-compilation? All the inputs are used as source libraries 
here so I'm not sure how to tell if a runtime input is needed.
  

Maxime Devos <maximedevos@telenet.be> writes:

> This description reads like marketing talk (unqualified 
> ‘seamless’,
> ‘performance’, ‘simplicity’, ‘security’).  The seamless seems 
> factually
> incorrect, since there is not corresponding Shepherd service.
>
> As requested in (guix)Synopses and Descriptions, could the 
> marketing be
> left out, instead staying factual and descriptive?
>
> E.g., you could look at the descriptions of 'yggdrasil', 
> 'gnunet', 'go-
> ipfs' and 'wireguard' and see if some things could be reused, or 
> if
> some things are out-of-scope or missing in Nebula and mention 
> that.

Sure thing; I used the upstream description, so I'll write my own 
more consistent with Guix's guidelines.

> Also, there are some binaries in 'dist/windows/wintun' -- even 
> non-
> free!

Oh shoot! I removed the wintun and wireguard Windows dependencies 
but it looks like some Windows code still snuck in somewhere; I'll 
patch that out.
  

Maxime Devos <maximedevos@telenet.be> writes:

>> +  ;; NOTE: does not include nebula-service, which is 
>> incompatible with
>> +  ;; Shepherd.
>
> What does this mean?  Do you mean there's no corresponding 
> Shepherd
> service?  If so, perhaps people can still run the 
> 'nebula-service'
> binary directly?

Sorry, that was confusing. The nebula-service tool is used for 
setting up auto-start on multiple platforms. It's mainly useful on 
Windows and Mac as it's more difficult to create services on those 
platforms. I didn't think it was especially useful to include as 
on Linux it just creates a simple systemd service, and naturally 
can't create a shepherd service
  

Also, thank you so much for the very thorough review! This is 
pretty much my first big open-source contribution, so it's very 
helpful to get all the feedback :).
  

Dominic Martinez schreef op vr 11-03-2022 om 15:53 [-0500]:
> Maxime Devos <maximedevos@telenet.be> writes:
> 
> > I doubt that all of these are compile-time tools.  At least most 
> > of
> > them are probably inputs.  (The distinction is important for 
> > cross-
> > compilation.)
> 
> I think I'm confused on how to approach this because Go produces 
> statically linked binaries. A lot of other Go packages also seem 
> to use native-inputs. How does this interact with 
> cross-compilation? All the inputs are used as source libraries 
> here so I'm not sure how to tell if a runtime input is needed.

Static linking is not relevant to inputs/native-inputs -- Guix inputs
don't have a build-time/runtime distinction (*), instead they have a
the-architecture-it-is-being-built-on/the-architecture-it-is-built-for
distinction.  'inputs' = compiled for --target, 'native-inputs' =
compiled for --system.

(*) ignoring complications introduced by propagation.

More concretely, consider the following case:

  * a program A depends on the Go library B
  * the Go library B depends on the C library libfoo (using whatever is
    Go's equivalent of 'dlopen')
  * to avoid things like LD_LIBRARY_PATH, the package definition in
    Guix replaces 'libfoo.so' by '/gnu/store/.../libfoo.so'.
  * the program A is being cross-compiled.

To make sure that the cross-compiled A ends up using the libfoo.so
compiled for --target instead of --system, B has to be in 'inputs'
instead of 'native-inputs'.

This also holds when no .so libraries are used, e.g. if B invokes some
kind of binary with Go's equivalent of 'posix_spawn' and Guix hardcodes
the binary location instead of relying on $PATH.

I haven't tried this for Go packages in particular, but this is how
things work for, say, C and Guile packages.

Greetings,
Maxime.
  

Dominic Martinez schreef op vr 11-03-2022 om 16:02 [-0500]:
> Maxime Devos <maximedevos@telenet.be> writes:
> 
> > > +  ;; NOTE: does not include nebula-service, which is 
> > > incompatible with
> > > +  ;; Shepherd.
> > 
> > What does this mean?  Do you mean there's no corresponding 
> > Shepherd
> > service?  If so, perhaps people can still run the 
> > 'nebula-service'
> > binary directly?
> 
> Sorry, that was confusing. The nebula-service tool is used for 
> setting up auto-start on multiple platforms. It's mainly useful on 
> Windows and Mac as it's more difficult to create services on those 
> platforms. I didn't think it was especially useful to include as 
> on Linux it just creates a simple systemd service, and naturally 
> can't create a shepherd service

Ok that does indeed sound like something that is unlikely to work in
Guix, though keep in mind that Guix can be used on top of other
distros, possibly distros using SystemD (e.g. this mail is composed on
Debian+Guix), so it might be useful after all, though I don't consider
it in any way essential.

Greetings,
Maxime.