[02:16:45]
<Yunohost Git/Infra notifications> [apps_tools] yunohost-bot opened [pull request #25](https://github.com/YunoHost/apps_tools/pull/25): Translations update from Weblate
[02:46:00]
<Yunohost Git/Infra notifications> [my_webapp_ynh] Most14 [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/152#discussion_r2022049512) on pull request #152 Remove FPM configuration mentions: ALL_README.md/ coffeescript python
[06:37:55]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/232#issuecomment-2768323776) on [issue #232](https://github.com/YunoHost-Apps/roundcube_ynh/issues/232) Install fails because of php-net_ldap3 unreachable: https://git.kolab.org is down
Maybe we should use [packagist release](https://packagist.org/packages/kolab/net_ldap3#v1...
[08:37:29]
<Yunohost Git/Infra notifications> [synapse_ynh] bee-media opened [issue #525](https://github.com/YunoHost-Apps/synapse_ynh/issues/525): Error 500 (Synapse) "PUT" /yunohost/api/apps/synapse/config/main
[09:28:07]
<Felix 3> > <@m606:matrix.org> the thing is that even if you go for option 1, it would require work to replace some of the defaults value of upstream config file with YNH templates tags (things like `__TIMEZONE__`, DB stuff pointed by Aleks, etc.) 🤔
I think I don't understand, could you please rephrase?
Do you mean that it would be work for me? The actual [upstream config](https://github.com/meeting-room-booking-system/mrbs-code/blob/main/web/config.inc.php-sample) is pretty tame, you only have to specify the options you want to override from that huge file with the defaults. Also, since I put auth and db settings in a seperate file, I can just use the regular templating mechanism from YunoHost to template out that config both during install and during upgrades.
For reference, here's what I have so far: [config.inc.php](https://github.com/felurx/mrbs_ynh/blob/main/conf/config.inc.php) (for customization, which I want to not leave to the admin) and [config-ynh.inc.php](https://github.com/felurx/mrbs_ynh/blob/main/conf/config-ynh.inc.php) (which I consider to be a packaged file, so I tell the admin to not edit it and that it can/will be overwritten during upgrades)
[14:49:13]
<Yunohost Git/Infra notifications> [cryptpad_ynh] ericgaspar pushed 1 commit to 2025.3.1: Update manifest.toml ([dd703eae](https://github.com/YunoHost-Apps/cryptpad_ynh/commit/dd703eaefcb7097689f7ddf49d16e2391b1540b9))
[14:49:14]
<Yunohost Git/Infra notifications> [cryptpad_ynh] ericgaspar created new branch 2025.3.1
[14:49:24]
<Yunohost Git/Infra notifications> [cryptpad_ynh] ericgaspar opened [pull request #240](https://github.com/YunoHost-Apps/cryptpad_ynh/pull/240): 2025.3.1
[15:06:38]
<m606> Well I meant what you have already been doing in `config-ynh.inc.php`.
But having a look at your split files, I wonder - if you plan to put only a selection of settings in `config.inc.php` (i.e. doing the grunt work of analyzing the whole config file anyway, heavy but helpful for the future admins), that means there would virtually be a third set of settings not offered for override to admins. Therefore I am not sure to understand the interest of splitting config files versus simply `ynh_add_config` the full default template with:
1. template tags integrated (i.e. what you have in `config-ynh.inc.php`, but directly in upstream config file template)
2. config panel to manage only selected options (those you have been planning so far to add to `config.inc.php`). Granted, that is a bit more declarative work to be done at packaging in `config_panel.toml` but that may not be too much depending on how many options you want to add here, and provided the data format is simple enough to be managed by YNH default config panel elements (i.e. not requiring custom getters/setters/showers).
3. remaining options left to default settings in the config file. An advanced admin could still go and change them in the config file which he/she would then have to backup/migrate himself/herself (but being "advanced", I believe we can expect he/she would have that in mind). Or submit and issue/PR to mrbs_ynh repo asking for that particular settings he/she needs you might consider to add later to the config panel.
[15:12:50]
<m606> that way you keep the structure of upstream file which to my mind eases the maintenance process - at upstream upgrade, you can diff that file with updated upstream config file, and see which lines have been added/changed and make the change accordingly in the YNH package's template config file rather than having to juggle with 3 differents files.
[15:15:04]
<m606> Well I meant what you have already been doing in `config-ynh.inc.php`.
But having a look at your split files, I wonder - if you plan to put only a selection of settings in `config.inc.php` (i.e. doing the grunt work of analyzing the whole config file anyway, heavy but helpful for the future admins), that means there would virtually be a third set of settings not offered for override to admins. Therefore I am not sure to understand the interest of splitting config files versus simply `ynh_add_config` the full default template with:
1. template tags integrated (i.e. what you have in `config-ynh.inc.php`, but directly in upstream config file template)
1. config panel to manage only selected options (those you have been planning so far to add to `config.inc.php`). Granted, that is a bit more declarative work to be done at packaging in `config_panel.toml` but that may not be too much depending on how many options you want to add here, and provided the data format is simple enough ([PHP files are supported](https://doc.yunohost.org/en/packaging_config_panels#:~:text=PHP)) to be managed by YNH default config panel elements (i.e. not requiring custom getters/setters/showers).
1. remaining options left to default settings in the config file. An advanced admin could still go and change them in the config file which he/she would then have to backup/migrate himself/herself (but being "advanced", I believe we can expect he/she would have that in mind). Or submit and issue/PR to mrbs_ynh repo asking for that particular settings he/she needs you might consider to add later to the config panel.
[15:19:23]
<Yunohost Git/Infra notifications> [apps] yunohost-bot opened [pull request #2900](https://github.com/YunoHost/apps/pull/2900): Add Nepenthes to wishlist
[15:19:24]
<Yunohost Git/Infra notifications> [apps] yunohost-bot labeled Wishlist on [pull request #2900](https://github.com/YunoHost/apps/pull/2900): Add Nepenthes to wishlist
[15:28:21]
<m606> I was considering making this package.
> This is a tarpit intended to catch web crawlers. Specifically, it's targetting crawlers that scrape data for LLMs - but really, like the plants it is named after, it'll eat just about anything that finds it's way inside. It works by generating an endless sequences of pages, each of which with dozens of links, that simply go back into a the tarpit. Pages are randomly generated, but in a deterministic way, causing them to appear to be flat files that never change. Intentional delay is added to prevent crawlers from bogging down your server, in addition to wasting their time. Lastly, optional Markov-babble can be added to the pages, to give the crawlers something to scrape up and train their LLMs on, hopefully accelerating model collapse.
Maybe that could even be something that would be optionally enabled to be integrated to YNH SSO login screen, to limit crawler scanning activity over the whole instance.
[15:33:55]
<m606> > <@m606:matrix.org> I was considering making this package.
> > This is a tarpit intended to catch web crawlers. Specifically, it's targetting crawlers that scrape data for LLMs - but really, like the plants it is named after, it'll eat just about anything that finds it's way inside. It works by generating an endless sequences of pages, each of which with dozens of links, that simply go back into a the tarpit. Pages are randomly generated, but in a deterministic way, causing them to appear to be flat files that never change. Intentional delay is added to prevent crawlers from bogging down your server, in addition to wasting their time. Lastly, optional Markov-babble can be added to the pages, to give the crawlers something to scrape up and train their LLMs on, hopefully accelerating model collapse.
> Maybe that could even be something that would be optionally enabled to be integrated to YNH SSO login screen, to limit crawler scanning activity over the whole instance.
I guess actual integration could be just a link to the app's path
[15:34:13]
<m606> cf. demo: https://zadzmo.org/nepenthes-demo
[16:22:03]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/516#issuecomment-2769911041) on [issue #516](https://github.com/YunoHost-Apps/synapse_ynh/issues/516) Setting user as admin will not work on first installation: Closing now as no answer
[16:22:03]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T closed [issue #516](https://github.com/YunoHost-Apps/synapse_ynh/issues/516): Setting user as admin will not work on first installation
[16:22:10]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T closed [issue #525](https://github.com/YunoHost-Apps/synapse_ynh/issues/525): Error 500 (Synapse) "PUT" /yunohost/api/apps/synapse/config/main
[16:22:10]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T labeled duplicate on [issue #525](https://github.com/YunoHost-Apps/synapse_ynh/issues/525): Error 500 (Synapse) "PUT" /yunohost/api/apps/synapse/config/main
[16:22:10]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/issues/525#issuecomment-2769912762) on [issue #525](https://github.com/YunoHost-Apps/synapse_ynh/issues/525) Error 500 (Synapse) "PUT" /yunohost/api/apps/synapse/config/main: Closing as duplicated of #514
[16:22:20]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T pinned [issue #514](https://github.com/YunoHost-Apps/synapse_ynh/issues/514): Cant change synapse settings via config interface
[16:23:00]
<Yunohost Git/Infra notifications> [apps] yunohost-bot opened [pull request #2901](https://github.com/YunoHost/apps/pull/2901): Add Restreamer to wishlist
[16:23:01]
<Yunohost Git/Infra notifications> [apps] yunohost-bot labeled Wishlist on [pull request #2901](https://github.com/YunoHost/apps/pull/2901): Add Restreamer to wishlist
[16:37:43]
<Yunohost Git/Infra notifications> [apps] alexAubin [commented](https://github.com/YunoHost/apps/pull/2901#discussion_r2023207482) on pull request #2901 Add Restreamer to wishlist: suggestion description = "Live video streaming from any source to any destination, even multiple destinations."
[18:20:42]
<m606> > allow_email: (default: False) Enable authentication on the mail stack for the system user and send mail using __APP__@__DOMAIN__. A mail_pwd setting is automatically defined (similar to db_pwd for databases). You can then configure the app to use __APP__ and __MAIL_PWD__ as SMTP credentials (with host 127.0.0.1). You can also tweak the user-part of the domain-part of the email used by manually defining a custom setting mail_user or mail_domain
https://doc.yunohost.org/en/packaging_apps_resources#properties-4
So can we just have `__MAIL_USER__@__MAIL_DOMAIN__` for both sending address and user login ? or user login remains __APP__ ?
Would that increase risk of rejection from receiver mailbox due to domain mismatch or something like this ?
[18:20:57]
<m606> > allow_email: (default: False) Enable authentication on the mail stack for the system user and send mail using __APP__@__DOMAIN__. A mail_pwd setting is automatically defined (similar to db_pwd for databases). You can then configure the app to use __APP__ and __MAIL_PWD__ as SMTP credentials (with host 127.0.0.1). You can also tweak the user-part of the domain-part of the email used by manually defining a custom setting mail_user or mail_domain
https://doc.yunohost.org/en/packaging_apps_resources#properties-4
So can we just have `__MAIL_USER__@__MAIL_DOMAIN__` for both sending address and user login ? or user login remains `__APP__` ?
Would that increase risk of rejection from receiver mailbox due to domain mismatch or something like this ?
[18:24:02]
<m606> also, given host is localhost, no need of encrypted auth method (SSL or TLS), right ?
[18:42:43]
<orhtej2> > <@m606:matrix.org> also, given host is localhost, no need of encrypted auth method (SSL or TLS), right ?
Tls is mandatory and you'll be presented with cert for main domain
[18:52:34]
<Yunohost Git/Infra notifications> [cryptpad_ynh] ericgaspar merged [pull request #240](https://github.com/YunoHost-Apps/cryptpad_ynh/pull/240): 2025.3.1
[19:47:54]
<Yunohost Git/Infra notifications> yalh76 edited repository pinepods_ynh https://github.com/YunoHost-Apps/pinepods_ynh
[19:47:54]
<Yunohost Git/Infra notifications> yalh76 created repository pinepods_ynh https://github.com/YunoHost-Apps/pinepods_ynh
[20:08:26]
<m606> > Tls is mandatory and you'll be presented with cert for main domain
do you mean it for app SMTP configuration?
[20:09:41]
<m606> hmm ok
[21:45:35]
<orhtej2> I mean even on port 25 whats-it-name will require TLS auth
[21:45:37]
<orhtej2> dovecot?
[22:10:44]
<miro5001> Can we have a custom email address for allowemail instead of app@domain
Something like noreply@domain or contact@domain or anything depending on the app.
Now I have changed manually some config files for some apps to use an account from the yunohost users (with an alias)
[22:22:56]
<Aleks (he/him/il/lui)> https://doc.yunohost.org/packaging_apps_resources#system-user
>`allow_email`: (default: False) Enable authentication on the mail stack for the system user and send mail using `__APP__@__DOMAIN__`. A `mail_pwd` setting is automatically defined (similar to `db_pwd` for databases). You can then configure the app to use `__APP__` and `__MAIL_PWD__` as SMTP credentials (with host 127.0.0.1). You can also tweak the user-part of the domain-part of the email used by manually defining a custom setting `mail_user` or `mail_domain`
[22:23:09]
<Yunohost Git/Infra notifications> [syncthing_ynh] yunohost-bot opened [pull request #204](https://github.com/YunoHost-Apps/syncthing_ynh/pull/204): Upgrade to v1.29.4
[22:26:24]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 9 pending update PRs
- 11 new apps PRs
- 14 failed apps updates: appflowy, jenkins, khatru-pyramid, kiwix, languagetool, lemmy, localai, misskey, ofbiz, opencloud, phpldapadmin, pixelfedglitch, snweb, stremio
See the full log here: https://paste.yunohost.org/raw/suronitico
[22:32:56]
<m606> > <@Alekswag:matrix.org> https://doc.yunohost.org/packaging_apps_resources#system-user
>
> >`allow_email`: (default: False) Enable authentication on the mail stack for the system user and send mail using `__APP__@__DOMAIN__`. A `mail_pwd` setting is automatically defined (similar to `db_pwd` for databases). You can then configure the app to use `__APP__` and `__MAIL_PWD__` as SMTP credentials (with host 127.0.0.1). You can also tweak the user-part of the domain-part of the email used by manually defining a custom setting `mail_user` or `mail_domain`
That is the value that will be sent in the `From` headers, right ?
[22:33:31]
<m606> I mean `__MAIL_USER__@__MAIL_DOMAIN__`
[22:33:56]
<orhtej2> > <@m606:matrix.org> That is the value that will be sent in the `From` headers, right ?
Impersonating anything but `$app` will get you an auth error
[22:34:12]
<orhtej2> > <@m606:matrix.org> I mean `__MAIL_USER__@__MAIL_DOMAIN__`
Yes
[22:35:02]
<m606> > Impersonating anything but `$app` will get you an auth error
so is the doc wrong about that possibility of using something else than $app ?
[22:39:12]
<m606> i mean in the app I am currently trying to package, it asks for
- `from` header: i though about having custom `__MAIL_USER__@__MAIL_DOMAIN__` (two variables editable in config panel) but I get from your message that it would fail ? And even if it was not failing I wonder whether it would have an impact on the "spam score", i.e. potentially using a domain not associated with the sending IP ?
- mail login: for this I guess in any case I should stick to `__APP__` ?
[22:43:26]
<Aleks (he/him/il/lui)> 1. it should be fine and shouldnt impact the spam score, the whole point of all this is that the user is properly authenticated on the mail stack and therefore mails are signed dkim etc
2. yes
[22:45:00]
<m606> Other thing getting me confused, I am supposed to add those config params in the app config file as indicated in the app install instructions. But that is a Django app, and YNH Django template app shows [similar config options](https://github.com/YunoHost-Apps/django-fritzconnection_ynh/blob/1afb28724a3a173a0186dc0149e8ee70b76528e1/scripts/_common.sh#L28) in `_common.sh`. Are they the same ? In this case I can remove them from `_common.sh` ?
[22:46:40]
<m606> https://docs.pretix.eu/self-hosting/config/#email
[22:46:52]
<Aleks (he/him/il/lui)> hmpf i'm not convinced about the meaningfulness of declaring all those global vars that are probably only used in the actual conf template, instead of writing directly `__APP__@__DOMAIN__` in the conf template directly in the first place ... that just dilutes everything and create artificial complexity
[22:47:28]
<Aleks (he/him/il/lui)> ```
__YNH_CURRENT_HOST__=${ynh_current_host}
```
[22:47:28]
<Aleks (he/him/il/lui)> wat
[22:47:59]
<Aleks (he/him/il/lui)> nononono.jpg
[22:50:08]
<Aleks (he/him/il/lui)> https://c.tenor.com/ubboSatrrVEAAAAd/tenor.gif
[22:50:09]
<m606> sorry mistake in the link, this is the real template https://github.com/YunoHost-Apps/django_example_ynh/blob/master/scripts/_common.sh
previous one is an app using it.
[22:50:09]
<m606> but it won't change your surprise
[22:50:09]
<Aleks (he/him/il/lui)> https://c.tenor.com/KjJTBQ9lftsAAAAC/tenor.gif
[22:50:36]
<m606> I don't know what is $ynh_current_host, and I didn't know we could define var this way round in bash )
[22:53:44]
<m606> > <@Alekswag:matrix.org> hmpf i'm not convinced about the meaningfulness of declaring all those global vars that are probably only used in the actual conf template, instead of writing directly `__APP__@__DOMAIN__` in the conf template directly in the first place ... that just dilutes everything and create artificial complexity
you mean remove it from common.sh and leave it to app config file only, right ?
[22:53:56]
<Aleks (he/him/il/lui)> yup
[22:53:59]
<m606> thanks
[23:02:23]
<m606> app instructions suggest `/etc/pretix/pretix.cfg` for config path, but I guess it would be simpler if `$data_dir` or `$install_dir` ? Not sure if there is a "best choice" ?
[23:02:39]
<m606> app instructions suggest `/etc/pretix/pretix.cfg` for config path, but I guess it would be simpler in `$data_dir` or `$install_dir` ? Not sure if there is a "best choice" ?
[23:03:57]
<Aleks (he/him/il/lui)> i'd say config should go in `$install_dir`