I build on release tags, and it looks like building 2.28.0 now succeeds with node 22 as well (whereas 2.27.0 still failed). So I think this is fixed now!

No problem; like I said, using node 20 works fine. I only noticed this issue recently, when I rebuilt my build environment, and tried doing so by the book (i.e. according to the docs).

If there’s something I can do to try to further narrow this down, let me know. I’m doing the build in an Ubuntu 24.04 VM, which I can restore to a working snapshot if testing causes it to break.

The Developer setup documentation says ”We recommend using NodeJS v22”, but trying to build the app (release 2.27.0) with node 22 fails (after nvm install 22.14.0):

npm error code EBADENGINE
npm error engine Unsupported engine
npm error engine Not compatible with your version of node/npm: mattermost-mobile@2.27.0
npm error notsup Not compatible with your version of node/npm: mattermost-mobile@2.27.0
npm error notsup Required: {"node":"^18.18.0 || ^20.0.0","npm":"^9 || ^10"}
npm error notsup Actual:   {"npm":"10.9.2","node":"v22.14.0"}
npm error A complete log of this run can be found in: /home/jani/.npm/_logs/2025-04-20T11_20_48_320Z-debug-0.log

The build works if I install node 20.19.0 instead.

Trying to build v2.25.1 with `npm build:android` fails with what looks like a missing dependency. This was not an issue with v2.25.0, so the cause is some recent change.

The full log is below, but here’s what I think is the crucial part:

* What went wrong:
Could not determine the dependencies of task ':app:mergeReleaseNativeLibs'.
> Could not resolve all dependencies for configuration ':app:releaseRuntimeClasspath'.
> Could not resolve project :frameanimation.
Required by:
project :app > project :expo > project :expo-image
> No matching variant of project :frameanimation was found. The consumer was configured to find a library for use during runtime, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '8.2.1', attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but:
- No variants exist.
> Could not resolve project :gif.
Required by:
project :app > project :expo > project :expo-image
> No matching variant of project :gif was found. The consumer was configured to find a library for use during runtime, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '8.2.1', attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm' but:
- No variants exist.

fail.log

In at least the past couple of updates of Mattermost, the .deb package has changed contents of /opt/mattermost/client/root.html sometime after installing the update, which changes the file’s checksum. This is an issue for people like me, who run debsums --changed daily as part of monitoring the integrity of my server.

I’m not intimately familiar with Debian packaging, but I don’t think those (checksummed) installation files should change post-install. Maybe an unchanging template file should be installed instead, and the final file generated from that?

(I’ve inspected the file, and the only change from the package-provided one is an addition of ”js.stripe.com/v3” to aheader tag, so I’m pretty sure this is a packaging issue and not filesystem corruption or a malicious attacker.)

As a workaround, I can of course recalculate the new checksum, and update the .md5sums file where it’s listed accordingly, but… eww.

(Somewhat related: #26769)

I’m just making this note here publicly, since I was first going to pose this as a question, but then managed to solve it by myself:

For background, I recently switched my Mattermost from a tar archive installation to installing it from the package repository, and simultaneously switched it from using a MySQL database to using PostgreSQL, all in one fell swoop by exporting the old content, doing a fresh install, and then importing. This appears to have mostly worked, with just user profile images having been lost, and passwords requiring a reset, both of which (I’ve gleaned from various places) were to be expected.

However, all bot accounts also seem to have been converted into normal user accounts somewhere during this process. So far the only issue I’ve discovered resulting from this is this entry getting logged repeatedly:

Failed to get system bot    caller="app/post.go:2205" component=post_reminders error="SqlBotStore.Get: Bot does not exist., resource "Bot" not found, id: <my system bot's id>"

I solved this by running

sudo -u mattermost mmctl user convert --bot "<bot id>" # replace <bot id> with your real system bot account id

Since that seems to have gone well (the error messages stopped), I went ahead and converted the rest of the bot accounts back to true bots likewise.

For anyone else stumbling across this thread when googling for this annoying problem: the issue here is that using special characters in your password on the DataSource line is broken: Can’t use special character in password in the DataSource property · Issue #1541 · mattermost/mattermost · GitHub

As stupid as that is, the easiest way to work around it is to set a password consisting of just alphanumeric characters. You shouldn’t have much use for it outside this anyway, so as not to make it ridiculously insecure.

@amyblais Alright, I finally managed to get through the signup. Here’s my suggestion, although it’s in moderation for now, so the link probably won’t work until it’s approved.

A ”Mark read” choice in push notifications about new messages, as seen in many IM apps, would be handy in Mattermost Mobile too. Currently the message can only be marked read by tapping the message to open the app (which is slow).

Hi @amyblais,

I could post this on the feature idea forum, but I can’t figure out how the signup on the site works. When I click on ”Create an account”, I get a prompt to verify my email address, and having done that, a page saying ”Go back to Production to finish logging in”. I don’t know what ”Production” is, and at no point was there any actual way to set up a password, so I can’t log in.