4.7.1 was released three weeks ago, but as I’m writing this, prebuilt binaries have yet to appear on the release page. Maybe the build jobs have failed?

I’m still getting federated posts from updating old ones on my blog (with the plugin now at version 7.5.0). Not every time, but something like four out of maybe two dozen that I edited today (from 2018) have so far appeared on Mastodon.

Should I open a new report? I noticed the merged PR (above) mentions the block editor, whereas I’m using the classic editor.

What

A checkbox on the settings page to optionally disable federating updates of existing posts.

Why

Previously:

If you edit an old post, that is not yet on mastodon, then it is technically an Update Activity but it shows up on Mastodon after the Update, so Mastodon seem to handle Updates without the updated timestamp as an Create.

I edit old posts (from before installing this plugin) every now and then, and find it pretty awkward when this causes those posts to show up on Mastodon as if they were new — more so than not federating updates at all. That’s why I’d like to have that option: to be able to disable federating updates altogether.

Only federating updates for posts that have already shown up on Mastodon would be a better solution, but also a bit more complex I believe. (It’d require some way to keep track of this status, as also mentioned in the issue that the quote above is from.)

How

No response

Okay, this was a conflict between the new integration and the third party integration I had been using up until now. I did uninstall the old integration before trying to setup the new one, but apparently that wasn’t enough; I also had to manually purge all references to sleep_as_android (both old and new) from .storage/core.entity_registry. Only after that (and core restart) the setup showed the webhook URL as expected.

The problem

The setup instructions say ”You will be presented a URL during the setup process.” I see no URL during the setup process (nor is it available anywhere after setup).

Steps to reproduce:
Select Settings > Devices & services > Add integration > Sleep as Android

What I expect to happen:
To ”be presented a URL during the setup process.”

What actually happens:

What version of Home Assistant Core has the issue?

core-2025.9.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Sleep as Android

Link to integration documentation on our website

https://www.home-assistant.io/integrations/sleep_as_android/

Diagnostics information

config_entry-sleep_as_android-01K5BG3KZKPF229RQSVK9BYAYC.json

Example YAML snippet

Anything in the logs that might be useful for us?

I’ve tried enabling debug logging for the integration, but it produces no output at all.

Additional information

No response

Yes, it seems to work as expected (i.e. identically with both OG and sudo-rs) when the are lines split, in either order, as long as timestamp_timeout value is unquoted. Double-quoting it again causes the ”expected nonnegative number” error (regardless of whether that line is first or second).

$ sudo-rs chown jani:jani test
/etc/sudoers.d/90-ssh-auth-sock:2:39: expected nonnegative number
Defaults!/bin/chown timestamp_timeout="0"
                                      ^
$ sudo cat /etc/sudoers.d/90-ssh-auth-sock 
[sudo] password for jani:
Defaults!/bin/chown env_keep+="SSH_AUTH_SOCK"
Defaults!/bin/chown timestamp_timeout="0"

Describe the bug
I’m testing sudo-rs, and came across a bit of weirdness in sudoers parsing, related to quotes and parameter order.

To Reproduce

1. $ touch test
2. edit /etc/sudoers.d/90-ssh-auth-sock to look like this:
   Defaults!/bin/chown timestamp_timeout=1,env_keep+=SSH_AUTH_SOCK
3. $ sudo-rs chown root:root test # this works as expected
4. edit /etc/sudoers.d/90-ssh-auth-sock to reorder the parameter=value pairs like this:
   Defaults!/bin/chown env_keep+=SSH_AUTH_SOCK,timestamp_timeout=1
5. $ sudo-rs chown jani:jani test # this fails:
/etc/sudoers.d/90-ssh-auth-sock:1:63: double quotes are required for VAR=value pairs
Defaults!/bin/chown env_keep+=SSH_AUTH_SOCK,timestamp_timeout=1
^

Expected behavior

For sudo-rs to perform the command in 5. without error, as it did in point 3.

Environment (please complete the following information):

• Ubuntu 24.04
• sudo-rs commit hash: b434d4d (precompiled version 0.2.8 binary from the Github release page)

Additional context
For background, I’m using pam_ssh_agent_auth to authorize my user with SSH keys to run some commands, which requires env_keep+=SSH_AUTH_SOCK.

I also like have it time out immediately, so I additionally set timestamp_timeout=0. I initially thought the issue was caused by the zero, but testing with timestamp_timeout=1 resulted in the same errors, so that’s what I’m using here, for unambiguity.

The caret in the error message points to timestamp_timeout’s value, so I’d assume the logical solution is to quote that value, like this:

Defaults!/bin/chown env_keep+=SSH_AUTH_SOCK,timestamp_timeout="1"

But this doesn’t help:

$ sudo-rs chown jani:jani test
/etc/sudoers.d/90-ssh-auth-sock:1:63: double quotes are required for VAR=value pairs
Defaults!/bin/chown env_keep+=SSH_AUTH_SOCK,timestamp_timeout="1"
                                                              ^

So my next thought is to quote both values:

Defaults!/bin/chown env_keep+="SSH_AUTH_SOCK",timestamp_timeout="1"

This causes a different error:

$ sudo-rs chown jani:jani test
/etc/sudoers.d/90-ssh-auth-sock:1:65: expected nonnegative number
Defaults!/bin/chown env_keep+="SSH_AUTH_SOCK",timestamp_timeout="1"
                                                                ^

The only remaining option is to quote only the first parameter value. Surprisingly, this works:

Defaults!/bin/chown env_keep+="SSH_AUTH_SOCK",timestamp_timeout=1

$ sudo-rs chown jani:jani test
$

With OG sudo, any order or combination of these parameters, quoted or unquoted, works as expected.

Describe the bug
I’m getting inconsistent results when converting AVIF images to other formats, using Firefox (in Ubuntu). I’m self-hosting Mazanoke 1.1.5, but the results are the same with mazanoke.com.

To Reproduce
Steps to reproduce the behavior:

1. Download this example AVIF file (as raw)
2. In Mazanoke, select Convert to: PNG
3. Drag and drop the AVIF file into the browser
4. Click the Download button of the converted file

Expected behavior
to receive a PNG file, fox.profile0.10bpc.yuv420.png

Screenshots
I receive a JPEG file, named fox.profile0.10bpc.yuv420.jpeg

Desktop (please complete the following information):

• OS: Ubuntu 24.04
• Browser Firefox 142.0.1

Additional context
The same thing (i.e. receiving a JPEG file) happens if I choose WebP as output, but not if I choose ICO: downloading the latter does produce a fox.profile0.10bpc.yuv420.ico, as expected.

Choosing JPG output also works as expected (although it would be pretty funny if it didn’t). Notably, this produces the filename fox.profile0.10bpc.yuv420.jpg: the file extension differs from the one produced by Firefox for the unexpected cases (.jpeg).

I can also work around the issue by selecting ”Download all”, which produces a zip archive, and all the files therein are in my chosen output formats as listed.

In Vivaldi (which is based on Chrome) the Download link also does produce the file in the chosen output format. So this looks like Firefox-specific issue.

Converting from (and to) other formats seems to work as expected in Firefox (at least the ones I’ve tested so far).

According to the [changelog](https://docs.mattermost.com/product-overview/mobile-app-changelog.html), there have been two releases since 2.29.1, but 2.29.1 is the latest on the [releases page](https://github.com/mattermost/mattermost-mobile/releases) here on Github. 2.30.0 and now 2.31.0 (apparently released today) are missing.

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!