v0.19.5

The images build on hosts whose group Debian already has, macOS among them, and wb.sh refuses to run as root.

Fixed

• The images build when the host's group is one Debian already has
  (#3).
  The workbench builds its images with the host's UID and GID, so the
  files it writes into the workspace stay the user's. A primary group
  of GID 100 (users, the default on NixOS and openSUSE) or 20 (macOS's
  staff, Debian's dialout) stopped the build at groupadd with
  GID already exists. The group is now created with --non-unique,
  so the image's user takes the host's GID whatever Debian calls it,
  and the workspace's files keep the host's group.
• wb.sh names its own version again. v0.19.4's cut left the
  script at 0.19.3, and the workbench's version is its image's tag.
  This release builds an image of its own, so the fix above reaches
  every machine on its next run.

Updated

• wb.sh refuses to run as root. Run as root, every file in the
  workspace would be root's, and the next run without sudo could not
  write them. Root used to stop at the image build with an error that
  named none of this. The script now stops before building or writing
  anything, says why, and points to the way out: the docker group,
  which is what sudo was usually standing in for, or a user of one's
  own. help still answers.

Upgrading

git pull, then any command that needs the workbench image
(./wb.sh console, ./wb.sh new…) builds it again, which takes a few
minutes. Workspaces created before keep their Dockerfile.local and
run as they did.

Full record: CHANGELOG.md