Timestamps currently display only the time, which is... fine, but can
be somewhat annoying to see how long ago something actually was. It's
possible to use timestamp.ago() to show how long ago a thing was as
well. Let's add it to our default timestamp formatter so we can see that
everywhere jujutsu shows us timestamps

I do Android development - the tools for it aren't in packetmix (see
https://github.com/CollaboraOnline/nix-build-support) but we still need
to persist the data here...

We've been using github CI for a while, let's translate everything to
tangled format so that we can move across!

We need to put our CI in the root of our monorepo as otherwise it won't
run on our tangled spindle...

We've been using https://reuse.software in packetmix for our licensing,
but we haven't made it work in the monorepo and we haven't got sprinkles
under it. Let's change that

We've seen some weird consequences which appear to be from setting the
base=main push option all the time - it's better to use some aliases or
something to set the options only when needed...

Workspaces are not the default filter when you clone a directory,
however we want them so we can have folders such as .tangled shared
between multiple workspaces. Therefore, we should recommend them for our
clone URLs

Sprinkles is widgets for our Niri desktop. Currently we're working on a
notification daemon, and we plan to move our clock out from PacketMix
into sprinkles as well...

Josh doesn't seem to be working correctly with cloning over SSH, but we
know it works for pushing. Therefore, we should mention git's support
for having a different push URL and recommend always cloning over HTTPS

We've exposed teal's SSH to the outside world, so it's now possible to
use the SSH push URL for josh

We don't capitalize our project names, with the exception of at the
start of sentences, so it's nice to make them italic: it makes them
stand out a little bit from the text around them

Additionally, several projects weren't linked/etc.

I've done that now :)

Josh does weird things when creating branches, it's worth documenting
them (particularly as we tend to use jujutsu where push option
specification has to be done via the git config)

Josh wants workspace files to exist before workspaces are cloned to
avoid rewriting commits, so let's add some...

We are moving over to tangled and want to have a spindle so that we can
run long builds like PacketMix needs :sweat_smile:

Midnight is our CI server so it makes sense to host the spindle on it,
proxied to the outside world via teal

We're reinstalling midnight! Previously we had the old hardware config
here, but that one didn't support impermanence and was pretty different
to teal's. As part of our reinstall we've repartitioned our disks to
have a much more similar layout...

We're reinstalling midnight, which means these routes will no longer
exist. They've all been migrated anyway...

When we start up headscale, it tries to connect to OIDC. If our OIDC
server is down, there were previously two options:
- We can fail to start the server altogether
- We can fallback to CLI auth and lose the ability to use OIDC until
headscale is restarted

Neither of these are what I want: I want us to start up anyway but not
allow registration until OIDC successfully connects

I've made a patch to do just that! I made it ontop of main, so I've also
had to upgrade headscale to allow use of this patch.

I had some troubles with nilla, which can't properly interpret the
headscale flake (missing rev/shortRev attributes) - therefore I've taken
the nix package definition from the headscale repo and updated it to use
the patch and the correct source manually

Refs: juanfont/headscale#1873

Officially switching over to builtin niri+xwayland satellite integration!
Yay! The update that brought the integration caused issues when launching
X applications due to ordering conflicts since Niri now sets `DISPLAY=:0`

This fixes a regression from tqywkonpmxyulxkyuyusqntrwomtkkxu
(9d7dfaabeb1b2cf9ddb4219a064e75b270b7926a). I accidentally put the
WantedBy in the Unit section rather than the Install section. This left
the unit starting on graphical-session.target rather than niri.service,
which prevented it starting due to the ordering loop...

...oops

Coded added a stopgap solution for walker starting before elephant. We
were still getting pretty bad startup performance, though, so I looked
into it.

It turned out a variety of things were needed to start walker faster:
- Moving to a systemd service was helpful, but only once walker had
started once, otherwise the socket would never connect and walker
wouldn't open at all
- Disabling file indexing by default was necessary for systems with lots
of files in home (for example LibreOffice clones). If you want to add
file indexing back for yourself, I recommend you figure out where your
large files are and use '.ignore' files (.gitignore syntax) to ignore
them
- Elephant needed to be started properly - after niri so WAYLAND_DISPLAY
was set but not in the ordering cycle on graphical-session.target. I
used the same settings as we have for ssh-agent, say

Because of all of this, I also factored walker out into its own file.

This additionally marks

- The first keybind moved outside of the niri.nix file
- The first keybind to be created with Mod rather than ${mod} (= Super)

While it's a bit of a shame to not have all the keybindings in the same
place, I think it's worth it...

Recent updates to Walker (1.0.0) have broken the application. Walker now
uses elephant as a backend service for finding apps, clipboards, and
other things you may want to search but it does not start that service on
startup, we have to do this manually.

As we're pulling ingredients from homes, it seems like a good time to
also take the *usernames* from our homes as ingredient names. We mostly
all have ingredients named after ourselves (e.g. for keymap, etc.) but
these are trivially inferrable...

...unlike the ingredients themselves, these aren't system-specific so
may-as-well go as strings in the ingredients list

We often have homes that have ingredients which need system components.
Examples are gaming (which needs steam to be installed globally),
nightshift (which needs geoclue2 to be installed globally), niri (which
needs some substitutors, xdg stuff, etc.). It's annoying to keep track
of these ourselves: far better to have any same-named ingredients be
added to attached systems when they are added to homes.

It's worth doing this in a module rather than pulling the ingredients
in to our ingredients list as otherwise we won't get ingredients enabled
as dependencies/etc.

I continually end up installing this one to mess with my laptop
brightness... probably worth just installing it in a misc.nix. I don't
want to use homes/minion/misc.nix since as I don't *use* it on emden, so
best to just give redhead a misc of its own...

I often use computers fairly late - it's nice to have my display turn a
little less blue at night. Here's an ingredient to do that!

I considered having this as some sort of 'nightshift+niri', since as I
am using gammastep which is wayland only, but then I realized that all
supported desktop systems use wayland so it doesn't really matter. If
someone uses an X system later they may want to factor this out...

The fact that nightshift relies on system geoclue2 is yet another nail
in the "we should be determining system ingredients from your homes"
coffin...

Josh is a git proxy for working with monorepos - it lets you filter out
large portions of your repository so you can clone just the project you
are working on

We'd like to try using a monorepo (patisserie) when we move to tangled,
and as part of that we'd like to use Josh with it... let's add it!

We've still got our DDNS hosted on midnight, but we want to shut
midnight down... let's move it over to teal

When we implemented ingredients, we accidentally left quickshell in a
subdirectory where it'd never be used...

...that led to our overview background, time and battery indicators
being missing since as the code to display them was never imported...

...oops

We have options that it'd be nice to bring under our ingredient names to
disambiguate them... the option for "niri.niri.<foo>" is a little weird
but it's better than calling it "niri.<foo>" and having a base either
"development.<foo>" or "jujutsu.<foo>" for the jujutsu options.

This is subject to change in future - for example we might decide that
if the filename and ingredient name are the same we should use it only
once - however options are not commonly added to ingredients so that
would create potential naming conflicts for little benefit so we may
well not decide to do that too...

Some ingredients depend on others - whether this is by setting options
from another ingredient in a module or by some runtime code that only
makes sense with something else enabled. Let's turn on some ingredients
that are needed by other ingredients when we need them

For now, I've held of on adding ingredients like catppuccin or espanso
(where the options are not configured by PacketMix) even where they
clearly are needed to actually use some config... only ingredients who's
defined options are used or where there will be runtime errors in some
cases are included. We can consider adding these in a followup

Instead of making freshlybakedcake/ssh.nix enable development I moved it
to a combined ingredient. That behavior would be a little too surprising

We would like to infer the hostname and username as ingredients if they
exist. This will let us remove even more ingredients that we obviously
want included. Some homes don't have the system name specified, or don't
have ingredients by that name, for those we want to avoid erroring

The common ingredient is required everywhere, so let's make it default

We're setting it in config rather than default because we want to make
it clear that it *won't* be overriden unless you force over it...

I've written another nilla module for homes to use sugared ingredients.

Much like the system module, portable submodules aren't suitable because
of a general lack of portability TwT...

Unlike the system module, homes can't currently have their modules
array removed as we seem to be using it to set the home directory and
state version (arguably these should be in a user module and common
respectively - or we could put them both in common and generate the
directory from the name of the home)

I've written a nilla module to convert strings into enable options for
ingredients. I couldn't think of a nice way to do portable submodules
(since as things can rely on options from other ingredients, removing
portability anyway) so for now this'll have to do... it does, however,
pretty nicely sugar this annoying-ish definition.

Ingredients are a little tricker to use with homes than systems. That's
because in Nilla home arguments aren't special args (to allow their
portability to systems). Because this can't be changed, we previously
had special imports where we passed in inputs that needed to be
imported. As ingredients auto-import, this wouldn't be doable without
some sort of manual override functionality...

...instead of this, I've added a way to override some arguments that are
passed into ingredients. Doing this allows us to swap out our "project"
argument for a version that *can* be imported from/etc.

After doing this, moving homes to ingredients is a trivial refactor

We can have combination ingredients by putting plusses between
ingredient names. They should be automatically enabled when we enable
their component ingredients

These are useful to, for example, add certain configuration that is only
relevant to certain groups of people (e.g. freshlybakedcake) or reorder
service launch (like we're currently doing in homes for ssh/scriptfs in
niri)

We intend to switch the manual module importing to a system we call
"ingredients", where you will write a list of the modules you want
enabled and they will be enabled, along with any dependencies, etc.
without writing lots of .enable boilerplate by hand

In the long-term, this will allow us the following:
- Dependencies of some ingredients on other ingredients, rather than
having to know and add all of them to your system manually
- Documentation generation of ingredient dependencies, etc.
- Combination ingredients (e.g. freshlybakedcake+personal, to be
auto-imported if freshlybakedcake *and* personal both are)
- Auto-importing rather than having manual default.nixes on each level
which we have previously forgotten to update

This is the start of that idea - it's not feature-complete but it does
auto-import files directly in ingredient subdirectories (it's unclear
if we want this to remain direct children only) and have a module with
enable arguments rather than direct imports. In other words: it's about
as minimal of a prototype as I could reasonably get

At the moment, I've only done system ingredients as, due to homes using
_module.args some of them need special provision for imports - I will
figure this out later (possibly we could specially handle the 'project'
argument for ingredients or have some method of overriding ingredient
import arguments?)