ertius.org

Run Commands At Exact Git Refs

2026-09-21T00:00:00+00:00

It is often very handy to be working on multiple things in a single repository, and while magit makes unpicking local changes into coherent commits easy, testing those commits is kind of annoying. My primary use case for this was for testing changes in an Ansible tree - often I have a lot of things in flight, but it's pretty important to ensure that a commit is coherent. Specifically: the change refers to a new file and the new file itself needs to end up in the same commit. Just running tests or ansible-playbook --check --diff doesn't help in that case, because all the files are in the tree, but what you care about is whether they'll be committed together.

So I wrote a little script, the gist of which is this:

#!/usr/bin/env bash
set -euo pipefail

main_repo=$(git rev-parse --show-toplevel)
rel_dir=$(git rev-parse --show-prefix)
cache="$HOME/.cache/run-at-worktrees"

mode_index=0
commit=HEAD
while [[ $# -gt 0 ]]; do
  case "$1" in
    --index)   mode_index=1; shift ;;
    --)        shift; break ;;
    -*)        echo "run-at: unknown flag: $1" >&2; exit 2 ;;
    *)         commit="$1"; shift ;;
  esac
done

if [[ $# -eq 0 ]]; then
  echo "run-at: missing command" >&2
  exit 2
fi

if (( mode_index )); then
  tree=$(git -C "$main_repo" write-tree)
  sha=$(
    GIT_AUTHOR_DATE='@0 +0000' GIT_COMMITTER_DATE='@0 +0000' \
    GIT_AUTHOR_NAME=run-at GIT_AUTHOR_EMAIL=at@localhost \
    GIT_COMMITTER_NAME=run-at GIT_COMMITTER_EMAIL=at@localhost \
    git -C "$main_repo" commit-tree "$tree" -p HEAD \
      -m 'run-at index snapshot'
  )
  label="index snapshot on top of $(git -C "$main_repo" rev-parse --short HEAD)"
else
  sha=$(git -C "$main_repo" rev-parse --verify "$commit^{commit}")
  label=$(git -C "$main_repo" log -1 --format='%h %s' "$sha")
fi

wt="$cache/${sha:0:12}"
mkdir -p "$cache"

if [[ ! -d "$wt" ]]; then
  git -C "$main_repo" worktree add --detach "$wt" "$sha" >/dev/null
fi

echo "→ run-at: $wt" >&2
echo "  rev:  $sha" >&2
echo "  desc: $label" >&2

target_dir="$wt"
if [[ -n "$rel_dir" ]]; then
  target_dir="$wt/${rel_dir%/}"
fi
if [[ ! -d "$target_dir" ]]; then
  echo "run-at: target directory does not exist in selected revision: ${rel_dir:-.}" >&2
  exit 1
fi

cd "$target_dir"

exec "$@"

(the real version does some Ansible-specific stuff like symlinking the venv).

It's a lot of lines to:

Get a git commit id (or, if you pass --index, create a temporary commit from the staging area). Either must go before the --.
Make a worktree in ~/.cache/run-at-worktrees, with the name based on the commit.
cd to the same relative directory (e.g. if I'm in ~/src/linux/drivers, ensure I end up in ./drivers in the worktree)
Exec the provided command.

Setting the commit metadata - GIT_AUTHOR_* and GIT_COMMITTER_* - to static values means the temporary commit's hash depends only on the current commit + contents of the index, so we will reuse any previous worktree that shared the same content (and HEAD). commit-tree ignores any configured gpg/ssh signing requirement, so it doesn't require any creds and the commit id doesn't depend on keys or timestamps.

This is one of those things that in the past I might have considered too slow to do, but on a 5-year-old Mac, running it on the Linux kernel:

❯ time run-at -- pwd
Preparing worktree (detached HEAD 9ecfb2f7287a)
Updating files: 100% (94643/94643), done.
→ run-at: /Users/rob/.cache/run-at-worktrees/9ecfb2f7287a
  rev:  9ecfb2f7287a967b418ba69f10d45ead0d360593
  desc: 9ecfb2f7287a Merge tag 'trace-ring-buffer-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
/Users/rob/.cache/run-at-worktrees/9ecfb2f7287a
user=3.21s system=6.72s cpu=94% total=10.523

Since the worktree is named after the commit it's pointing at, subsequent runs are ~instant:

❯ time run-at -- pwd
→ run-at: /Users/rob/.cache/run-at-worktrees/9ecfb2f7287a
  rev:  9ecfb2f7287a967b418ba69f10d45ead0d360593
  desc: 9ecfb2f7287a Merge tag 'trace-ring-buffer-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
/Users/rob/.cache/run-at-worktrees/9ecfb2f7287a
user=0.02s system=0.03s cpu=76% total=0.066

My code bases are much, much smaller than linux.git, so that's plenty fast enough for me for running tests or uv run ansible-playbook --check --diff .... It is not fully hermetic, and any changes or junk left in the worktree persist between runs, but it's turned out to be very handy.

Trying To Make A Binary Cask With Homebrew

2026-09-20T00:00:00+00:00

homebrew is kinda weird compared to Debian and apt, but it is quite thorough and means I can keep almost all my software on macOS up-to-date with just brew upgrade. For the things it didn't have, though, I'd usually just install from source to ~/.local/bin and then leave it un-upgraded forever, which is not ideal. I thought I'd actually do it a bit more properly today, and, well, at least the "copy these binary files" part is not very complicated.

Jargon#

First, some jargon, since I can never remember what anything is in brew-land:

A formula is a package definition for installing open source software from source (or community-provided prebuilt binary bottles) in the form of a Ruby file
A cask is a package definition for installing a binary, often a proprietary GUI app, which will be a .rb file in the Casks/ directory of a tap
A tap is a Homebrew "repository", somewhere it can download formulas and casks from (usually public git repositories)

Getting Started#

I want to install coop, from trailofbits, a sandbox for running coding agents. Since upstream already ship binaries, I thought I'd try to use them, by creating a cask that just downloaded them from GitHub and installed them.

First I need a tap to put it in. The simplest way is to use GitHub, so let's do that:

brew tap-new rweir/homebrew-tap

On aarch64/macos at least, this creates a local git repository (owned by me) in /opt/homebrew/Library/Taps/rweir/homebrew-tap. Then create a matching repository on GitHub and push to it:

gh repo create "rweir/homebrew-tap" \
    --push --public \
    --source "$(brew --repository "rweir/homebrew-tap")"

Now you have a personal tap, which you and anyone else can tell their local brew to use:

brew tap rweir/tap

brew implicitly strips the homebrew- from the repository name, so GitHub repo name rweir/homebrew-tap maps to brew tap argument rweir/tap.

So, I ask brew to create the basic cask file for me to fill in:

brew create --cask \
    https://github.com/trailofbits/coop/releases/download/v0.6.0/coop-v0.6.0-aarch64-apple-darwin.tar.gz \
    --tap rweir/homebrew-tap \
    --set-name coop

Then just draw the rest of the owl:

cask "coop" do
  version "0.6.0"
  sha256 "2eb045bbbb24e25c995500f93146eea5ee866595f9042ad441cb930d7ada3ed6"
  depends_on arch: :arm64
  depends_on :macos

  # Where to download the binary from
  url "https://github.com/trailofbits/coop/releases/download/v#{version}/coop-v#{version}-aarch64-apple-darwin.tar.gz"
  name "coop"
  desc "Isolated VM environment for running Claude Code and Codex"
  homepage "https://github.com/trailofbits/coop"

  # Use the templated `url` field above to find other versions
  livecheck do
    url :url
    regex(/^v?(\d+(?:\.\d+)+)$/i)
  end

  # binaries are in a subdirectory inside the tarball, `brew` will use
  # the basename as the target
  binary "coop-v#{version}-aarch64-apple-darwin/coop"
  binary "coop-v#{version}-aarch64-apple-darwin/coop-proxy"
end

Keeping It Up To Date#

brew includes tooling to check for upstream updates:

$ HOMEBREW_NO_AUTO_UPDATE=1 brew livecheck --cask rweir/tap/coop
coop: 0.6.0 ==> 0.6.0

When there's a new version, I can make and then merge a PR to update version and sha256 in coop.rb to make it available.

Installing#

Great, now it can be easily installed:

brew install --cask rweir/tap/coop

Testing#

Cool! Now let's run it:

$ coop setup
zsh: killed     coop setup

and the classic popup:

Computer Says No

Whelp#

I could not find a single page describing all this (edit: I just found a pretty good doc on the Homebrew site, actually: Casks have a different trust model), but what's going on seems to be:

macOS on AArch64 won't run ARM64 code that doesn't have a signature, but even an "ad-hoc" one is fine (source)
The linker does sign the binaries from cargo build with an ad-hoc signature, so that's fine
Homebrew Cask marks downloaded binaries as downloaded by setting the com.apple.quarantine xattr on them (and is quite reasonably removing support for not doing that)
Trying to run a binary with the quarantine xattr on it triggers Gatekeeper, which by default requires the binary to be both signed with an Apple Developer ID and then also notarised by Apple. Notarisation requires the binary be uploaded to Apple and pass some malware checks, and if it passes, Apple issues a notarisation ticket that Gatekeeper can verify.

You can allow-list binaries, but it's being made increasingly difficult - Sequoia removed the control-click workaround for this and the current workaround is a temporary button in Settings → Privacy & Security:

Overriding it

So, that was something of a waste of time. Options to make it work:

Get an Apple Developer account myself and have the binaries signed and notarised
Add xattr -d com.apple.quarantine to the cask and bypass all this
Instead of a cask, create a formula that uses bin.install to simply install the binaries rather than building them, avoiding Casks's provenance checks entirely and trusting upstream to not distribute malware, and ignoring the source entirely
Document that one needs to go to Settings and click two buttons after install and every update

None of these are excellent, and the other-other option is: make a normal Homebrew formula instead, which downloads the source and builds it or uses prebuilt binary bottles, which is what I'll do next.

So, lesson learnt: casks are only sensible for binaries where upstream has already interacted with Apple to have them signed and notarised.

Very Partial Git Commits

2026-02-08T00:00:00+00:00

magit is of course the best git client there is, in particular because of how easy it makes curating the index/staging area. You can select individual hunks and go down to marking individual lines for staging, and so I often end up spending a lot of time crafting a commit. A downside of this is that most of the time my index is in some very specific state and so if I want to commit something else, e.g. a typo fix or a dependency or something that's not super related to the current change, I can't easily do so - I would need to stash and add and commit and unstash, and so I basically never do.

Turns out someone thought of this and added a great new^[1] feature to git - -o / --only:

$ git add some_file.txt && git commit -o -m"add some_file.txt" some_file.txt

A should-not-have-been-surprising-to-me quirk is that it's filtering the index not the tree, and so you need to stage it first.

added 2006-02-05 16:08:01 -0800 to ... git-commit.sh ↩

I just want to mirror 10GB

2026-02-05T00:00:00+00:00

I use a few third-party apt repositories on my servers, which is very convenient, but can also be slightly annoying:

kanidm uses GitHub Pages, which still isn't available via IPv6 in the year of our lord 2026
smallstep has some bizarre DNS load balancing config that is both IPv4-only and has long CNAME chains that make resolution unreliable for me (which is possibly my fault!)
incus releases very frequently and removes older packages, and I prefer to pin exact package versions for big complicated (but good! very good!) things like Incus which makes it regularly be uninstallable on a new host because the last release I pinned is gone from their repo

So, it seemed like time to set up a local mirror of this small amount of data that I would like to have reliably available.

debmirror was the obvious first choice for me, but no variation of --ignore="binary-all" that I could contrive would make it stop trying to fetch the non-existent binary-all arch:

Feb 05 10:50:07 myhost systemd[1]: Starting debmirror@kanidm.service - Mirror third-party apt repository: kanidm...
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: === Syncing mirror: kanidm ===
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Host: kanidm.github.io
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Root: /kanidm_ppa
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Dists: bookworm,trixie
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Sections: stable
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Archs: amd64,arm64
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Destination: /srv/apt-mirror/kanidm
Feb 05 10:50:07 myhost debmirror-sync.sh[462970]: Running: debmirror --method=https --host=kanidm.github.io --root=/kanidm_ppa --dist=bookworm,trixie --section=stable --arch=amd64,arm64 --keyring=/etc/apt/keyrings/thirdparty-mirror/kanidm_ppa.gpg --nosource --ignore-missing-release --ignore-small-errors --timeout=300 --rsync-extra=none --diff=none --progress /srv/apt-mirror/kanidm
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Warning: --rsync-extra is not configured to mirror the trace files.
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]:          This configuration is not recommended.
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Mirroring to /srv/apt-mirror/kanidm from https://anonymous@kanidm.github.io/kanidm_ppa/
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Arches: amd64,arm64
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Dists: bookworm,trixie
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Sections: stable
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Pdiff mode: none
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Will clean up after mirroring.
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Attempting to get lock ...
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: Getting meta files ...
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: [168B blob data]
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: [180B blob data]
Feb 05 10:50:07 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [149B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [196B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [208B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [140B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: ok
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Ignoring missing Release file for dists/bookworm/stable/binary-all/Packages.gz
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [235B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Download of dists/bookworm/stable/binary-all/Packages.gz failed: 404 Not Found
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Ignoring missing Release file for dists/trixie/stable/binary-all/Packages.gz
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: [231B blob data]
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Download of dists/trixie/stable/binary-all/Packages.gz failed: 404 Not Found
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Failed to download some Package, Sources or Release files!
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: WARNING: releasing 1 pending lock...
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]: Errors:
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]:  Ignoring missing Release file for dists/bookworm/stable/binary-all/Packages.gz
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]:  Download of dists/bookworm/stable/binary-all/Packages.gz failed: 404 Not Found
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]:  Ignoring missing Release file for dists/trixie/stable/binary-all/Packages.gz
Feb 05 10:50:08 myhost debmirror-sync.sh[462972]:  Download of dists/trixie/stable/binary-all/Packages.gz failed: 404 Not Found
Feb 05 10:50:08 myhost debmirror-sync.sh[462970]: === Sync failed with exit code 2 ===

(I think it is this bug).

aptly looked nice for try #2, and claims to support exactly this - mirroring third party repositories - but as far as I could tell it had no support for mirroring repository signatures, making clients in 2026 quite unhappy:

Error: The repository 'https://somehost.example.org/thirdparty/kanidm trixie Release' is not signed.
Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.

I uh would really rather not have to set up my own secure remote package signing system for my very basic mirror.

Attempt #3 to just use wget to spider files doesn't work since some of the repositories are hosted on GitHub Pages, which doesn't do normal directory indexes.

Try #4 was apt-mirror2, which is blessedly itself packaged in Debian, and Just Works - it basically just takes some sources.list lines and some paths and does the thing:

# apt-mirror2 config for kanidm
# Generated by Ansible

set base_path         /srv/apt-mirror
set mirror_path       /srv/apt-mirror/public
set skel_path         /srv/apt-mirror/.skel
set var_path          /srv/apt-mirror/.var
set nthreads          4
set gpg_verify        on
set etc_trusted_parts /srv/apt-mirror/.gnupg

deb [arch=amd64,arm64 signed-by=/srv/apt-mirror/.gnupg/kanidm_ppa.gpg] https://kanidm.github.io/kanidm_ppa bookworm stable
deb [arch=amd64,arm64 signed-by=/srv/apt-mirror/.gnupg/kanidm_ppa.gpg] https://kanidm.github.io/kanidm_ppa trixie stable

It is quite surprising that this is much much more fiddly than running my own full-Debian mirror is - that was half an hour of fiddling with ftpsync and it was done.

Artisanal Filesystem Hacking With systemd

2026-01-31T00:00:00+00:00

A service I started running some instances of a while ago is RIPE Atlas, a distributed dns/ping/traceroute probing tool run by RIPE. It is pretty easy to deploy - they provide an apt repository, that has a package in it that installs an apt config that gives you access to the packages. Once it's installed, it produces an SSH public key that you paste into a web page and away it goes.

It is however not super flexible to operate. One thing I wanted to do was configure it to use an external resolver instead of the local unbound instance I have that is full of weird config hax for my internal network. As far as I could tell there's no config option anywhere for this and I really wanted to avoid editing any of the files in the package. Once again, systemd saves the day - just put the resolver config in /etc/ripe-atlas/resolv.conf and a drop-in file in /etc/systemd/system/ripe-atlas.service.d/dns.conf:

[Service]
BindReadOnlyPaths=/etc/ripe-atlas/resolv.conf:/etc/resolv.conf

et voila. Once again a thing I would probably not have bothered to do in the pre-systemd era - it is easy to add a "mount --bind" line to a sysvinit script but that would mean hacking a shell script from a package (albeit a conffile), which is annoying going forward (telling dpkg to leave it alone) and much more annoying to automate - telling Ansible to insert a line into a text file in roughly the right place is much more annoying than just dropping two files on disk:

- name: Deploy RIPE Atlas custom resolv.conf
  ansible.builtin.template:
    src: ripe-atlas-resolv.conf.j2
    dest: /etc/ripe-atlas/resolv.conf
    owner: root
    group: root
    mode: '0644'
  notify:
    - "RIPE Atlas : restart service"

- name: Create ripe-atlas service override directory
  ansible.builtin.file:
    path: /etc/systemd/system/ripe-atlas.service.d
    state: directory
    owner: root
    group: root
    mode: '0755'

- name: Deploy ripe-atlas DNS override
  ansible.builtin.template:
    src: ripe-atlas-dns.conf.j2
    dest: /etc/systemd/system/ripe-atlas.service.d/dns.conf
    owner: root
    group: root
    mode: '0644'
  notify:
    - "RIPE Atlas : daemon-reload"
    - "RIPE Atlas : restart service"

Which is actually quite verbose, but is extremely straight-forward and depends on the systemd configuration merge semantics rather than luck at automatically hacking shell scripts. I actually started writing out an equivalent attempt using ansible.builtin.lineinfile to edit an init script to add a mount --bind line after the header (not correctly in the start and torn down in stop since that seems way too hard), then remembered that in that world I'd first need to write enough sh to put this service in a chroot to begin with, so that I could customise the /etc/resolv.conf it saw.

Zola Asset Integrity

2026-01-12T00:00:00+00:00

As a diligent Over Engineer, a while ago I added two things to how Zola generates links to assets:

integrity attributes to CSS <link>s, which means the browser will reject CSS with the wrong hash
?h=0123456789abcdef faux-GET params to the asset URLs themselves, so that I can set long HTTP cache times on them

That looks like this in a Zola template:

<link
    integrity="sha384-{{ get_hash(path="css/some.css", sha_type=384, base64=true) | safe }}"
    rel="stylesheet" href="{{ get_url(cachebust=true, path="css/some.css") }}">

which produces output like this in the generated HTML:

<link
    integrity="sha384-6d001da919b965dc3a4672b9d7ddce374d165452a2285f2753988842092ea6b9946645375cff3ede89a991c9698bfcea"
    rel="stylesheet" href="/css/some.css?h=0123456789abcdef">

Thus letting the HTML assert what the assets loaded for it should look like. So, now, if a malicious TLA MITMs you or compromises the server serving static assets, the browser will reject them (from the console log):

[Error] Cannot load stylesheet http://127.0.0.1:1111/css/main.css?h=0123456789abcdef. Failed integrity metadata check. Content length: 7715, Expected content length:
7715, Expected metadata: sha384-6d001da919b965dc3a4672b9d7ddce374d165452a2285f2753988842092ea6b9946645375cff3ede89a991c9698bfcea

In other news, Zola has a serve command that runs a little dev server and reloads if any of the files change:

❯ mise run serve
[serve] $ zola serve --interface 0.0.0.0 --base-url / --port=${PORT:-1111} --drafts
Building site...
Checking all internal links with anchors.
> Successfully checked 0 internal link(s) with anchors.
-> Creating 1 pages (0 orphan) and 0 sections
Done in 7ms.

Web server is available at / (bound to 0.0.0.0:1111)

Listening for changes in /home/user/project/{config.toml,content,static,templates}
Press Ctrl+C to stop

Change detected @ 2026-01-12 15:03:46
-> Static file changed /home/user/project/static/css/some.css
Done in 2ms.

You can see at the bottom that it reloaded the CSS file that had changed.

Unfortunately, Zola doesn't tie these two features together and if you use integrity and edit the assets while zola is running, then it will start serving the new asset with the old HTML, and then the browser will quite reasonably tell you to fuck off and stop loading the CSS. Excitingly, browsers don't really show that this is happening anywhere except in the console log, and if you have multiple style sheets and edited only one, the behaviour you will see is:

everything is fine
edit a CSS file
reload page
styles are all fucked up, and if you're like me, assume it's because your edit was terrible
think that's weird, let's blame caching or something
restart zola
everything is fine
undo change to CSS file
styles are all fucked up, and if you're like me, assume it's because your edit was terrible
etc

On the bug, user legoktm provides a pretty good workaround, that just removes the integrity attribute entirely when in local dev serving mode:

Firstly, add a new macro in templates/macros.html:

{% macro sri(path) -%}
{% if config.mode != "serve" -%}
integrity="sha384-{{ get_hash(path=path, sha_type=384, base64=true) | safe }}"
{%- endif %}
{%- endmacro %}

Then at the top of templates/base.html (or wherever your <link> tags are done):

{% import "macros.html" as macros %}

and wherever you actually write out the <link> in the templates, do this instead:

<link rel="stylesheet" href="{{ get_url(path="static/some.css", cachebust=true) }}"
    {{macros::sri(path="static/some.css")}} />

Git Spelunking

2026-01-02T00:00:00+00:00

I wanted to find something in some commit, and while trying to remember the right way to wrap around git rev-list --all, I found that git grew an option to just do that: git log -G<regexp> --branches --all^[1].

And when was it added? Let's find out:

❯ git log -G"-G" --pretty=format:"%h%x09%x09%ad%x09%s" --reverse -- Documentation/diff-options.txt
f506b8e8b5      2010-08-23 10:17:03 -0700   git log/diff: add -G<regexp> that greps in the patch text
5bc3f0b567      2013-05-31 17:42:15 +0530   diffcore-pickaxe doc: document -S and -G properly
9299f84921      2020-02-06 21:53:01 +0100   diff-options.txt: avoid "regex" overload in example
6b552e39c0      2024-11-18 22:05:50 +0000   doc: git-diff: apply format changes to diff-options
1f010d6bdf      2025-01-20 01:56:02 +0000   doc: use .adoc extension for AsciiDoc files

https://stackoverflow.com/a/2928721 ↩

Java In The Browser In The Year 2025

2025-12-01T00:00:00+00:00

Sometime one needs to use an ancient version of java, but since Oracle is in charge, obviously the official process is a nightmare. Fortunately some excellent person wrote a list of urls from other companies who surely have permission to offer said binaries, all available without logging in to Oracle.

This installs it to /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/, however OpenWebstart, since it's an app bundle or something, is unable to use that, so:

sudo mkdir /opt/jre8
cd /opt/jre8
sudo cp -r "/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/" .

Now you can point OpenWebstart at /opt/jre8, but whatever GUI toolkit it's using is quite terrible, so you must go to /opt, highlight jre8 and then click "Choose".

ZFS micro incompatibilities

2025-11-30T00:00:00+00:00

I've been setting up ZFS replication between some servers, but between one pair, every sync was failed with:

Nov 30 11:07:11 sourcehost syncoid[890260]: Sending incremental tank/enc/var/spool@autosnap_2025-11-27_20:00:22_monthly ... autosnap_2025-11-30_11:00:39_hourly (~ 555 KB):
Nov 30 11:07:12 sourcehost syncoid[890982]: warning: cannot send 'tank/enc/var/spool@autosnap_2025-11-27_20:00:22_weekly': Invalid argument

Source machine (which was on the way to being upgraded to trixie but hadn't been rebooted yet):

root@sourcehost:~# uname -a
Linux sourcehost 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
root@sourcehost:~# zfs version
zfs-2.3.2-2
zfs-kmod-2.3.1-1~bpo12+1

I had assumed it was some incompatibility with the destination machine and spent ages trying to track that down until I read the error more carefully - cannot send, ie the problem is with the zfs tool on sourcehost, before it even talks to the destination.

Eventually I found a reference to a bug in openzfs 2.3.1 that broke the user-space API, and then 2.3.2 reverted the breakage, which broke compatibility with 2.3.1 itself. Going through PRs from between 2.3.1 and 2.3.2, it's this, and here's the explanation of the accidental ABI change change

A reboot in to the new kernel with the new, same-versioned zfs userspace and kernel module fixed it.

Automounting ZFS encrypted filesystems

2025-11-27T00:00:00+00:00

zfs set keylocation=file:///etc/some-secret-path dataset/enrypted

And that's all that's needed - well, and a systemctl daemon-reload to actually generate the units. Before that, you can see what zfs-mount-generator plans to do:

$ mkdir /tmp/zfs-gen/
$ /usr/lib/systemd/system-generators/zfs-mount-generator /tmp/zfs-gen/
$ cat /tmp/zfs-gen/zfs-load-key@dataset-enrypted.service
# Automatically generated by zfs-mount-generator

[Unit]
Description=Load ZFS key for dataset/encrypted
SourcePath=/etc/zfs/zfs-list.cache/dataset
Documentation=man:zfs-mount-generator(8)
DefaultDependencies=no
Wants=
After=
RequiresMountsFor='/etc/some-secret-path'

[Service]
Type=oneshot
RemainAfterExit=yes
# This avoids a dependency loop involving systemd-journald.socket if this
# dataset is a parent of the root filesystem.
StandardOutput=null
StandardError=null
ExecStart=/bin/sh -euc '[ "$$(/usr/sbin/zfs get -H -o value keystatus "dataset/encrypted")" = "unavailable" ] || exit 0;exec /usr/sbin/zfs load-key "dataset/encrypted"'
ExecStop=/bin/sh -euc '[ "$$(/usr/sbin/zfs get -H -o value keystatus "dataset/encrypted")" = "available" ] || exit 0;exec /usr/sbin/zfs unload-key "dataset/encrypted"'
~

Which shows that it's just a service that loads the key at startup and unloads the key on shutdown, exactly as you'd want. Note that it also set a mount dependency on the location the key is stored, so that this can be stored on another e.g. another encrypted filesystem that itself needs to be unlocked.

This all assumes you've done the zfs-zed dance to hook ZFS in to systemd to begin with; if not, the Debian manpage explains how to do that bit.