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.

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)

Updated the Device information section above accordingly.

I just updated to 22.1 and can confirm that the issue is indeed still unfixed.

I blocked the account all those posts listed were from, then unblocked the domain (after which the posts were still there on the home feed), then blocked it again, and now those posts appear to have vanished. I don’t know which of the steps were crucial, but I’m open to experimenting further if it can help.

I added pubeurope.com to my blocked domains, and now my home feed consists of nothing but posts from that domain.

I’ve apparently blocked Threads previously (although I don’t remember it, so it may just be a default), but I don’t recall seeing posts from Threads in my timeline. Certainly not completely filling it like this.

I’m on Pixelfed.social.

Switched to 11.1 and tried updating those components again. No change unfortunately.

home-assistant_2024-11-14T09-59-20.244Z.log

Yes, the qemu solution seems simpler and more future-proof than the custom Unifi repository.

Also, my guess would be that few people running Wekan on hardware old enough not to have AVX will have a massively large user base on their installation; most are probably small-time hobbyists like myself, so any negligible slowdowns being exacerbated by scale won’t be much of an issue.

Right, could be more trouble than it’s worth.

I have been eyeing some slightly newer (used) hardware for my home server, but for now this AVX requirement from (the Wekan-integrated) MongoDB is the only real reason to upgrade; otherwise the old HP (from 2011!) is still chugging along just fine in what it’s used for. :)