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)

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

After last night’s refresh I’m now running 2024.10.4. Attempting to update Nordpool, fmi-hass-custom and pytapo fail with:

Unable to install package nordpool==0.4.2: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)
Unable to install package fmi-weather-client==0.4.0: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)
Unable to install package pytapo==3.3.32: error: failed to create file `/snap/home-assistant-snap/637/.lock` Caused by: Permission denied (os error 13)

It’s apparently due some changes in core, as some people running HA inside a customized Docker have also suffered this.

In the previous latest/stable, updating Nordpool and FMI weather client failed with errors about pip’s version, so I had reverted those back to their earlier versions and put off retrying the updates until now. Pytapo could be a dependency of Tapo Camera Control, which also updated recently.

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.

I can already guess the answer to this is ”no, because of how snap works”, but would it be possible for Wekan (installed as a snap) to use mongodb tools already installed on the host system? The reason I’m asking is that I’m running Unifi’s network application on the same non-AVX-capable host, and the installation script for it has added a mongodb repository patched to work without AVX, so that’s already covered.

A tooltip is used to render explanations for terminology when site content is viewed directly in a browser. But feed readers traditionally don’t support styles, and so the content is broken up by the <span class='terminology-tooltip'> elements’ content being shown mid-sentence. For instance, this paragraph in the 2024.10 release post

<p>We also introduce some small YAML automation syntax changes. If you are still a sucker for writing your automations
in <span class='terminology'>YAML<span class='terminology-tooltip'>YAML is a human-readable data serialization
language. It is used to store and transmit data in a structured format. In Home Assistant, YAML is used for configuration,
for example in the <code>configuration.yaml</code> or <code>automations.yaml</code>
files.<a class='terminology-link' href='/docs/configuration/yaml/'> [Learn more]</a></span></span> (like me), I’m sure
you’ll love these little tweaks that make it all feel more natural.</p>

is shown in my feed reader (Tiny Tiny RSS) as:

I’m not sure if this is a recent technical change, or just the first instance of these spans being used, or if I just haven’t been reading the posts that thoroughly, but the 2024.10 release post was the first I noticed this.