A new install with nothing changed but the port and ROOT_URL could not reach the database:

MongoServerSelectionError: connect ECONNREFUSED 0.0.0.0:27017
reason: TopologyDescription { type: 'ReplicaSetNoPrimary',
        servers: Map(1) { '0.0.0.0:27017' => [ServerDescription] },
        setName: 'rs0', ... }

0.0.0.0 is in no compose file. It is FerretDB’s own listen address, and the driver was handed it by the server. The ferretdb service runs with --repl-set-name=rs0 - added in #6480 so Meteor can tail an OpLog instead of poll-and-diff - so FerretDB answers the hello handshake as a one-member replica set and fills hosts, me and primary with its --listen-addr. A driver not in direct-connection mode reads that as an invitation to do replica-set discovery: it adopts the advertised member list and drops the seed it was given, because the server reports a name other than the one that was dialled. mongodb://ferretdb:27017 became 0.0.0.0:27017, which inside the wekan-app container is that container itself.

Measured against FerretDB v1.49.0 with the driver the bundle ships: without the parameter the topology ends up ReplicaSetWithPrimary with the seed discarded, with it the topology is Single on the host that was given. It costs nothing else - the handshake still reports setName: rs0, the only thing Meteor checks before it will tail an OpLog. All five FerretDB v1 compose files carry it; the MongoDB ones deliberately do not, being real replica sets whose members are reachable under the names they advertise.

Four things at once, in an issue reopened against 10.10, 10.37, 10.38, 10.72 and 10.77.

THE SCROLL. Every earlier fix removed viewport arithmetic from boardsList.css. The last piece of it was in layouts.css: body.mobile-mode #content { height: calc(100dvh - 48px) }. 48px is a guess at the height of the header, and the header is not 48px and is not any one number - --wekan-header-height is published from a ResizeObserver for exactly this reason. On a phone whose bar wraps, #content was taller than the room under the header, its bottom sat below the screen, and body.mobile-mode is position: fixed and overflow: hidden, so that strip is unreachable. Nothing needs computing: body is a flex column of one viewport and #content is its flex: 1 item.

THE TABLE VIEW. The right column has two branches - the board icons and +tablePage - and only the icons were ever given a scroller, so in Table view the rows past the fold were clipped with nothing to scroll.

THE 4x-TALL TILES. A grid defaults to align-content: stretch, so a list shorter than its column has the leftover height divided among its rows and each tile grown into it - and a board tile paints its colour over the whole cell. This was fixed once, but only on .board-list.mobile-view; the phone media query builds a grid too, and a narrow window that is not a mini screen took that path.

THE SPACING. An 8px grid gap plus a margin-bottom: 0.5rem per tile: 16px between rows and 8px between columns, which reads as crowded sideways. One value now, in both directions. The mobile full-screen popup had the same class of bug as the first and states dvh now too. Desktop is unaffected.

build-mac-x64 asked for macos-13, and GitHub has retired that image - actions/runner-images publishes macos-14, macos-15 and macos-26 only. A retired label does not fail: the job QUEUES, for a runner that is never coming. It has been sitting there every release until cancelled by hand, and no WeKan release has ever carried a wekan-<version>-mac-x64.zip because of it. Intel macOS was renamed, not removed: macos-15-intel, which is what TSC already builds on.

Cancelling it is what skipped charts, ucs and nextcloud: a cancelled job cancels the run, and a cancelling run skips every job that has not started - so all three were skipped the second the docker job they wait on succeeded, after everything had already shipped. A job whose if is always() still runs while a run is cancelling, so the three now say always() and name the needs that must have succeeded.

The armv6 bundle died on qemu-arm: Could not open '/lib/ld-linux-armhf.so.3'. Debian has no ARMv6 port

• debian:trixie publishes arm/v5 and arm/v7 - and containerd treats a lower ARM variant as compatible, so --platform linux/arm/v6 quietly resolved to arm/v5: Debian armel, soft-float, with no hard-float loader in it. The preflight compared the architecture and ignored the variant, so it never said so; it compares both now, and armv6 is built in Debian’s arm/v7 container, which is armhf and runs node-armv6 fine. Nothing ARMv7 reaches the bundle - the container compiles nothing, and node, FerretDB and the MongoDB tools are all downloaded already built for ARMv6 - except the bundled qemu-user, which is copied out of the container and is therefore skipped for that one bundle.

armhf, s390x, ppc64el and riscv64 all failed, three attempts each, and the job reported it as a Launchpad problem: “often an OOM in the Meteor npm install, or a transient build-farm reset; re-run”. It was neither. The build log said the same deterministic thing every time:

Staging mongo42
Failed to copy '/build/.../parts/mongo42/install/mongo42': no such file or
directory. Build failed

The mongo42 part downloads MongoDB 4.2 so a database from an old MongoDB snap can still be migrated (#6471), and MongoDB publishes 4.2 for amd64 and arm64 only. Everywhere else the part prints “nothing to migrate from there; skipping” and exits 0 having created nothing - its own comment calls that optional by design. It was not: the part also carries stage: [mongo42], and snapcraft does not skip a filter whose path is missing, it ends the build. So a migration helper no exotic architecture has ever needed took the whole snap down on exactly the four that can only be built on Launchpad. The directory is created before anything can decide to skip; the binary is still downloaded only where it exists.

riscv64 additionally lost its last attempt to npm ERR! code ECONNRESET on one tarball, after half an hour of building - every request there goes through Launchpad’s proxy - so that npm install is retried three times. The ::error:: no longer guesses: it sends the reader to the build log printed above it.

A chart entry is written once, during the release it belongs to, so a release whose charts job did not run leaves a hole nothing ever fills. Counted against the live index: 216 of 690 WeKan releases have a chart entry.

releases/backfill-charts.sh answers which releases the index should list - the ones that exist and can be installed. 216 are kept (never repackaged; that would change a digest helm clients have seen), 369 could be built, and 162 are OMITTED because they have no container image on ghcr: a chart is a pointer to an image, so an entry for one of those is an install that fails at the pull. The index is rebuilt from the packages actually present, so omission needs no bookkeeping.

It also found something already wrong: the published index has four entries for 9.36.0 and two for 10.30.0, each with a different digest and the same url, because the release script prepends an entry every time it runs. At most one of those digests can be the one of the package really served, and a helm client that picks another fails the integrity check on a good file. The rebuild keeps the entry whose digest matches the package, falling back to the newest only when there is no package to compare against. Nothing is written without --apply and nothing is pushed without --push; the charts job runs it in plan mode only, into the run summary.

With the charts repository cloned it became clear the index had drifted from its own packages in four ways at once, all from the same habit: an entry was written by COPYING the previous entry and substituting a few fields, so the index was being kept as the record rather than as a description of the .tgz files beside it.

146 packages had no entry at all - 362 packages, 220 entries. They are downloadable by URL but invisible to helm search, to helm install wekan --version 9.63.0 and to Artifact Hub. 9.36.0 had four entries and 10.30.0 two, each copy with a different digest and the same url, so a client could pick a digest matching no file and fail integrity on a good package. appVersion was the CHART version on every entry - 10.79.0 where the package says 10.79, which is the WeKan version a reader is looking for. And every entry claimed the mongodb subchart was 0.7.2, a field nobody substituted, while the packages had long since moved to 0.7.6.

releases/reindex-charts.py derives the index from the packages, reading each one’s Chart.yaml out of the archive, so an entry cannot describe a package wrongly. Nothing is invented: created is preserved exactly on every entry whose digest matches its package, and a package being added takes the date it was committed to gh-pages, which is when it was really published. Two 2023 packaging slips - wekan-1.2.7.tgz containing chart 1.2.6, and wekan-6.96.tgz containing 6.9.6 - are reported and left out rather than making one version mean two files; both files stay on the server.

The index went from 220 entries to 360, and was checked after writing: no repeated version, every digest equal to the sha256 of its file, every file present, and no version that was listed before missing.

The charts repository keeps the chart SOURCE on main and the published packages plus index.yaml on gh-pages, and its own two scripts move between them: release.sh commits the source, tars wekan/ into wekan-<version>.0.tgz, checks out gh-pages and drops the package there; release2.sh commits and pushes. release-charts.sh drives both and owns the index in between - and that middle part is what changes here.

The index is now rebuilt from the packages instead of being edited. It used to copy the newest entry, substitute a few fields and prepend the result, and all four of the index’s defects came from exactly that. Deriving it makes them impossible rather than fixed: one entry per package, digest computed from the file, fields read out of the archive, and any package that was missed picked up on the next run.

The package is checked against its own filename before it is indexed. release.sh names the tarball from its argument while the version INSIDE comes from the Chart.yaml that was just edited, so when those drift the repository gains a file called one version that declares another - which is how wekan-1.2.7.tgz (containing 1.2.6) and wekan-6.96.tgz (containing 6.9.6) came to exist. Both are now removed, and a package like them stops the release with a message instead of being published.

Release All Missing publishes a chart too. It could rebuild any missing bundle but not a missing chart, so a release that never got one never would - its header even said the charts were out of scope. It has a charts job now, guarded twice: nothing happens without a token that can push to wekan/charts, and nothing happens if the chart for that version is already published, because re-publishing would re-tar the package and change the digest of a chart people have already pulled.