commit 943189a9aa
Merge: 4a229d68 f5a09f30
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Sun Nov 13 08:54:32 2022 +0200

    Merge pull request #2259 from throny/patch-3

    warn users about upgrading to pg15 when using borg

commit 4a229d6870
Merge: 9b326e08 c68def08
Author: Slavi Pantaleev <slavi@devture.com>
Date:   Sun Nov 13 08:53:13 2022 +0200

    Merge pull request #2260 from etkecc/patch-117

    Update ntfy 1.28.0 -> 1.29.0

commit f5a09f30b7
Author: throny <m.throne12@gmail.com>
Date:   Sat Nov 12 23:48:57 2022 +0100

    Update maintenance-postgres.md

commit b12cdbd99d
Author: throny <m.throne12@gmail.com>
Date:   Sat Nov 12 23:40:46 2022 +0100

    Update maintenance-postgres.md

commit c68def0809
Author: Aine <97398200+etkecc@users.noreply.github.com>
Date:   Sat Nov 12 22:01:31 2022 +0000

    Update ntfy 1.28.0 -> 1.29.0

commit adbc09f152
Author: throny <m.throne12@gmail.com>
Date:   Sat Nov 12 11:20:43 2022 +0100

    warn users about upgrading to pg15 when using borg

This caused push notifications to be delivered more than once
if multiple `pusher` workers were enabled.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228

This fixes a regression since the change done in c1c152f7ac.
When another role (say `matrix-jitsi`) included `roles/custom/matrix-base/tasks/util/ensure_openssl_installed.yml`,
which then included `{{ role_path }}/tasks/util/ensure_openssl_installed_DISTRO.yml`,
that `role_path` variable would end up being the parent role
(`matrix-jitsi`) and not the `matrix-base` role, so we'd get a failure.

An alternative solution may have been to avoid using `role_path`, but
importing roles properly (like we've done in this patch) sounds like a better way.

Unfortunately, `import_role` fails if `tasks_from` is something like
`util/ensure_openssl_installed` (containing a `/`), so I had to move
these utils out of `util/`.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228

This avoids Ansible trying to ensure `community.general.pacman` is
available, even if that module will never run (because `when` says so).

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228

- https://github.com/matrix-org/dendrite/releases/tag/v0.10.7

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.

- update tag to latest dendrite release (https://github.com/matrix-org/dendrite/releases/tag/v0.10.6)

We no longer ask users to create Matrix user accounts for these bots:

- Postmoogle
- Honoroit
- Reminder Bot

Other bots and services (matrix-registration-bot, maubot, mjolnir,
Dimension, etc.) require an Access Token to run (not a password),
so this new role doesn't help for them.

It does help for the above bots though, and for defining your own
"initial user accounts" in the `matrix_user_creator_users_additional`
variable.

Dendrite uses a lot of databases, but a single (`dendrite`) role, which
leads to `matrix_postgres_import_roles_to_ignore` being something like
`['dendrite', 'dendrite', 'dendrite', ...]` needlessly.

This leads to weird regexes being generated for
`matrix_postgres_import_roles_ignore_regex`.
It's not that it hurts, but it just looks odd.

We were only reporting failures for when the async task didn't finish.
We also need to report a failure for when the task finished, but
returned a non-zero exit code.