commit 42c1dbb911d4d1bb8c392049bc50d0a5c6a67b2d
parent 59fcc51f74233be2a92f78dd2d272e8f2eaf95de
Author: Vincent Demeester <vincent@sbr.pm>
Date: Tue, 26 May 2020 11:43:16 +0200
Update readme and tasks 🙃
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Diffstat:
3 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/README.md b/README.md
@@ -74,7 +74,7 @@ soon-ish 👼):
Most of the `make` commands will try to populate this ahead of time. The assumption is :
have a `sync` folder where the assets are. *Note: how to bootstrap (as syncthing will
not be there, and the `sync` folder either)*
-- `docs`: holds documentation about this code, literate configuration, see [literate configuration](#org37b6917).
+- `docs`: holds documentation about this code, literate configuration, see [literate configuration](#org11396b9).
`make publish` will publish the `README.org` and the `docs` folder to my website.
- `lib`: shared code used during configuration (mostly `nix` code).
- `machines`: configuration per machines
@@ -84,7 +84,7 @@ soon-ish 👼):
- `private`: holds non-shareable code, like *secrets*.
- `tmp`: things to… organize (e.g. where I import my other *legacy* configuration)
-<a id="org37b6917"></a>As I'm slowly, but <span class="underline">surely</span>, going to have `org-mode` files for
+<a id="org11396b9"></a>As I'm slowly, but <span class="underline">surely</span>, going to have `org-mode` files for
literate configuration files in this repository, I have to think of how to organize files
in order to end up with one huge file. The goal of having those `org-mode` files, is
mainly to document my configuration and publish it, most likely on [sbr.pm](https://sbr.pm).
@@ -101,6 +101,7 @@ Repositories
- <https://github.com/davidtwco/veritas>
- <https://gitlab.com/samueldr/nixos-configuration>
- <https://github.com/rasendubi/dotfiles>
+- [https://github.com/yurrriq/dotfiles](https://github.com/yurrriq/dotfiles)
- <https://github.com/akirak/nixos-config>
- <https://github.com/akirak/home.nix>
- <https://github.com/cstrahan/nixos-config>
diff --git a/README.org b/README.org
@@ -93,6 +93,7 @@
- [[https://github.com/davidtwco/veritas]]
- [[https://gitlab.com/samueldr/nixos-configuration]]
- [[https://github.com/rasendubi/dotfiles]]
+- [[https://github.com/yurrriq/dotfiles][https://github.com/yurrriq/dotfiles]]
- [[https://github.com/akirak/nixos-config]]
- [[https://github.com/akirak/home.nix]]
- [[https://github.com/cstrahan/nixos-config]]
diff --git a/tasks.org b/tasks.org
@@ -265,7 +265,11 @@
nixos-unstable. =nixos-20.03= with being able to use =unstable= package seems to be the
safest bet.
-** TODO Define a plan to experiment with this
+** DONE Define a plan to experiment with this
+CLOSED: [2020-05-26 Tue 10:36]
+:LOGBOOK:
+- State "DONE" from "TODO" [2020-05-26 Tue 10:36]
+:END:
The main requirement is that /while experimenting/, it should not affect the rest of the
machines. [[https://github.com/lovesegfault/nix-config][lovesegfault/dotfiles]] is a good idea to follow as I can keep the current
@@ -291,21 +295,48 @@
nixos-unstable machine and the rest more stable (servers, …). Also let's make sure we
document this all the way (litterate configuration).
-** TODO Bootstrap =hokkaido.nix= machine file
+** DONE Bootstrap =hokkaido.nix= machine file
+CLOSED: [2020-05-26 Tue 10:36]
+:LOGBOOK:
+- State "DONE" from "TODO" [2020-05-26 Tue 10:36]
+:END:
- Being able to do =nix-build -A hokkaido=
- Use nixos-20.30 as base
-** TODO Create switch script
+** DONE Create switch script
+CLOSED: [2020-05-26 Tue 10:36]
+:LOGBOOK:
+- State "DONE" from "TODO" [2020-05-26 Tue 10:36]
+:END:
Being able to do =switch= (or =make -C Makefile.new switch=, or whatever)
-** TODO Try to use =nixos-unstable= as base
+** DONE Try to use =nixos-unstable= as base
+CLOSED: [2020-05-26 Tue 10:36]
+:LOGBOOK:
+- State "DONE" from "TODO" [2020-05-26 Tue 10:36]
+:END:
+
+** TODO [#B] home-manager on fedora situation
+
+How to make it self contained too.
+
+** TODO [#A] How to manage secrets
-** TODO How to manage secrets
+Right now, I have a boolean to detect if I am on ci or not. It's not the best because I
+don't test all.
** TODO Define CI (where, how)
+… and cache.
+
+- For packages builds.sr.ht is good
+- For systems, we can build it on builds.sr.ht *but* we could use a /local/ builder
+ machine to build the systems and cache built things.
+
+** TODO Migrate other machines/systems to it
+
* CANCELED =ci.nix= build on multiple channels
CLOSED: [2020-05-22 Fri 13:55]
:LOGBOOK:
