[00:07:57]
<rodinux> well, I discover paheko_ynh needs to be installed on root __PATH__ to send correctly emails on a dedicated domain.
[00:08:31]
<rodinux> So I add a DISCLAIMER.md...
[00:09:04]
<Aleks (he/him/il/lui)> i have no idea why the web configuration would somehow affect the ability to send emails ...
[00:09:24]
<Aleks (he/him/il/lui)> that's like the color of your plants changing the temperature in the fridge
[00:10:24]
<rodinux> I also can't explain why, surely a specific configuration on the code of the app...
[00:12:02]
<rodinux> but I can confirm, when I wa trying debug the mails with few instances, I have similar issues, like the topic in the forum...
[00:13:27]
<rodinux> Or perhaps something wrong with these lines https://github.com/YunoHost-Apps/paheko_ynh/blob/7dd15034f11415735c46f8a7b2fcf18093500a69/conf/config.local.php#L171-L180
[00:15:21]
<rodinux> I am not sure, I will just add a DISCLAIMER.md for now...
[00:15:38]
<Aleks (he/him/il/lui)> dunno why those `WWW_` vars would affect the mail config ...
[00:16:21]
<Aleks (he/him/il/lui)> NB: DISCLAIMER.md has been replaced with the whole panoply, ADMIN.md, PRE_INSTALL.md, POST_INSTALL.md etc
[00:18:20]
<rodinux> Ah OK, so I can add a PRE_INSTALL.md and will have all the panoply XD
[00:22:20]
<rodinux> also I have edit the manifest.toml `install.path` with `default = "/"`
[00:33:45]
<rodinux> are you ok to review the PR Aleks (he/him/il/lui) https://github.com/YunoHost-Apps/paheko_ynh/pull/45
[00:37:33]
<Aleks (he/him/il/lui)> that sounds overly complicated ... i don't think this is the right place to explain people how to add a new domain, many app require a dedicated domain and do not do this
Additionally if this is really a show-stopper that email don't work for some reason on a subpath, then it should be entirely disabled and you should remove the `path` question from the manifest entirely
If you still want to allow people to install on a subpath nevertheless, then just say something like : `Important: for some reason, email does not work when installing on a subpath. You are encouraged to use a full, dedicated for this domain (with path set to /)`
[00:42:24]
<rodinux> > <@Alekswag:matrix.org> that sounds overly complicated ... i don't think this is the right place to explain people how to add a new domain, many app require a dedicated domain and do not do this
>
> Additionally if this is really a show-stopper that email don't work for some reason on a subpath, then it should be entirely disabled and you should remove the `path` question from the manifest entirely
>
> If you still want to allow people to install on a subpath nevertheless, then just say something like : `Important: for some reason, email does not work when installing on a subpath. You are encouraged to use a full, dedicated for this domain (with path set to /)`
Ok, so I put this text on ADMIN.md better way, but can I still let path `default="/"` ?
[00:43:52]
<rodinux> another problem, if you did not use a root path, the script with the cron.php send a lot of logs, this application needs emails for associations...
[00:44:15]
<Aleks (he/him/il/lui)> send of lot of logs such as ..?
[00:45:14]
<Aleks (he/him/il/lui)> >Ok, so I put this text on ADMIN.md better way, but can I still let path default="/" ?
Weeell, maybe ADMIN.md is fine but it feels odd to not warn the person right before the install ... But again, I don't know how much of a big deal it is that email work or do not work for this app ...
[00:49:48]
<rodinux> It is very important for this app. Je m'exprime en frnaçais: utile pour gérer des adhérents, leur adhésions et par défaut envoi des messages pour les échéances, messages de groupes dans l'association... bref, indipensable
[00:50:35]
<Aleks (he/him/il/lui)> ben si c'est indispensable et que pour une raison complètement mystique ça marche pas quand l'app est installée sous un sous-chemin, il faut désactiver l'install sur un sous-chemin et voila, rien besoin d'expliquer à qui que ce soit
[00:51:02]
<Aleks (he/him/il/lui)> (enfin rien à dire dans pre_install ou admin ou post_install sur le sujet)
[00:51:40]
<Aleks (he/him/il/lui)> normalement yunohost capte tout seul que l'app doit être installée sur un domain dédié et averti l'admin en conséquence (ou bien si c'est pas le cas c'est un bug de yunohost qui doit être corrigé dans yunohost)
[00:51:54]
<Aleks (he/him/il/lui)> et donc pour désactiver l'install sur un sous-chemin : il suffit d'enlever la question `path` du manifest
[00:55:23]
<rodinux> Tout simplement ? je vais faire cela pour l'instant, c'est encore le plus simple... Si je trouve comment résoudre plus tard on verra, mais là c'est le mieux à faire... par contre si des personnes ont garder un path, comment va se passer l'upgrade ??
[00:55:55]
<Aleks (he/him/il/lui)> ébeeeen ça devrait pas crasher leur instance mais bon ce sera un peu chelou quoi
[00:56:59]
<rodinux> je peux quand même mettre un message du coup en prévention... dans ADMIN.md
[01:00:29]
<rodinux> je rajoute tout de même pour ceux qui aurait ce souci `**Important**: for some reason, email does not work when installing on a subpath. You are encouraged to use a full, dedicated for this domain (with path set to /)`
[01:05:49]
<rodinux> du coup j'efface tout le champ ? https://github.com/YunoHost-Apps/paheko_ynh/blob/56f148e48b68aaf827091c4cf1ba12f4173c8635/manifest.toml#L33-L35
[01:06:20]
<Aleks (he/him/il/lui)> yup
[01:09:59]
<Yunohost Git/Infra notifications> [apps] @alexAubin created new branch coin
[01:10:00]
<Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to coin: Set coin to notworking ([e54105b9](https://github.com/YunoHost/apps/commit/e54105b9ea372e08453da5edf58a31f176cb9a09))
[01:10:36]
<Yunohost Git/Infra notifications> [apps] @alexAubin opened [pull request #1897](https://github.com/YunoHost/apps/pull/1897): Set coin to notworking
[01:40:37]
<rodinux> Well the test.toml upgrade from v1.2.8 failed, but i t si from Apr 9
[01:42:34]
<rodinux> pass from level 7 to level 6....
[02:26:44]
<Aleks (he/him/il/lui)> CI artefact, fixed it ..
[04:24:43]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-coblat: Add Coblat to wishlist ([ec2e1e8d](https://github.com/YunoHost/apps/commit/ec2e1e8df4655bc5002269d5ef99d219327f193a))
[04:24:44]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-coblat
[04:24:44]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1898](https://github.com/YunoHost/apps/pull/1898): Add Coblat to wishlist
[08:42:15]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636#issuecomment-1840275184) on [issue #636](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636) Fix redirect logout: During my test, when connected to Nextcloud with LDAP user, when I disconnect from Nextcloud there is no effect, I stay ...
[11:11:18]
<Yunohost Git/Infra notifications> App satdress goes down from level 8 to 1 in job [#21119](https://ci-apps.yunohost.org/ci/job/21119)
[12:21:29]
<Yunohost Git/Infra notifications> App snserver failed all tests in job [#21120](https://ci-apps.yunohost.org/ci/job/21120) :(
[14:34:07]
<Mateusz Szymański> > <@yunohostinfra:matrix.org> App snserver failed all tests in job [#21120](https://ci-apps.yunohost.org/ci/job/21120) :(
> ✘✘✘ Your app only requires yunohost >= 4.0, 4.1 or 4.2, which tends to indicate that it may not be up to date with recommended packaging practices and helpers.
[14:48:12]
<Salamandar> I’m currently trying to work on transmission, and especially https://github.com/YunoHost-Apps/transmission_ynh/issues/105
[14:48:30]
<Salamandar> the issue is that there are ACLs on /home/yunohost.app/transmission removing the permission g+x
[14:48:59]
<Salamandar> ```
salamandar:yunohost.transmission:# getfacl .
# file: .
# owner: debian-transmission
# group: www-data
user::rwx
group::rwx #effective:rw-
group:multimedia:rwx #effective:rw-
mask::rw-
other::r--
default:user::rwx
default:group::rwx
default:group:multimedia:rwx
default:mask::rwx
default:other::r-x`
```
[14:49:15]
<Salamandar> I can’t find anywhere who sets those ACLs
[14:49:21]
<Salamandar> Aleks (he/him/il/lui): any idea ?
[14:49:52]
<Aleks (he/him/il/lui)> ogod
[14:50:18]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/helpers/multimedia 😬
[14:50:46]
<Aleks (he/him/il/lui)> and https://github.com/YunoHost/issues/issues/1981 😬
[14:50:55]
<Salamandar> yeah but it’s only multimedia not app
[14:50:59]
<Salamandar> … right ?
[14:51:34]
<Aleks (he/him/il/lui)> what do you mean it's only multimedia not app ..?
[14:53:55]
<Aleks (he/him/il/lui)> hmyeah i'm confused as well by what removes the ACL
[14:54:08]
<Aleks (he/him/il/lui)> is it related to the `mask::rw-` thing ?
[14:54:09]
<Salamandar> i’m talking about /home/yunohost.app/transmission
[14:54:14]
<Salamandar> not /home/yunohost.multimedia
[14:54:23]
<Salamandar> but maybe it’s handled the same way, idk
[14:54:59]
<Aleks (he/him/il/lui)> yeah idk there seem to be some `multimedia` perms in there hence why i immediately thought about the multimedia helpers but it's not clear
[14:55:38]
<Aleks (he/him/il/lui)> cf https://github.com/YunoHost-Apps/transmission_ynh/blob/testing/scripts/install#L77 though ...
[14:56:49]
<Aleks (he/him/il/lui)> the multimedia helpers contain `setfacl -RL -m m::rwx` though ...
[14:56:57]
<Aleks (he/him/il/lui)> (ie they set the mask to rwx)
[14:56:57]
<Salamandar> Ah yeah okay
[14:57:07]
<Salamandar> it sets acls on the source_dir too…
[14:57:57]
<Aleks (he/him/il/lui)> wat source_dir ? 😬
[14:58:30]
<Aleks (he/him/il/lui)> ah the option
[14:58:45]
<Salamandar> yep
[14:58:58]
<Aleks (he/him/il/lui)> yeah the permissions are on the source_dir, the destination dir is only a symlink so x_x
[14:59:31]
<Salamandar> ok so this fixes the issue : \`setfacl -m m::rwx /home/yunohost.app/transmission`
[14:59:34]
<Aleks (he/him/il/lui)> (which is debatable, maybe a mount bind would be better, but it's not clear to me what is exact intent / use case / constrains ...)
[14:59:36]
<Salamandar> ok so this fixes the issue : `setfacl -m m::rwx /home/yunohost.app/transmission`
[15:00:01]
<Salamandar> yeah hard to decide on that
[15:00:10]
<Salamandar> i’ll suggest this simple stupid fix on the package
[15:00:20]
<Salamandar> also this package is not maintained anymore
[15:00:21]
<Salamandar> hmm
[15:00:23]
<Salamandar> 😇
[15:00:30]
<Aleks (he/him/il/lui)> but the real question is why was it working before and not anymore x_x
[15:01:06]
<Salamandar> because symlinks i think…
[15:01:20]
<Salamandar> we’ve had another issue when moving to manifestv2 on transmission
[15:01:33]
<Salamandar> linked to symlinks (pun intended)
[15:03:35]
<Aleks (he/him/il/lui)> ok found it i think
[15:04:40]
<Aleks (he/him/il/lui)> in https://github.com/YunoHost-Apps/transmission_ynh/pull/104/files, in the upgrade script, the `chmod -R 764 $data_dir` got moved to the end of the script ... "6" for group is rw- ... so far this was not an issue because `ynh_multimedia_addfolder` is called after, but `chmod -R 764 $data_dir` was moved *after* the multimedia_addfolder
[15:04:58]
<Aleks (he/him/il/lui)> i don't even understand what the heck with "764"
[15:05:15]
<Aleks (he/him/il/lui)> who the hell wants a folder with `r` permission but not `x` ..
[15:05:33]
<Salamandar> ok but the issue here is on the ACL mask
[15:05:43]
<Aleks (he/him/il/lui)> hmm
[15:05:56]
<Aleks (he/him/il/lui)> i was thinking `chmod` changes the acl mask but idk
[15:06:13]
<Salamandar> but maybe the ACL mask inherits the permissions when first created ?
[15:06:14]
<Salamandar> yeah
[15:06:44]
<Salamandar> so instead of 764, 775 ?
[15:07:19]
<Aleks (he/him/il/lui)> actuall somebody mentionned the fix in https://github.com/YunoHost-Apps/transmission_ynh/issues/105#issuecomment-1789683024
[15:07:59]
<Aleks (he/him/il/lui)> yeah 775 sounds cool ...
[15:08:01]
<Salamandar> yes
[15:08:04]
<Salamandar> ok
[15:08:10]
<Salamandar> but it was not enough on my server
[15:08:16]
<Salamandar> that’s when i noticed the ACLs
[15:08:25]
<Aleks (he/him/il/lui)> 🤔
[15:10:17]
<Aleks (he/him/il/lui)> i just tried and calling chmod does changes the mask:
```
root@test-new-install:/home# getfacl yunohost.app/
# file: yunohost.app/
# owner: root
# group: root
user::rwx
user:alex:rwx
group::r-x
mask::rwx
other::r-x
root@test-new-install:/home# chmod 764 yunohost.app
root@test-new-install:/home# getfacl yunohost.app/
# file: yunohost.app/
# owner: root
# group: root
user::rwx
user:alex:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
```
[15:11:55]
<Salamandar> wtt
[15:15:55]
<Salamandar> alright
[15:16:19]
<Salamandar> my third PR on transmission is sent 😛
[15:16:38]
<Salamandar> but my first doesn’t even work…
[15:16:45]
<Salamandar> https://github.com/YunoHost-Apps/transmission_ynh/pull/106
[15:16:50]
<Salamandar> if someone wants to see what is happening
[15:17:17]
<Aleks (he/him/il/lui)> "not working" is just the intermediate step between "not existing" and "working" :P
[15:18:38]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636#issuecomment-1841000546) on [issue #636](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636) Fix redirect logout: > I stay on Nextcloud page without being logged out ?
[15:19:31]
<Leonard> https://aria.im/_matrix/media/v1/download/matrix.org/ZxMaCgLVmHaPhLhOYcdeJYcf
[15:19:33]
<Leonard> Hello, I'm developping an yunohost application for FastAPI and I try to implement configuration panel, And I wonder where is yunohost log about error reading configuration panel. Because I have the following error :
[15:22:19]
<Aleks (he/him/il/lui)> Salamandar: not sure to understand what doesnt work exactly
[15:22:20]
<Aleks (he/him/il/lui)> ah it still complains about the manually modified file
[15:22:27]
<Salamandar> yep
[15:22:27]
<Aleks (he/him/il/lui)> the CI is a bit misleading
[15:23:02]
<Aleks (he/him/il/lui)> it complains during the change_url script but what this is really symptomatic of, is that the file got modified between the first time it got added, and the end of the install script
[15:23:15]
<Aleks (he/him/il/lui)> (ideally the CI should complain about this at the end of the install test, not during the other tests)
[15:24:44]
<Aleks (he/him/il/lui)> hmm cant pinpoint the issue tho
[15:25:22]
<Aleks (he/him/il/lui)> > <@leolecolo:matrix.org> Hello, I'm developping an yunohost application for FastAPI and I try to implement configuration panel, And I wonder where is yunohost log about error reading configuration panel. Because I have the following error :
hmmyeah you could try to run something like `yunohost app config get <app_id>` maybe (not sure about the exact command)
[15:29:16]
<Aleks (he/him/il/lui)> > <@Alekswag:matrix.org> it complains during the change_url script but what this is really symptomatic of, is that the file got modified between the first time it got added, and the end of the install script
it's hella confusing, naively I'm thinking maybe starting the daemon, it's the daemon itself that is tweaking the configuration ? x_x
[15:30:25]
<Aleks (he/him/il/lui)> ```
2896 WARNING - "rpc-password": "3308YgScECYNXDZ98aLNhQoi",
2896 WARNING + "rpc-password": "{d4e474d8d3a58b110100586723f5f825943eca86LkJEK8Vr",
```
[15:30:33]
<Aleks (he/him/il/lui)> like it changes the rpc-password for some reason ?
[15:32:37]
<Aleks (he/him/il/lui)> dunno where that `{d4e474d8d3a58b110100586723f5f825943eca86LkJEK8Vr` would come from otherwise...
[15:34:00]
<Salamandar> I’m wondering about that yeah indeed
[15:34:21]
<Aleks (he/him/il/lui)> apparently in other test, that string always starts with a `{` for some reason ...
[15:34:22]
<Salamandar> but, still, in my PR i run "ynh delete checksum" before replacing it…
[15:34:28]
<Aleks (he/him/il/lui)> that's like the most boring issue ever
[15:34:30]
<Salamandar> haha
[15:34:52]
<Aleks (he/him/il/lui)> yeah but the warning happens buring the `backup_if_different` thing
[15:35:08]
<Aleks (he/him/il/lui)> that's when it checks if the checksum is different, and if so displays the diff (and backups the current file)
[15:35:53]
<Salamandar> ah !
[15:35:57]
<Salamandar> ok
[15:35:59]
<Aleks (he/him/il/lui)> i guess alternatively we can try to save the new file after we start the daemon in the install script ...
[15:36:50]
<Aleks (he/him/il/lui)> and also fetch the "new" rpc password from the file maybe using ynh_read_var_from_file and save it as a setting
[15:37:14]
<Aleks (he/him/il/lui)> otherwise next time we regen the file, the daemon will yet again put its own string with `{` i guess ...
[15:37:27]
<Aleks (he/him/il/lui)> or maybe it regens a new key everytime it starts idk
[15:37:41]
<Aleks (he/him/il/lui)> (but then why save it in the configuration)
[15:41:31]
<Salamandar> not every restart
[15:43:33]
<Aleks (he/him/il/lui)> good news :D
[15:46:43]
<Salamandar> huh
[15:46:50]
<Salamandar> if i put "totopouet" it overwrites it
[15:46:57]
<Salamandar> if i put "{totopouet" it keeps it
[15:46:59]
<Salamandar> interesting…
[15:49:00]
<Aleks (he/him/il/lui)> so maybe we can just prefix the generated key with `{` and voila
[15:51:05]
<Salamandar> yeah
[15:51:06]
<Salamandar> so weird…
[15:52:46]
<Salamandar> fack
[15:52:59]
<Salamandar> I have a weird configuration on my server, any password succeeds
[15:52:59]
<Salamandar> 😐️
[15:54:31]
<Salamandar> > "rpc-authentication-required": false,
yikes. Gotta fix this in the package…
[15:55:30]
<Aleks (he/him/il/lui)> trololo.mp4
[15:56:56]
<Mateusz Szymański> - what's your password?
- yes
[16:30:45]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636#issuecomment-1841151408) on [issue #636](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636) Fix redirect logout: > > I stay on Nextcloud page > > without being logged out ? Yes, without being logged out. https://github.com/YunoHost...
[16:30:56]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636#issuecomment-1841151408) on [issue #636](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/636) Fix redirect logout: > > I stay on Nextcloud page > > without being logged out ? Yes, without being logged out. https://github.com/YunoHos...
[16:40:49]
<Salamandar> OK, so after some tests
[16:41:25]
<Salamandar> when the rpc password starts with a {, it looks like it’s a checksum of some sorts, of the password we first put
[16:42:04]
<Salamandar> ```
salamandar:yunohost.transmission:# cat /etc/transmission-daemon/settings.json | grep rpc-pass
"rpc-password": "totopouet",
salamandar:yunohost.transmission:# systemctl start transmission-daemon
salamandar:yunohost.transmission:# cat /etc/transmission-daemon/settings.json | grep rpc-pass
"rpc-password": "{3575b3a655REDACTED OF COURSE I’M NOT A MORRON4cd36JV.fIjdz",
```
[16:42:16]
<Salamandar> and totopouet works (and nothing else)
[16:42:51]
<Aleks (he/him/il/lui)> @_@
[16:44:12]
<Salamandar> so maybe it reads the setting, computes a cryptographic "something", then stores it back
[16:44:20]
<Salamandar> it would make sense but it’s not documented it seems
[16:45:17]
<Salamandar> wooooo found something in the code
[16:45:18]
<Salamandar> auto constexpr DigestStringSize = TrSha1DigestStrlen;
auto constexpr SaltedPrefix = "{"sv;
[16:46:09]
<Salamandar> *yikes*
[16:53:43]
<Aleks (he/him/il/lui)> 🙃
[16:54:13]
<Aleks (he/him/il/lui)> or we can just call the save\_checksum helper after we start the daemon + overwrite the setting using ynh\_read\_var\_from\_file 🙃
[21:41:32]
<Yunohost Git/Infra notifications> App rustdesk-server failed all tests in job [#21137](https://ci-apps.yunohost.org/ci/job/21137) :(
[21:47:02]
<Yunohost Git/Infra notifications> App rustdesk-server failed all tests in job [#21137](https://ci-apps.yunohost.org/ci/job/21137) :(
[22:11:36]
<Yunohost Git/Infra notifications> App rustdesk-server failed all tests in job [#21137](https://ci-apps.yunohost.org/ci/job/21137) :(