Release announcement:
https://github.com/psb1558/Junicode-font/releases/tag/v2.001
This is a breaking change, at least in font file naming (Junicode.ttf
is now Junicode-Regular.ttf). In general, 2.0 adds a lot more font
variants and opentype and web font versions of the font.
Seeing as backward compatibility is broken anyway, I opted to break it
a bit more and change custom install path (`junicode-ttf`) to
seemingly more conventional `truetype`; new .otf and .woff2 variants
are then naturally placed in corresponding directories. This
does *not* affect the `fonts.packages` NixOS option, which rearranges
font files anyway, but brings a degree of consistency with other
fonts.
Both the file renaming and the directory structure change break
satysfi, however, so I adjusted its builder accordingly, copying over
only those font variants that were also present in 1.0 series.
You can see in https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html that
this should be "HairPin" not "Hairpin". Using "Hairpin" results in
```
Oct 25 18:55:03 my-host systemd-networkd[843736]: /etc/systemd/network/10-bridge.network:11:
Unknown key name 'Hairpin' in section 'Bridge', ignoring.
```
While there is no fetcher or builder (in nixpkgs) that takes an `md5` parameter,
for some inscrutable reason the nix interpreter accepts the following:
```nix
fetchurl {
url = "https://www.perdu.com";
hash = "md5-rrdBU2a35b2PM2ZO+n/zGw==";
}
```
Note that neither MD5 nor SHA1 are allowed by the syntax of SRI hashes.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
The previous implementation works fine when the plugins do not already
contain store paths, which is the case for stuff from munin-contrib.
However, for plugins generated via nix (e.g. with writeShellScriptBin),
it tries to fix the paths in it which already point to the nix store,
ruining everything.
If extraAutoPlugins contains values that carry context (e.g. it comes
from a flake input), the keys generated from them using baseNameOf
inherit that context and the config doesn't compile.
This doesn't actually need to be an attrset anyways, so a bit of
internal refactoring lets us fix this without changing the visible API.
Changes the `mkIf` to trigger if *either* `data_dir`/`metadata_dir` use
`/var/lib/garage`, not only if both do. This is useful to me because I
want to store metadata in `/var/lib/garage` but I also want to store
data in a different mountpoint (via `data_dir` and `ReadWritePaths`).
