Replacing nixcfg with libkookierebuild

Generally, nixcfg grew out of a dotfiles repository, that happened to
also have some scripts in it. As more and more of the configuration
was replaced with nix specifics (home-manager, etc...), so did nixcfg
change over time (previously "stuff").

As part of this, kookiepkgs was introduced along-side nixcfg, to make
it easier to add custom things to nixpkgs-based systems
(NixOS). Additionally, the core system configuration was handled via
private infrastructure repositories, each specific to the machine in
question.

The problem with this approach is a lot of redundancy when building
non-userspace (read home-manager) systems and a lot of chaos with
having to cherry-pick commits from different branches to work with
nixpkgs trees in development.

Ultimately, keeping both new package definitions, patches and
configuration for the root system and userspace (home-manager) in the
same repository is a _much_ better approach to solving these issues.

And as such, libkookie was started: the general idea is that it
includes all nix expressions that are relevant to _any_ of my
computers. Under `roots`, a machine can have it's primary
configuration file which is built andcopied into the nix store, so
that nixpkgs can always point at the version a generation was built
with, not what is on disk).

Overlays contains everything that kookiepkgs used to, modules contains
both system-level modules (only required on NixOS), as well as
anything that is being built with home-manager. Modules are all kept
in the same tree, however some require system-level access while
others don't. There could be some kind of list to distinguish the two,
so that userspace-only systems can still take advantage of libkookie.

1 files changed, 54 insertions, 0 deletions

diff --git a/overlays/kookie/invoice/README.md b/overlays/kookie/invoice/README.md
new file mode 100644
index 00000000000..500fb5929fe
--- /dev/null
+++ b/overlays/kookie/invoice/README.md
@@ -0,0 +1,54 @@
+# invoice
+
+A tool that generates invoices with `pandoc`, `xelatex` and `yaml`.
+A descriptor file is required in order to make all of this work.
+These are independent of the tooling and template and should be
+client specific. Following is a small example of what it should
+look like:
+
+```yaml
+---
+invoice-nr: 2019-1234
+date: 2019-06-09
+author: Alice Anonymous
+city: Metropolis
+from:
+- Cyberstreet 69
+- XX51F5 Metropolis
+- alice.anonymous@mail.cyber
+- + 69 (0) 13 37 13 12
+ustid: Your Tax ID here
+bank: Evil Bank (i.e. a bank)
+bank_iban: Your IBAN
+bank_bic: Your Bank BIC
+to:
+- Client Name
+- Client Address
+- ...
+VAT: 19 # Depends on the country you live in
+service:
+- description: Looking cool
+  price: 255
+  details:
+    - Making all your other employees look silly
+    - Telling really bad jokes
+- description: Being awesome
+  price: 615
+  details: Its in the title!
+
+currency: EUR
+lang: english
+
+# Typography and layout
+fontsize: 10pt
+geometry: a4paper, left=43mm, right=43mm, top=51mm, bottom=17mm
+---
+```
+
+Then point the script at this descriptor:
+
+```
+$ invoice clients/client_name.yml
+```
+
+This will then generate `clients/client_name.pdf` as an invoice