A package picks up a non-master package - bug or intentional?

A package picks up a non-master package - bug or intentional?

[ng0]

Hi,

I just picked up gnunet-fuse again and the build behaves strange.

You have to know that I keep multiple versions of gnunet and related
packages in my GUIX_PACKAGE_PATH.
Normally I would expect that this:

+    (arguments
+     `(#:configure-flags
+       (list (string-append "--with-gnunet="
+                            (assoc-ref %build-inputs "gnunet")))))

just picks up the gnunet from within the master tree the package
definition itself is in.
But as I recently have build "gnunetgf-0.10.17731daf5" this is being
picked up instead as you can see here:

checking fuse.h usability... yes
checking fuse.h presence... yes
checking for fuse.h... yes
checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
configure: error: gnunet-fuse requires GNUnet
phase `configure' failed after 2.8 seconds


I wonder.. why? Is Guix just not clever enough and picks the first
fitting "gnunet" it finds and if already available its store path?

I need to build this with exactly 0.10.1 and not HEAD. HEAD of -fuse
would require HEAD of (gnunet) core, this is why this build fails.
-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: A package picks up a non-master package - bug or intentional?

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> I just picked up gnunet-fuse again and the build behaves strange.
>
> You have to know that I keep multiple versions of gnunet and related
> packages in my GUIX_PACKAGE_PATH.
> Normally I would expect that this:
>
> +    (arguments
> +     `(#:configure-flags
> +       (list (string-append "--with-gnunet="
> +                            (assoc-ref %build-inputs "gnunet")))))
>
> just picks up the gnunet from within the master tree the package
> definition itself is in.
> But as I recently have build "gnunetgf-0.10.17731daf5" this is being
> picked up instead as you can see here:
>
> checking fuse.h usability... yes
> checking fuse.h presence... yes
> checking for fuse.h... yes
> checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
> checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
> configure: error: gnunet-fuse requires GNUnet
> phase `configure' failed after 2.8 seconds
>
>
> I wonder.. why? Is Guix just not clever enough and picks the first
> fitting "gnunet" it finds and if already available its store path?

Guix doesn’t *look* for any packages, so it doesn’t need to be clever.
You *tell* it what exact package to use.  Only packages that you have
declared as inputs will be available.  To declare a package as an input
you add *the package itself* (by unquoting a symbol that evaluates to a
package value).  There is no ambiguity, neither at build time nor at
runtime of Guix.

The confusion here is probably in what package value the symbol in the
inputs resolves to.  And this depends on the modules that are loaded.
We would need to see the full package definition and see what values the
package variables correspond to.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: A package picks up a non-master package - bug or intentional?

[ng0]

On 17-02-15 22:24:58, Ricardo Wurmus wrote:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > I just picked up gnunet-fuse again and the build behaves strange.
> >
> > You have to know that I keep multiple versions of gnunet and related
> > packages in my GUIX_PACKAGE_PATH.
> > Normally I would expect that this:
> >
> > +    (arguments
> > +     `(#:configure-flags
> > +       (list (string-append "--with-gnunet="
> > +                            (assoc-ref %build-inputs "gnunet")))))
> >
> > just picks up the gnunet from within the master tree the package
> > definition itself is in.
> > But as I recently have build "gnunetgf-0.10.17731daf5" this is being
> > picked up instead as you can see here:
> >
> > checking fuse.h usability... yes
> > checking fuse.h presence... yes
> > checking for fuse.h... yes
> > checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
> > checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
> > configure: error: gnunet-fuse requires GNUnet
> > phase `configure' failed after 2.8 seconds
> >
> >
> > I wonder.. why? Is Guix just not clever enough and picks the first
> > fitting "gnunet" it finds and if already available its store path?
> 
> Guix doesn’t *look* for any packages, so it doesn’t need to be clever.
> You *tell* it what exact package to use.  Only packages that you have
> declared as inputs will be available.  To declare a package as an input
> you add *the package itself* (by unquoting a symbol that evaluates to a
> package value).  There is no ambiguity, neither at build time nor at
> runtime of Guix.
> 
> The confusion here is probably in what package value the symbol in the
> inputs resolves to.  And this depends on the modules that are loaded.
> We would need to see the full package definition and see what values the
> package variables correspond to.

Okay, I will send the patch tomorrow.

This is inside (gnu packages gnunet), so my personal modules aren't in
there. The package name 'gnunet' is unique:

ng0@wasp ~> guix package --search=gnunet

name: gnunet
version: 0.10.1
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: bluez-5.43 glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1
+ gnutls-3.5.4 gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9
+ libextractor-1.3 libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6
+ libmicrohttpd-0.9.52 libogg-1.3.2 libunistring-0.9.6 nss-3.27.1 openssl-1.0.2j
+ opus-1.1.4 perl-5.24.0 pkg-config-0.29 pulseaudio-9.0 python-2.7.12
+ sqlite-3.14.1 zlib-1.2.8
location: gnu/packages/gnunet.scm:263:2

name: gnunet-fuse
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 fuse-2.9.6 gettext-0.19.8.1
+ gnunetgf-0.10.17731daf5 libtool-2.4.6 pkg-config-0.29
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:337:4

name: gnunet-gtk
version: 0.10.1
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: glade-3.20.0 gnunet-0.10.1 gtk+-3.22.6 libextractor-1.3
+ libgcrypt-1.7.3 libglade-2.6.4 libunique-3.0.2 pkg-config-0.29 qrencode-3.4.4
location: gnu/packages/gnunet.scm:368:2

name: gnunet-gtk
version: 0.10.1
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: glade-3.20.0 gnunet-0.10.1 gtk+-3.22.6 libextractor-1.3
+ libgcrypt-1.7.3 libglade-2.6.4 libunique-3.0.2 pkg-config-0.29 qrencode-3.4.4
location: gnu/packages/gnunet.scm:368:2

name: gnunet-gtkg
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 gettext-0.19.8.1 glade-3.20.0
+ gnunetg-0.10.17731daf5 gnutls-3.5.4 gsettings-desktop-schemas-3.22.0
+ gtk+-3.22.6 libextractor-1.3 libgcrypt-1.7.3 libglade-2.6.4 libtool-2.4.6
+ libunique-3.0.2 pkg-config-0.29 qrencode-3.4.4
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:288:4

name: gnunetg
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216 ncurses-6.0 nss-3.27.1
+ openssl-1.0.2j opus-1.1.4 perl-5.24.0 pkg-config-0.29 pulseaudio-9.0
+ python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:58:4

name: gnunetgf
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216 mysql-5.7.17
+ ncurses-6.0 nss-3.27.1 openssl-1.0.2j opus-1.1.4 perl-5.24.0 pkg-config-0.29
+ postgresql-9.5.6 pulseaudio-9.0 python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:164:2

name: gnunetgft
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216 ncurses-6.0 nss-3.27.1
+ openssl-1.0.2j opus-1.1.4 perl-5.24.0 pkg-config-0.29 pulseaudio-9.0
+ python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:202:2

name: gnunetgftl
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libressl-2.5.0 libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216
+ ncurses-6.0 nss-3.27.1 opus-1.1.4 perl-5.24.0 pkg-config-0.29 postgresql-9.5.6
+ pulseaudio-9.0 python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:375:2

name: gnunetgftn
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216 ncurses-6.0 nss-3.27.1
+ openssl-1.0.2j opus-1.1.4 perl-5.24.0 pkg-config-0.29 pulseaudio-9.0
+ python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:245:2

name: gnunetgpg
version: 0.10.17731daf5
outputs: out debug
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-2.69 automake-1.15 bluez-5.43 gettext-0.19.8.1
+ glib-2.50.2 glpk-4.61 gmp-6.1.1 gnurl-7.52.1 gnutls-3.5.4
+ gst-plugins-base-1.10.3 gstreamer-1.10.3 jansson-2.9 libextractor-1.3
+ libgcrypt-1.7.3 libidn-1.33 libltdl-2.4.6 libmicrohttpd-0.9.52 libogg-1.3.2
+ libtool-2.4.6 libunistring-0.9.6 miniupnpc-2.0.20161216 ncurses-6.0 nss-3.27.1
+ openssl-1.0.2j opus-1.1.4 perl-5.24.0 pkg-config-0.29 postgresql-9.5.6
+ pulseaudio-9.0 python-2.7.12 sqlite-3.14.1 zlib-1.2.8
location: /home/ng0/src/packages/ng0/packages/gnunet.scm:155:2

name: guile-gnunet
version: 0.0.383eac2
outputs: out
systems: x86_64-linux i686-linux armhf-linux mips64el-linux
dependencies: autoconf-wrapper-2.69 automake-1.15 gnunet-0.10.1 guile-2.0.12
+ pkg-config-0.29
location: gnu/packages/gnunet.scm:333:4
 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: A package picks up a non-master package - bug or intentional?

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> On 17-02-15 22:24:58, Ricardo Wurmus wrote:
>> 
>> ng0 <contact.ng0@cryptolab.net> writes:
>> 
>> > I just picked up gnunet-fuse again and the build behaves strange.
>> >
>> > You have to know that I keep multiple versions of gnunet and related
>> > packages in my GUIX_PACKAGE_PATH.
>> > Normally I would expect that this:
>> >
>> > +    (arguments
>> > +     `(#:configure-flags
>> > +       (list (string-append "--with-gnunet="
>> > +                            (assoc-ref %build-inputs "gnunet")))))
>> >
>> > just picks up the gnunet from within the master tree the package
>> > definition itself is in.
>> > But as I recently have build "gnunetgf-0.10.17731daf5" this is being
>> > picked up instead as you can see here:
>> >
>> > checking fuse.h usability... yes
>> > checking fuse.h presence... yes
>> > checking for fuse.h... yes
>> > checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
>> > checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
>> > configure: error: gnunet-fuse requires GNUnet
>> > phase `configure' failed after 2.8 seconds
>> >
>> >
>> > I wonder.. why? Is Guix just not clever enough and picks the first
>> > fitting "gnunet" it finds and if already available its store path?
>> 
>> Guix doesn’t *look* for any packages, so it doesn’t need to be clever.
>> You *tell* it what exact package to use.  Only packages that you have
>> declared as inputs will be available.  To declare a package as an input
>> you add *the package itself* (by unquoting a symbol that evaluates to a
>> package value).  There is no ambiguity, neither at build time nor at
>> runtime of Guix.
>> 
>> The confusion here is probably in what package value the symbol in the
>> inputs resolves to.  And this depends on the modules that are loaded.
>> We would need to see the full package definition and see what values the
>> package variables correspond to.
>
> Okay, I will send the patch tomorrow.
>
> This is inside (gnu packages gnunet), so my personal modules aren't in
> there. The package name 'gnunet' is unique:
>
> ng0@wasp ~> guix package --search=gnunet

What matters is not the package name but the name (and value) of the
Scheme variable that is referenced in the inputs.  They are often
identical, but since we’re speaking of non-intuitive behaviour it may
well be that the names differ in this case.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

gnunet-fuse (was: Re: A package picks up a non-master package - bug or intentional?)

[ng0]

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

Hi,

patch file of the package in question attached.

On 17-02-16 08:46:46, Ricardo Wurmus wrote:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > On 17-02-15 22:24:58, Ricardo Wurmus wrote:
> >> 
> >> ng0 <contact.ng0@cryptolab.net> writes:
> >> 
> >> > I just picked up gnunet-fuse again and the build behaves strange.
> >> >
> >> > You have to know that I keep multiple versions of gnunet and related
> >> > packages in my GUIX_PACKAGE_PATH.
> >> > Normally I would expect that this:
> >> >
> >> > +    (arguments
> >> > +     `(#:configure-flags
> >> > +       (list (string-append "--with-gnunet="
> >> > +                            (assoc-ref %build-inputs "gnunet")))))
> >> >
> >> > just picks up the gnunet from within the master tree the package
> >> > definition itself is in.
> >> > But as I recently have build "gnunetgf-0.10.17731daf5" this is being
> >> > picked up instead as you can see here:
> >> >
> >> > checking fuse.h usability... yes
> >> > checking fuse.h presence... yes
> >> > checking for fuse.h... yes
> >> > checking for GNUnet core... /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5
> >> > checking for GNUnet util library in /gnu/store/xbvcn8fqp5l45dh5s32nmqmvbykahq7k-gnunetgf-0.10.17731daf5... checking for gnunet/gnunet_util_lib.h... no
> >> > configure: error: gnunet-fuse requires GNUnet
> >> > phase `configure' failed after 2.8 seconds
> >> >
> >> >
> >> > I wonder.. why? Is Guix just not clever enough and picks the first
> >> > fitting "gnunet" it finds and if already available its store path?
> >> 
> >> Guix doesn’t *look* for any packages, so it doesn’t need to be clever.
> >> You *tell* it what exact package to use.  Only packages that you have
> >> declared as inputs will be available.  To declare a package as an input
> >> you add *the package itself* (by unquoting a symbol that evaluates to a
> >> package value).  There is no ambiguity, neither at build time nor at
> >> runtime of Guix.
> >> 
> >> The confusion here is probably in what package value the symbol in the
> >> inputs resolves to.  And this depends on the modules that are loaded.
> >> We would need to see the full package definition and see what values the
> >> package variables correspond to.
> >
> > Okay, I will send the patch tomorrow.
> >
> > This is inside (gnu packages gnunet), so my personal modules aren't in
> > there. The package name 'gnunet' is unique:
> >
> > ng0@wasp ~> guix package --search=gnunet
> 
> What matters is not the package name but the name (and value) of the
> Scheme variable that is referenced in the inputs.  They are often
> identical, but since we’re speaking of non-intuitive behaviour it may
> well be that the names differ in this case.
> 
> -- 
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

[-- Attachment #2: 0001-gnu-Add-gnunet-fuse.patch --]
[-- Type: text/plain, Size: 1681 bytes --]

From b01415b2513d40f970269eb33393364d6d18a7e5 Mon Sep 17 00:00:00 2001
From: ng0 <ng0@we.make.ritual.n0.is>
Date: Mon, 19 Sep 2016 16:23:53 +0000
Subject: [PATCH] gnu: Add gnunet-fuse.

* gnu/packages/gnunet.scm (gnunet-fuse): New variable.
---
 gnu/packages/gnunet.scm | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm
index a4514a7f4..27ed58b6a 100644
--- a/gnu/packages/gnunet.scm
+++ b/gnu/packages/gnunet.scm
@@ -393,3 +393,32 @@ services.")
      `(("pkg-config" ,pkg-config)
        ("libglade" ,libglade)))
     (synopsis "Graphical front-end tools for GNUnet")))
+
+(define-public gnunet-fuse
+  (package
+    (name "gnunet-fuse")
+    (version "0.10.0")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "mirror://gnu/gnunet/gnunet-fuse-"
+                                  version ".tar.gz"))
+              (sha256
+               (base32
+                "0ggc2gkyd6qvd4a9z84xbynq5jajbldbx6qkh79k9zjiycz2ffbb"))))
+    (arguments
+     `(#:configure-flags
+       (list (string-append "--with-gnunet="
+                            (assoc-ref %build-inputs "gnunet")))))
+    (build-system gnu-build-system)
+    (inputs
+     `(("gnunet" ,gnunet)
+       ("fuse" ,fuse)))
+    (native-inputs
+     `(("pkg-config" ,pkg-config)))
+    (synopsis "Mount directories which are published on GNUnet")
+    (description
+     "GNUnet-fuse allows you to mount directories published on GNUnet
+as read-only file-systems on operating systems that support the
+FUSE API).")
+    (license license:gpl3+)
+    (home-page "https://gnunet.org/")))
-- 
2.11.1

Re: gnunet-fuse (was: Re: A package picks up a non-master package - bug or intentional?)

[Ricardo Wurmus]

ng0 <contact.ng0@cryptolab.net> writes:

> patch file of the package in question attached.

Thanks.  Applying this to current master and trying to build
“gnunet-fuse” should result in the error you reported, is that correct?

If so, I’ll give this a try and report back.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: gnunet-fuse (was: Re: A package picks up a non-master package - bug or intentional?)

[ng0]

On 17-02-17 17:10:23, Ricardo Wurmus wrote:
> 
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> > patch file of the package in question attached.
> 
> Thanks.  Applying this to current master and trying to build
> “gnunet-fuse” should result in the error you reported, is that correct?
> 
> If so, I’ll give this a try and report back.

I hope so! If it doesn't, using a checkout of
<https://pagure.io/packages> in your GUIX_PACKAGE_PATH will give you
exactly the situation I have.

Thanks

> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/