[06:31:30]
<Yunohost Git/Infra notifications> [issues] chri2 [commented](https://github.com/YunoHost/issues/issues/2414#issuecomment-2188086552) on [issue #2414](https://github.com/YunoHost/issues/issues/2414) improve handling of app_senders_login_maps: For flohmarkt and gotosocial Ill try to do this: * write helpers to write the postfix file (no problems here, already ...
[12:19:09]
<Yunohost Git/Infra notifications> [yunohost] alexAubin pushed 2 commits to dev ([9982a7758207...feb9a095b3c4](https://github.com/YunoHost/yunohost/compare/9982a7758207...feb9a095b3c4))
[12:21:09]
<Yunohost Git/Infra notifications> [yunohost] alexAubin pushed 1 commit to dev: Update changelog for 11.2.17.1 ([87eedc2a](https://github.com/YunoHost/yunohost/commit/87eedc2a369baa72c9b8d46154924f667885c085))
[12:21:09]
<Yunohost Git/Infra notifications> [yunohost] alexAubin created new tag debian/11.2.17.1
[12:22:11]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.2.17.1 for bullseye/stable/all ...
[12:26:02]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.2.17.1 for bullseye/stable/all.
[12:33:14]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.2.17.1+202406251230 for bullseye/unstable/all ...
[12:33:16]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.2.17.1+202406251230 for bullseye/unstable/all.
[12:33:16]
<Yunohost Git/Infra notifications> [yunohost] ✖️ Pipeline [#1347180033](https://gitlab.com/YunoHost/yunohost/-/pipelines/1347180033) canceled on branch dev
[12:33:17]
<Aleks (he/him/il/lui)> gotta work for $dayjob today @_@
[13:47:37]
<Yunohost Git/Infra notifications> [yunohost] kay0u created new branch fix-regex-in-ynh_write_var_in_file/ynh_read_var_in_file
[13:47:57]
<Yunohost Git/Infra notifications> [yunohost] kay0u pushed 1 commit to fix-regex-in-ynh_write_var_in_file/ynh_read_var_in_file: fix regex in ynh_write_var_in_file/ynh_read_var_in_file ([09ae7046](https://github.com/YunoHost/yunohost/commit/09ae7046832c74d6cf801ad62fa1de0e634730d8))
[13:55:13]
<Yunohost Git/Infra notifications> [yunohost] kay0u opened [pull request #1880](https://github.com/YunoHost/yunohost/pull/1880): fix regex in ynh_write_var_in_file/ynh_read_var_in_file
[13:56:19]
<Yunohost Git/Infra notifications> [yunohost] kay0u edited [pull request #1880](https://github.com/YunoHost/yunohost/pull/1880): fix regex in ynh_write_var_in_file/ynh_read_var_in_file
[13:58:59]
<Aleks (he/him/il/lui)> u wot m8
[14:00:36]
<kayou> sowwy (my turn)
[14:14:37]
<Aleks (he/him/il/lui)> i have no idea how to review apart from blindly trusting and yolomerging 😅
[14:32:17]
<kayou> please don't
[14:32:21]
<kayou> :)
[14:32:33]
<kayou> i have no idea how you can review it too
[14:34:38]
<kayou> i think we should define which type of file we can read/write with these functions, and write some tests
[14:36:16]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/tests/test_helpers.d/ynhtest_config.sh#L267
[14:36:53]
<Aleks (he/him/il/lui)> but yeah the helpers are designed to be magic and magic is often not robust
[14:41:08]
<Aleks (he/him/il/lui)> the alternative would be to have a read/write connector for each common format (maybe based on jq/yq ? + need also php/py/.env/..), and possibility to add custom connectors ...
the other alternative would be to systematically regen the entire file somehow with `ynh_config_add`
[14:43:24]
<Aleks (he/him/il/lui)> it's a bit ironic that the current bug happens with the yunohost setting file when using `ynh_app_setting_get` would work just fine x_x
[14:56:49]
<Yunohost Git/Infra notifications> [yunohost] kay0u created new branch more-test-on-config-read
[14:57:56]
<Yunohost Git/Infra notifications> [yunohost] kay0u pushed 1 commit to more-test-on-config-read: more test on config read ([10791321](https://github.com/YunoHost/yunohost/commit/1079132177aa97980610d76afe10c292fb6300b6))
[14:58:09]
<Yunohost Git/Infra notifications> [yunohost] kay0u opened [pull request #1881](https://github.com/YunoHost/yunohost/pull/1881): more test on config read
[14:58:12]
<kayou> let see if it catch the error
[14:59:44]
<Yunohost Git/Infra notifications> [nextcloud_ynh] ci-apps-dev: level 2 https://ci-apps-dev.yunohost.org/ci/job/17232 on commit https://github.com/YunoHost-Apps/nextcloud_ynh/commit/4d8b668ebfa7cb4a1d3cd06780bfb2b1f64d830c "Update upgrade" by @Éric Gaspar on branches v2_PostgreSQL
[15:00:01]
<kayou> > <@yunohostinfra:matrix.org> [yunohost] kay0u edited [pull request #1880](https://github.com/YunoHost/yunohost/pull/1880): fix regex in ynh_write_var_in_file/ynh_read_var_in_file
tests from this PR: https://gitlab.com/YunoHost/yunohost/-/jobs/7182456843
[15:00:06]
<kayou> my fix is not a fix
[15:16:57]
<Yunohost Git/Infra notifications> [yunohost] kay0u pushed 1 commit to more-test-on-config-read: more tests with dot ([070b0f1e](https://github.com/YunoHost/yunohost/commit/070b0f1ef44382654cd26a8f412a7856d07d8e3f))
[15:18:54]
<Yunohost Git/Infra notifications> [yunohost] ✖️ Pipeline [#1347453519](https://gitlab.com/YunoHost/yunohost/-/pipelines/1347453519) canceled on branch more-test-on-config-read
[15:19:37]
<kayou> it seems the issue is the . in the name
[15:19:44]
<kayou> `checksum__var_www_borg__2_logging.conf: 1079d7c7ce64c436266c27451e6badaa`
[15:20:17]
<kayou> maybe we can just replace dots in key to something else (`_` for example?)
[15:20:19]
<Aleks (he/him/il/lui)> must ... not ... refactor
[15:21:01]
<Aleks (he/him/il/lui)> imho we should not replace anything in the first place, because we can't infer in a clean robust way what's the original path ...
[15:21:24]
<Aleks (he/him/il/lui)> because `/` are replaced by `_` which could be just a `_` from the filename
[15:22:51]
<Aleks (he/him/il/lui)> alternatively we could forget about the problem and write a custom getter/setter for that particular key in borg config panel x_x
[15:37:29]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#1347346717](https://gitlab.com/YunoHost/yunohost/-/pipelines/1347346717) failed on branch fix-regex-in-ynh_write_var_in_file/ynh_read_var_in_file
[16:48:33]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#1347487170](https://gitlab.com/YunoHost/yunohost/-/pipelines/1347487170) failed on branch more-test-on-config-read
[20:55:00]
<Yunohost Git/Infra notifications> [SSOwat] yunohost-bot opened [pull request #230](https://github.com/YunoHost/SSOwat/pull/230): Translations update from Weblate
[21:38:44]
<Aleks (he/him/il/lui)> i realize there's a stupid edge case when restoring apps
[21:38:58]
<Aleks (he/him/il/lui)> restoring fail2ban conf without restoring the /var/log/$app folder
[21:39:15]
<Aleks (he/him/il/lui)> because stupid fail2ban will not start if the target logs don't exist
[21:39:33]
<Aleks (he/him/il/lui)> so if you restore the app on another fresh system, /var/log/$app won't exist and this breaks fail2ban ?
[21:39:50]
<Aleks (he/him/il/lui)> I don't even understand how it didn't get caught by the CI yet since we test restore on a fresh system ?
[21:39:53]
<Salamandar> yeah
[21:40:10]
<Salamandar> mkdir /var/log/$app OR restore /var/log/$app is required
[21:40:24]
<Salamandar> i thought that was common knowledge :D
[21:41:30]
<Aleks (he/him/il/lui)> yeah but we're also saying "you shouldn't backup/restore /var/log/$app"
[21:41:48]
<Aleks (he/him/il/lui)> (or are we ?)
[21:42:09]
<Salamandar> > <@Alekswag:matrix.org> yeah but we're also saying "you shouldn't backup/restore /var/log/$app"
ARE WE ?
[21:42:12]
<Salamandar> no we aren't
[21:42:23]
<Salamandar> we are just saying "you shouldn't delete it"
[21:42:26]
<Aleks (he/him/il/lui)> ah no, we should backup /var/log/$app and $data_dir but the helpers2.1 automagically applies the --is-big logic
[21:42:31]
<Salamandar> haha
[21:42:36]
<Salamandar> although
[21:42:44]
<Aleks (he/him/il/lui)> so we SHOULD backup it
[21:42:59]
<Salamandar> backup (/var/log) -> remove (not /var/log) -> restore (/var/log) would the restore script fail because it already exists ?
[21:44:26]
<Aleks (he/him/il/lui)> 🥴
[21:44:26]
<Aleks (he/him/il/lui)> eeeeh
[21:44:41]
<Salamandar> although it's the same with data_dir
[21:44:45]
<Salamandar> so "eh"
[21:44:47]
<Aleks (he/him/il/lui)> the case is handled in ynh_restore(_file)
[21:44:49]
<Salamandar> let the user handle that
[21:44:59]
<Salamandar> > <@Alekswag:matrix.org> the case is handled in ynh_restore(_file)
ah ?
[21:45:25]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/helpers/helpers.v1.d/backup#L262 🤔
[21:46:24]
<Salamandar> some other subject
[21:46:26]
<Salamandar> the README `level` pill links to `https://dash.yunohost.org/appci/app/owntracks`
[21:46:34]
<Salamandar> so the link is broken with the new dashboard
[21:46:50]
<Salamandar> not "too" broken but it only links to the list of all the apps
[21:48:56]
<Aleks (he/him/il/lui)> yeah it redirects to https://apps.yunohost.org/dash ?
[21:49:07]
<Aleks (he/him/il/lui)> it's "by design" but not really convenient
[21:49:18]
<Salamandar> not convenient is the word here :)
[21:49:23]
<Salamandar> not dramatic though
[21:49:26]
<Aleks (he/him/il/lui)> there's just no direct link to the dash / ci info for one specific app
[21:49:33]
<Salamandar> yeah indeed
[21:49:41]
<Salamandar> maybe it should redirect to apps-ci
[21:49:42]
<Salamandar> idk
[21:50:08]
<Aleks (he/him/il/lui)> or we could link to the app page on ci-apps
[21:50:41]
<Aleks (he/him/il/lui)> https://ci-apps.yunohost.org/ci/apps/owntracks/
[21:51:26]
<Aleks (he/him/il/lui)> i guess that make more sense, personally when i click this link the majority of the time it's to go see the latest CI job ?
[21:53:55]
<Salamandar> yeah
[21:53:57]
<Salamandar> agreed
[21:54:03]
<Salamandar> i can patch the dash
[21:54:09]
<Salamandar> try to*
[21:57:40]
<Aleks (he/him/il/lui)> it's not in the dash, it's some sort of hardcoded redirect in the nginx conf on samurai iirc
[21:59:39]
<Salamandar> hah ok
[22:15:49]
<Aleks (he/him/il/lui)> hmmmm
[22:15:54]
<Aleks (he/him/il/lui)> did you just reload nginx ? 😬
[22:15:55]
<Aleks (he/him/il/lui)> ah it's back online
[22:18:03]
<Salamandar> huh
[22:21:34]
<Salamandar> but eh, that's fine
[22:21:34]
<Salamandar> https://ci-apps.yunohost.org/ci/apps/20euros is broken
[22:21:34]
<Salamandar> > <@Alekswag:matrix.org> did you just reload nginx ? 😬
idk why it sometimes fails when reloading, had to restart completely
[22:21:34]
<Salamandar> looks like ../resource.css is broken :D
[22:21:35]
<Salamandar> but https://ci-apps.yunohost.org/ci/apps/20euros/ with a trailing slash is OK
[22:21:46]
<Salamandar> all good, redirect is in place
[22:21:46]
<Aleks (he/him/il/lui)> cool cheers 👍️
[22:21:46]
<Aleks (he/him/il/lui)> yeah
[22:49:55]
<Aleks (he/him/il/lui)> > <@Alekswag:matrix.org> I don't even understand how it didn't get caught by the CI yet since we test restore on a fresh system ?
followup of the discussion on the chat : `systemctl restart fail2ban` won't be interpreted as a failure because fail2ban only fails a few ms later and so the service is temporarily active somehow ...
[22:50:34]
<Aleks (he/him/il/lui)> i guess we could add an automatic "wait until" in the helpers but then we gonna have a shitload of apps failing restore on a fresh system if they restore their fail2ban conf without the logs ?
[22:50:45]
<Aleks (he/him/il/lui)> i should check with a few greps
[22:51:48]
<Aleks (he/him/il/lui)> so tl;dr: this is an edge case we didn't think about yet ... but an immediate fix should be to run something like `mkdir -p /var/log/freshrss`, `touch /var/log/freshrss/freshrss.log` and `chown freshrss /var/log/freshrss/*.log`
[22:52:48]
<Aleks (he/him/il/lui)> ah hold on scratch that
[22:52:57]
<Aleks (he/him/il/lui)> what teh heck
[22:53:10]
<Aleks (he/him/il/lui)> https://github.com/YunoHost-Apps/freshrss_ynh/blob/master/scripts/install#L61C36-L61C65
[22:53:21]
<Aleks (he/him/il/lui)> `/var/log/${domain}-access.log`, wtf is this ...
[23:07:41]
<Aleks (he/him/il/lui)> OMG
[23:07:41]
<Aleks (he/him/il/lui)> another stupid bug I think I found the origin of
[23:07:41]
<Aleks (he/him/il/lui)> (╯°□°）╯︵ ┻━┻
[23:07:41]
<Aleks (he/him/il/lui)> https://github.com/YunoHost-Apps/searxng_ynh/blob/master/scripts/_common.sh#L116
[23:07:45]
<Aleks (he/him/il/lui)> resulting in
```
2024-06-25 22:44:25,930: DEBUG - Jun 25 22:44:25 uwsgi[46914]: [uWSGI] getting INI configuration from /etc/uwsgi/apps-available/searxng.ini
2024-06-25 22:44:25,931: DEBUG - Jun 25 22:44:25 uwsgi[46914]: open("/etc/uwsgi/apps-available/searxng.ini"): Permission denied [core/io.c line 525]
```
[23:08:11]
<Aleks (he/him/il/lui)> and indeed during the regular `ynh_add_uwsgi_service` it does a few user and group permission trickery
[23:08:38]
<Aleks (he/him/il/lui)> so i was like "how can this even work in a fresh restore in our ci test during restore on a fresh system"
[23:08:57]
<Aleks (he/him/il/lui)> but it's probably that `ynh_restore` cp the file with the same UID
[23:09:14]
<Aleks (he/him/il/lui)> and on a fresh system on the CI, since it's the only app installed, it will take THE SAME UID ? and therefore it works ?
[23:09:22]
<Aleks (he/him/il/lui)> but in a real life context it's not necessarily the same UID ?
[23:27:09]
<Salamandar> > <@Alekswag:matrix.org> `/var/log/${domain}-access.log`, wtf is this ...
nginx, it's kinda standard
[23:28:37]
<Aleks (he/him/il/lui)> yes, with nginx/ in the middle