Building 2.28.0 now succeeds with node 22 as well
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!
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.
After the app has been updated, the next time it’s opened it shows the changelog (version history).
(See #2852)
I expect opening the app to have it authenticate me to give me access to my passwords. The changelog is a needless detour.
I appreciate the work that goes into developing the app without seeing the changelog. I can find the changelog myself, should I feel the need to read it.
1.12-r5
15
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.
I was initially going to report this as a bug, but then I realized I’m in the beta program, so the issue could be specific to that. The unprompted version history at startup is an irritating interruption to using the app, and I could leave the beta program, if I knew that doing so gets rid of the interruption. (I’ve had no other issues with the beta AFAICR.)
What version of Keepass2Android are you using?
1.12-r5
At least in the mobile app this (showing of posts that should be filtered out completely) seems to occur when those posts get loaded after tapping ”Load missing posts”. So it’s like the filters don’t get applied to posts loaded on demand: I just had one shown to me earlier with the ”matches filter”, ”show anyway” preamble, but now that I went to check the timeline on the same device again, said post was now filtered out completely. (It hadn’t been deleted in the meantime, I checked.)
(I couldn’t remember if the example in my web UI screenshots above was similarly loaded with ”Load missing posts”.)
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.
As per title. Unlisted posts can not be reblogged, but the web UI still shows a reblog icon for such posts, and it can be clicked. After spinning for a while it then returns to its initial state, which is confusing (especially if you’re unaware of the limitation of reblogging unlisted posts).
The official mobile client does better: there such posts apparently don’t have the reblog icon. An alternative solution is Mastodon’s (web UI’s) way of showing a boost icon, but disabling it (so that it doesn’t react to clicks).
(The instance I’m on is pixelfed.social. The most recent post I had this issue with was federated from https://vernissage.photos/@magda/7470629220893329794#)
Attached is a screenshot of one of my filters, and of a post on my timeline matching the filter (see the hashtags at the end). There’s nothing (at all) in the console log. My handle is @uusijani@mastodon.social
. The post in this case apparently comes from a federated blog.
I have a feeling that most times I’ve seen posts that should have been filtered out, they’ve been boosted ones and not OC from people I follow. But obviously it could just be that I don’t follow many people who post about things that I like to hide with filters.
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)