[01:29:22]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 71 pending update PRs
- 1 new apps PRs: atuin
- 9 failed apps updates: adminer, armadietto, arn_messager, cloudreve, gogs, jenkins, passed, planka, translite
See the full log here: https://paste.yunohost.org/raw/yofuzakuri
Autoupdate dashboard: https://apps.yunohost.org/dash?filter=autoupdate
[09:26:25]
<Yunohost Git/Infra notifications> App adguardhome goes down from level 8 to 6 in job [#29691](https://ci-apps.yunohost.org/ci/job/29691)
[09:58:32]
<Yunohost Git/Infra notifications> App adguardhome goes down from level 8 to 6 in job [#29501](https://ci-apps.yunohost.org/ci/job/29501)
[12:39:41]
<Yunohost Git/Infra notifications> App pyload stays broken (level 0) in job [#29511](https://ci-apps.yunohost.org/ci/job/29511)
[12:56:44]
<Yunohost Git/Infra notifications> Job [#29432](https://ci-apps.yunohost.org/ci/job/29432) for diacamma failed miserably :(
[13:25:31]
<Yunohost Git/Infra notifications> App glances failed all tests in job [#29521](https://ci-apps.yunohost.org/ci/job/29521) !
[13:29:03]
<tituspijean[m]> Hi all, I'm trying to debug a sudden issue with GoToSocial, it somehow tells me my router is not a trusted proxy (YNH 13). Looking at the dev console on Firefox, I see no `X-Real-IP` or `X-Forwarded-For` headers, despite the NGINX conf (with the `/etc/nginx/proxy_params_no_auth`) being set. Can anyone replicate this with GtS or another app relying on proxy_params?
[13:29:15]
<Yunohost Git/Infra notifications> [penpot_ynh] orhtej2 pushed to v2.14.0: v2.14.0 ([bae061a6](https://github.com/YunoHost-Apps/penpot_ynh/commit/bae061a64702e4df49352b2fcccb5906cfd1cde3))
[13:29:59]
<Yunohost Git/Infra notifications> [penpot_ynh] orhtej2 opened [pull request #187](https://github.com/YunoHost-Apps/penpot_ynh/pull/187): v2.14.0
[13:31:34]
<Yunohost Git/Infra notifications> [penpot_ynh] orhtej2 [commented](https://github.com/YunoHost-Apps/penpot_ynh/pull/187#issuecomment-4118341164) on [issue #187](https://github.com/YunoHost-Apps/penpot_ynh/pull/187) v2.14.0: trixietestme
[13:42:27]
<Yunohost Git/Infra notifications> App pretalx goes down from level 7 to 1 in job [#29522](https://ci-apps.yunohost.org/ci/job/29522)
[13:48:45]
<orhtej2> Worked for me with planka in ynh 12
[14:08:05]
<tituspijean[m]> thank you, I looked further in and my conclusions are:
- the x-real-ip header is between NGINX and the app via its internal port, it's normal I do not see it on the browser side
- I see my phone's cellular IP if I disable WiFi, so the issue is my router's not passing through local IPs. It's inconvenient but not that much of an issue.
I'll look into why GtS still does not trust the IP address of the router now xD
[14:14:18]
<Yunohost Git/Infra notifications> App synapse rises from level 6 to 8 in job [#29524](https://ci-apps.yunohost.org/ci/job/29524) !
[14:15:55]
<otm33> same warning with gts
[15:22:32]
<m606> do we have app packages that modify DNS records? and would that be acceptable ? cf. https://chatmail.at/doc/relay/getting_started.html (via https://forum.yunohost.org/t/chatmail-relay-server-for-delta-chat)
[15:31:26]
<m606> yes I guess - https://github.com/YunoHost-Apps/prosody_ynh/blob/0427f7bb0248b1c1b054c7e05265cae2ca582713/hooks/custom_dns_rules#
[15:32:27]
<Yunohost Git/Infra notifications> App wordpress rises from level 6 to 8 in job [#29536](https://ci-apps.yunohost.org/ci/job/29536) !
[16:30:00]
<trendless> m606: would it be easier to incorporate something like [madmail](https://github.com/themadorg/madmail) rather than adapt the official method? Either way, I'm running a relay using the official method (on its own server, not a ynh server), so happy to assist any way I can
[16:30:08]
<Yunohost Git/Infra notifications> [roundcube_ynh] m4lvin [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/259#issuecomment-4119671339) on [issue #259](https://github.com/YunoHost-Apps/roundcube_ynh/issues/259) Upgrading Roundcube 1.6.12~ynh1 to 1.6.13~ynh1fails: Same problem and same solution when updating from 1.6.13~ynh1 to 1.6.14~ynh1.
[16:43:56]
<Yunohost Git/Infra notifications> App privtracker stays at level 4 in job [#29548](https://ci-apps.yunohost.org/ci/job/29548)
[16:49:03]
<m606> Well i have been exploring a bit the official method to check how feasible it is, and only the analysis part is quite some work as the official method is a [full server install](https://github.com/chatmail/relay/blob/e8933c455f9eb4217cbb3461a6b603f26bb9cccd/cmdeploy/src/cmdeploy/deployers.py#L631-L652) on the top of a fresh Debian 12 install, with all the mail stack. As some of it is already installed and configured on the YNH server, it has to be analyzed what is not already here and what requires different config.
I noted in particualr that chatmail uses a [fork of Dovecot](https://github.com/chatmail/relay/blob/e8933c455f9eb4217cbb3461a6b603f26bb9cccd/scripts/dovecot/README.md), so could we install 2 dovecot versions in parallel or should we replace YNH one by the Chatmail one (the latter solution not being very good in terms of further technical support)?
I didn't know about madmail. It would be run in parallel from dovecot I guess? [Install instructions](https://github.com/themadorg/madmail/blob/main/docs/chatmail-setup.md) would make the "analysis part" much simpler indeed. In terms of resource consumption it could be higher as [they recommend 1GB RAM for a small personal severs](https://github.com/themadorg/madmail/blob/main/docs/faq.md#what-is-resource-usage-of-maddy), vs. official setup which [asks 1GB RAM for thousands of addresses](https://chatmail.at/doc/relay/getting_started.html#minimal-requirements-and-prerequisites) (it depends on what they call "small" of course).
How do you think it compares to [this feature list](https://forum.yunohost.org/t/chatmail-relay-server-for-delta-chat/40341/3)?
Just being curious - why would you rather use DeltaChat over XMPP or Matrix clients ?
[16:59:19]
<trendless> I've run all three and I prefer chatmail/deltachat. But this is definitely a topic that invites many much flamewar xD
[16:59:23]
<trendless> I'm not familiar with the ins and outs of madmail, but it and one other packaged mail server are being worked on as alternatives to the official method
[16:59:25]
<Yunohost Git/Infra notifications> [roundcube_ynh] oleole39 [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/259#issuecomment-4119865338) on [issue #259](https://github.com/YunoHost-Apps/roundcube_ynh/issues/259) Upgrading Roundcube 1.6.12~ynh1 to 1.6.13~ynh1fails: > Can this help? https://forum.yunohost.org/t/resolu-loperation-mettre-a-jour-lapplication-roundcube-a-echoue/41870
Her...
[17:06:07]
<trendless> I understand that routing all communication through port 443 is being discussed for implementation, at least via the official method. That would make running an alternative stack more feasible in ynh, yeah?
[17:06:09]
<trendless> I think the intention for madmail and other alternative implementations is to have feature parity with the official implementation
[17:06:12]
<trendless> if I'm not mistaken, at least madmail is being worked on in conjunction with some of the official devs
[17:06:13]
<m606> i have probably missed that
[17:06:16]
<trendless> it's come up in the chatmail ops chatrooms a few times
[17:06:19]
<m606> hmm ok, in search of a simpler alternative you think?
[17:07:02]
<trendless> chatmail's not a replacement for XMPP/Matrix in group chat contexts. It lacks much in the way of admin controls.
[17:07:04]
<trendless> yes, single binary that can be deployed in a variety of situations that the official pyinfra installer can't really address
[17:07:05]
<m606> oh I had understood you meant that was in discussion at YNH
[17:08:02]
<trendless> oh, no, by the devs themselves
[17:11:34]
<trendless> for bypassing port blocks, censorship, et al, the chatmail devs want the chatmail relays not to need any other ports besides 443
[17:11:36]
<trendless> but it's not there yet
[17:11:38]
<m606> ok well yes that would make it even simpler, but even [opening 5 ports](https://github.com/themadorg/madmail/blob/main/docs/chatmail-setup.md#5-prerequisites--troubleshooting) should not a big deal in terms of YNH packaging. I just do not really measure the potential collision risk with other services/apps, but hopefully nginx in YNH is doing it right
[17:13:30]
<trendless> I was thinking it's the needing ports currently used by ynh's email implementation that may be the biggest blocker, yeah?
[17:13:31]
<m606> and as you say madmail is supported by official devs as a future replacement for current official instructions, I agree that it makes sense to use that rather than official install. Well it is rated as beta for now, but...
[17:14:39]
<m606> errr port redirection with nginx is still a bit of mystery to me, never dug far enough and never know what to expect
[17:16:06]
<trendless> I dunno if it'll replace the official pyinfra method, but it'll be an alternative for situtations where the official isn't viable
[17:16:06]
<m606> well if it is much simpler to install, it will also likely be much simpler to maintain for them