Every non-amd64, non-arm64 platform already used FerretDB v1 - MongoDB ships no server for any of them - but only three were built, because only three had a Node.js runtime anyone published. The wekan/node fork now builds the rest, so the release follows FerretDB’s list instead of Node.js’s.

New bundles: i386, armhf and loong64, beside the ppc64le, s390x and riscv64 already there. i386 and armhf also become snaps and join the multi-arch image (linux/386, linux/arm/v7); loong64 ships as a .zip only, because it is not a snap architecture and buildx and the three registries do not agree on it yet.

Where the Node.js comes from is resolved at build time rather than declared: nodejs.org, then unofficial-builds, then the fork, in that order, and the log says which one served. The first two ship a tarball; the fork ships the bare binary it built, because that is the only part missing - so when the fork serves, npm comes from the official amd64 tarball of the same version. npm is JavaScript and runs on whatever node executes it, so an npm built for one CPU drives a node built for another.

Three vocabularies meet in that matrix and they disagree. Node says x86 and armv7l where Debian, snap and FerretDB say i386 and armhf, and snap says ppc64el where everyone else says ppc64le. Every row now names all three, because a row that named one of them would download another CPU’s binary and nothing would notice until somebody ran it.

armel is the one FerretDB target deliberately left out: V8 has not supported ARMv5 for many years, so there is no runtime to put in the bundle and the fork cannot build one either. A bundle with nothing to run it is not a bundle.

The MongoDB Database Tools are per-tool tolerant now - wekan/mongo-tools does not publish every architecture, and a missing mongodump is a missing convenience rather than a broken bundle, since FerretDB is the database. It removes the inherited amd64 tool instead of shipping it, because a tool for the wrong CPU is worse than no tool. It is written up as Platforms.

The s390x snap died in the STAGE step of both its Launchpad builds, right after “Staging mongodb”, with IsADirectoryError on stage/bin. ppc64el and riscv64 take the same branch and would have died the same way.

The mongodb part’s stage-packages unpack an Ubuntu 24.04 merged-/usr layout, which leaves bin in the part as a symlink to usr/bin. On amd64 and arm64 the part then downloads MongoDB and copies its binaries in, which replaces that symlink with a real directory. On the architectures MongoDB ships no server for, the build exits before that and the symlink survives - and staging a symlink on top of the real stage/bin an earlier part has already created is what failed the whole snap, not just that part.

An override-stage turns a bin symlink into an empty real directory before staging. It tests for a symlink specifically, so the architectures where mongod really is there are untouched, and it removes before mkdir -p, because mkdir -p follows a symlink and would have changed nothing.

On a 375px phone the menu’s column is capped at about 157px, and the menu kept the 260px width it carries so it can be dragged - so it lay across the board icons.

max-width: 100% did not fix it, and that is the part worth knowing: a grid item’s default min-width is auto, which is its content’s intrinsic minimum, and a minimum beats a maximum. The cap did nothing until the item was allowed to shrink to it. min-width: 0 is the same pair the board column beside it has carried all along, for the same reason. Nothing inside the menu needs the intrinsic width held open - the workspace name already ellipses through its own min-width: 0.

The node/ directory - a clone of the Node.js fork the runtime is built from - joins the other local-only clones in .gitignore at the same time, so it stops filling git status with 2.2G of untracked source.

Starred, Home, Templates and Archive have labels of four different lengths, and on a phone the count chip sat immediately after its label - so the four numbers landed at four different x positions and the column of counts read as ragged rather than as a column at all.

That packing was deliberate: the number beside the text rather than across a gap, on the grounds that a landscape phone’s menu is wide enough for the gap to look like a mistake. It is reversed here, because the alignment is what a reader is actually using - the counts are compared with each other down the column, and four x positions is what stops that. The row keeps the same spread-apart layout at every width now, so every count sits at the end of its own row and they line up. The phone override is gone rather than re-tuned: there is no width at which the ragged version was wanted.

The riscv64 leg failed three times in sixteen minutes, and the whole of what it printed was one line: Git operation failed with: Could not push 'HEAD' to Launchpad. The build had not started - remote-build uploads the source to a Launchpad git repository first, and it was the upload that failed - so there was no Launchpad build log to print, which is what the job knew how to show.

snapcraft swallows git’s own error, writes it to its own execution log, names that log’s path in the output, and nothing reads it. So “rejected”, “timeout”, “auth” and “too big” all looked identical from the job log, which is why three runs narrowed nothing down. That log is printed now when an attempt fails.

The retry also clears snapcraft’s local clone of the Launchpad repository before waiting. A retry that reuses a half-pushed one repeats the same failure, and three identical attempts sixteen minutes apart is what that looks like.