Type of issue
Other (issue in content formatting, broken link or image, non-working widget)
Problem description
In the blog, a tooltip is used to render terminology explanations when 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 2026.11 release post
<p>Targets are a great way to keep your <span class='terminology'>automations<span class='terminology-tooltip'>Automations in Home Assistant allow you to automatically respond to things that happen in and around your home.<a class='terminology-link' href='/docs/automation/'> [Learn more]</a></span></span> and <span class='terminology'>scripts<span class='terminology-tooltip'>A script is a saved list of steps that runs when you start it, for example, from a dashboard, with Assist, or from an automation. Unlike an automation, a script has no triggers, so it doesn’t start by itself.<a class='terminology-link' href='/docs/script/'> [Learn more]</a></span></span> up to date. Point one at an <span class='terminology'>area<span class='terminology-tooltip'>An area in Home Assistant is a <a href="/docs/organizing/">logical grouping</a> of devices and entities that represents a room or space in your home, such as the living room, kitchen, or garage.<a class='terminology-link' href='/docs/organizing/areas/'> [Learn more]</a></span></span>, a <span class='terminology'>floor<span class='terminology-tooltip'>A floor in Home Assistant is a <a href="/docs/organizing/">logical grouping</a> of areas that are meant to match the physical floors in your home...
is basically unreadable in my feed reader (Tiny Tiny RSS):
Suggested solution
IDK what CMS the blog runs on, but it needs to render those terminology explanations in the feed in a way that doesn’t break the content, or not at all.
URL
https://www.home-assistant.io/atom.xml
Version
2026.11.0
How do you know the suggested solution is correct?
No response
Additional information
I’m re-reporting this; I posted #35042 two years ago, but it went ignored, and this is still an issue.
My laptop (a Dell Latitude 5400, running Ubuntu 26.04) is also affected by this. /usr/libexec/geoclue-2.0/demos/where-am-i is able to get my location, yet go-hass-agent always reports the same error it does for OP:
1:17PM DEBUG Location updated.
1:17PM DEBUG Invalid sensor data. error="contains field errors\ninvalid field Name (value(\"\")) failed validation for required: Key: 'Sensor.Name' Error:Field validation for 'Name' failed on the 'required' tag\ninvalid field State (value(\"<nil>\")) failed validation for required: Key: 'Sensor.State' Error:Field validation for 'State' failed on the 'required' tag\ninvalid field Type (value(\"\")) failed validation for required: Key: 'Sensor.Type' Error:Field validation for 'Type' failed on the 'required' tag\ninvalid field UniqueID (value(\"\")) failed validation for required: Key: 'Sensor.UniqueID' Error:Field validation for 'UniqueID' failed on the 'required' tag
The device tracker’s state in HA remains ”Unknown”.
Here’s how Arch fixed it:
[Service]
ProtectHome=read-only
PrivateDevices=no
DeviceAllow=/dev/urandom r
DeviceAllow=char-hidraw rw
According to a comment on the related polkit report ”That’s the correct way to solve these issues”.
Mattermost Server Version
11.10.2
Operating System
Ubuntu 26.04 (and probably any other Unix-like OS)
Steps to reproduce
- wget https://releases.mattermost.com/11.11.0/mattermost-11.11.0-linux-amd64.tar.gz # current latest
- tar tvf mattermost-11.11.0-linux-amd64.tar.gz | head
Expected behavior
drwxrwxr-x root/root 0 2026-09-11 08:52 mattermost/
drwxrwxr-x root/root 0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-r-- root/root 32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-r-- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root 15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root 16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-r-- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-r-- root/root 9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-r-- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig
Observed behavior
drwxrwxrwx root/root 0 2026-09-11 08:52 mattermost/
drwxrwxrwx root/root 0 2026-09-11 08:52 mattermost/prepackaged_plugins/
-rw-rw-rw- root/root 32570767 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz
-rw-rw-rw- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-calls-v1.12.2-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root 15900090 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-github-v2.7.1-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root 16578584 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz
-rw-rw-rw- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-gitlab-v1.13.0-linux-amd64.tar.gz.sig
-rw-rw-rw- root/root 9828026 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz
-rw-rw-rw- root/root 566 2026-09-11 08:52 mattermost/prepackaged_plugins/mattermost-plugin-jira-v4.7.1-linux-amd64.tar.gz.sig
Additional Information
The installation instructions suggest extracting the files as non-root, which will result in the user’s umask being applied to the output files, so that’ll cause the world-writablity bit to get dropped (hopefully for most users).
It’d still be better though if the files were 0660/0770 (or at least 0664/0775) even when extracted as root. (Group-writability is enforced by the instructions’ sudo chmod -R g+w /opt/mattermost in any case.)
⚠️ Before submitting, please verify the following: ⚠️
Bug description
Selecting ”Add account” from the tray icon menu crashes the client.
Steps to reproduce
- Click on the tray icon
- Select Add account
Expected behavior
Account creation wizard appears.
Which files are affected by this bug
I don’t understand this question.
Operating system
Linux
Which version of the operating system you are running.
Ubuntu 24.04
Installation method
Community PPA (please test with the AppImage package ?)
Nextcloud Server version
34.0.3.2
Nextcloud Desktop Client version
34.0.2-20260819.104017.ea499374cb-1.0~noble1
Did this occur after an update or on a clean installation?
Minor version update (i.e. 33.0.0 → 33.0.1)
Are you using the Nextcloud Server Encryption module?
No
Are you using an external user-backend?
- ☑Default internal user-backend
- ☐ LDAP or Active Directory
- ☐ SSO – SAML
- ☐ Other
Nextcloud Server logs
Additional info
I tried the Appimage and it doesn’t seem to be affected (i.e. it doesn’t crash, and the account creation wizard appears).
I lied in answering ”Did this occur after an update or on a clean installation?” question above, because it’s been years since I’ve last tried adding accounts to the client and don’t really know the answer, but the choices given don’t account for this possibility.
”Debug archive creation is not available on this platform.” But I created a log according to the instructions in #10535’s comments and am attaching it here.
crash.log
I just built 2.42.3, and it appears to have fixed this — maybe via [PR #9789](https://github.com/mattermost/mattermost-mobile/pull/9789#:~:text=bad%2Dcertificate%20reporting.-,Build%20Script,-File%3A%20scripts)?
Nevermind, this happened multiple times again today. Guess I just had a lucky streak of a couple of weeks there when it didn’t.
I think this might be fixed; at least I haven’t seen the Shortcuts failure notification in a while now, whereas before it was a daily occurrence.
This isn’t a real bug (although downloading without -o results in ”File name too long”, if filenames on the local FS are restricted to 255 bytes). I’m just making a note about Rony Rex trolling with the title: https://areena.yle.fi/1-78271849
Could make good test case. :)
I’ve reverted my live server back to 6.09 (and locked it there) for now.
On the testing VM I started from scratch: I deleted all existing data and reinstalled the 10.02 snap. Right after installing it’s working fairly normally, no noticeable slowdown, and ferretdb is down in double- or even single digits of CPU percentage.
I then exported my main working board from the live system (as JSON, 11 MB) and imported it into the VM installation. There was some noticeable slowdown right after, but eventually it settled back into working normally (i.e. no tangible slowdown).
But ferretdb’s CPU usage began to climb, until it was again using more than 160 % of the CPU.
Since then, I’ve tried to isolate the triggering cause from the import (if any), but no luck so far.
The only possibly relevant messages I’ve seen in the log during this were:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added to [Gzip]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [ServerResponse]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
