Tuesday, March 18, 2025
apps@conference.yunohost.org
March
Mon Tue Wed Thu Fri Sat Sun
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 18
19
20
21
22
23
24
25
26
27
28
29
30
31
           

[10:36:12] <Yunohost Git/Infra notifications> [snappymail_ynh] T​agadda approved [pull request #194](https://github.com/YunoHost-Apps/snappymail_ynh/pull/194#pullrequestreview-2693901854) Keep domains and identities during upgrade
[10:36:43] <Yunohost Git/Infra notifications> [snappymail_ynh] T​agadda [commented](https://github.com/YunoHost-Apps/snappymail_ynh/pull/194#issuecomment-2732604730) on [issue #194](https://github.com/YunoHost-Apps/snappymail_ynh/pull/194) Keep domains and identities during upgrade: LGTM :)
[10:36:53] <Yunohost Git/Infra notifications> [snappymail_ynh] T​agadda merged [pull request #194](https://github.com/YunoHost-Apps/snappymail_ynh/pull/194): Keep domains and identities during upgrade
[10:37:28] <Yunohost Git/Infra notifications> [snappymail_ynh] T​agadda edited [pull request #195](https://github.com/YunoHost-Apps/snappymail_ynh/pull/195): Testing
[10:37:51] <Yunohost Git/Infra notifications> [snappymail_ynh] T​agadda [commented](https://github.com/YunoHost-Apps/snappymail_ynh/pull/195#issuecomment-2732611166) on [issue #195](https://github.com/YunoHost-Apps/snappymail_ynh/pull/195) Testing: bump
[15:17:34] <Yunohost Git/Infra notifications> [apps] y​unohost-bot opened [pull request #2875](https://github.com/YunoHost/apps/pull/2875): Add Bitwarden to wishlist
[15:17:34] <Yunohost Git/Infra notifications> [apps] y​unohost-bot labeled Wishlist on [pull request #2875](https://github.com/YunoHost/apps/pull/2875): Add Bitwarden to wishlist
[15:20:44] <Émy – OniriCorpe> > <@yunohostinfra:matrix.org> [apps] y​unohost-bot opened [pull request #2875](https://github.com/YunoHost/apps/pull/2875): Add Bitwarden to wishlist

??????
[15:21:45] <Yunohost Git/Infra notifications> [apps] O​niriCorpe [commented](https://github.com/YunoHost/apps/pull/2875#issuecomment-2733650630) on [issue #2875](https://github.com/YunoHost/apps/pull/2875) Add Bitwarden to wishlist: reject Use the Vaultwarden package instead
[15:21:53] <Yunohost Git/Infra notifications> [apps] y​unohost-bot edited [pull request #2875](https://github.com/YunoHost/apps/pull/2875): Add Bitwarden to rejection list
[15:22:45] <Yunohost Git/Infra notifications> [apps] O​niriCorpe merged [pull request #2875](https://github.com/YunoHost/apps/pull/2875): Add Bitwarden to rejection list
[15:22:45] <Yunohost Git/Infra notifications> [apps] O​niriCorpe deleted branch add-to-wishlist-bitwarden
[15:22:45] <Yunohost Git/Infra notifications> [apps] O​niriCorpe pushed 1 commit to master: Add Bitwarden to rejection list (#2875) * Add Bitwarden to wishlist * Reject Bitwarden from catalog ([f8b438ef](https://github.com/YunoHost/apps/commit/f8b438efd977893c3c2def63284cf5b73104b5b5))
[15:28:21] <mathieuw> > <@yunohostinfra:matrix.org> [apps] O​niriCorpe [commented](https://github.com/YunoHost/apps/pull/2875#issuecomment-2733650630) on [issue #2875](https://github.com/YunoHost/apps/pull/2875) Add Bitwarden to wishlist: reject Use the Vaultwarden package instead

I don't know if I know how to that, but maybe we should add 'Biwarden' in the field 'AlternativeTo' (or smthg like that, I don't remember what's the name of the field) in the .toml that describes the apps in the catalog. That way ppl realize VaultWarden is a self-hosted clone of BitWarden (they maybe don't know it).
Sorry if I can't be more explicit, I'm in a subway that's full of people, hard to manipulate my device, but I think you got it.
[15:37:55] <Aleks (he/him/il/lui)> hmyeah i was wondering the other day about having some sort of "alternative names" (for example minetest which was recently renamed etc)
[15:40:23] <m606> Hello, would there be a kind of mechanism in YNH for an app with access permissions given to several users and which asks user to link to personal files (i.e. it would require a config file containing filepaths per user) when the app itself doesn't have implemented any user account logic ?
One way I can imagine would be to install several instances of the app and allow access to one given instance to one given user only, but I wonder whether there would exist something simpler, that I could set at packaging level for instance admins?
[15:41:16] <m606> full context: https://github.com/s427/MARL/blob/main/server-mode.md#enable-server-mode
[16:06:02] <Yunohost Git/Infra notifications> [jellyfin_ynh] b​otagas [commented](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173#issuecomment-2733828445) on [issue #173](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173) Diagnosis complains about 1900 and 7359 ports exposure: In my case, the ports 1900 and 7359 are open (UDP), but I cannot see the server on any clients. I must type the URL:PORT...
[16:08:04] <Yunohost Git/Infra notifications> [jellyfin_ynh] b​otagas [commented](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173#issuecomment-2733828445) on [issue #173](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173) Diagnosis complains about 1900 and 7359 ports exposure: In my case, the ports 1900 and 7359 are open (UDP), but I cannot see the server on any clients. I must type the URL:PORT...
[16:09:52] <Yunohost Git/Infra notifications> [jellyfin_ynh] b​otagas [commented](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173#issuecomment-2733828445) on [issue #173](https://github.com/YunoHost-Apps/jellyfin_ynh/issues/173) Diagnosis complains about 1900 and 7359 ports exposure: In my case, the ports 1900 and 7359 are open (UDP), but I cannot see the server on any clients. I must type the URL:PORT...
[17:00:09] <Émy – OniriCorpe> > <@mathieuw:tetaneutral.net> I don't know if I know how to that, but maybe we should add 'Biwarden' in the field 'AlternativeTo' (or smthg like that, I don't remember what's the name of the field) in the .toml that describes the apps in the catalog. That way ppl realize VaultWarden is a self-hosted clone of BitWarden (they maybe don't know it).
> Sorry if I can't be more explicit, I'm in a subway that's full of people, hard to manipulate my device, but I think you got it.

We absolutely should do that yes
[19:38:23] <Yunohost Git/Infra notifications> [joplin_ynh] y​alh76 merged [pull request #86](https://github.com/YunoHost-Apps/joplin_ynh/pull/86): Upgrade to v3.3.3
[21:35:38] <miro5001> > <@m606:matrix.org> Hello, would there be a kind of mechanism in YNH for an app with access permissions given to several users and which asks user to link to personal files (i.e. it would require a config file containing filepaths per user) when the app itself doesn't have implemented any user account logic ?
> One way I can imagine would be to install one instance of the app and allow access to each instance to one user only, but I wonder whether there would exist something simpler, that I could set at packaging level for instance admins?

Depends how the app handles authentication. You can use /home/$user/app_name

[21:38:39] <m606> > <@miro5001:matrix.org> Depends how the app handles authentication. You can use /home/$user/app_name
>

the app has no auth mechanism
[21:39:24] <m606> by default it gets executed in the browser
[21:40:02] <m606> but with the new version it is possible to show content in the app on the server
[21:40:26] <m606> just need to add a config file with path to content
[21:42:31] <m606> writing this I realize that anyway the path to content would have to be set by instance admin
[21:44:15] <miro5001> Ojs is failing to upgrade because ynh_local_curl is failing to achieve the post install. It used to work but in the latest version, some js logic has been added to the install page breaking curl (which doesn't handle js). Install through yunohost doesn't fail but requires the user to proceed with the post install. But upgrade requires to have database that is only populated after the user run the post install, breaking the Ci tests.
I had to add a py script for the install.
But why javascript in an install page ???
[21:45:55] <miro5001> > <@m606:matrix.org> writing this I realize that anyway the path to content would have to be set by instance admin

I see. May be in the manifest, you choose the user and set the permission to that user
[21:49:44] <miro5001>
[install.init_main_permission]
type = "user"

[21:52:09] <miro5001> Then in the install script define the data as mentioned above or simply [resources.data_dir]
[22:13:31] <thomas> Hi all, I'm getting this message in the php-fpm logs for a Streams website installed on my YunoHost server:
[18-Mar-2025 23:00:36] WARNING: [pool streams] server reached max_children setting (32), consider raising it
Is there any way I could add something in the package so that it's possible to change the setting in the YunoHost admin interface (similar to what there was in packaging v1)
[22:21:58] <Aleks (he/him/il/lui)> sooo theoretically if you're using helpers 2.1, the `ynh_config_add_phpfpm` helper was totally reworked and it's now possible to define a `$php_max_children` setting, possibly from a config panel yes, just be aware that ynh_config_add_phpfpm needs to be re-called after changing the value to propagate to the actual conf
[22:22:11] <Aleks (he/him/il/lui)> cf https://doc.yunohost.org/packaging\_apps\_helpers\_v2.1#ynh-config-add-phpfpm
[22:22:56] <Aleks (he/him/il/lui)> >Additional "pm" and "php_admin_value" settings which are meant to be possibly configurable by admins from a future standard config panel at some point, related to performance and availability of the app, for which tweaking may be required if the app is used by "plenty" of users and other memory/CPU load considerations....
>
>If you have good reasons to be willing to use different defaults than the one set by this helper (while still allowing admin to override it) you should use `ynh_app_setting_set_default`
>
>[...]
>`$php_max_children`: by default, computed from "total RAM" divided by 40, cf `_default_php_max_children`
[22:23:37] <m606> > <@miro5001:matrix.org> Then in the install script define the data as mentioned above or simply [resources.data_dir]

thanks, I've been reading [the doc](https://doc.yunohost.org/en/packaging_apps_resources) to get your suggestion, but:
- permission: `type = "user"` can't find ref to it in the doc - did you mean "all_users" ? or $user (if that works) ?
- data_dir: i read that it defaults to `/home/yunohost.app/__APP__`. $user would be a subdir to be created from a script ?
But would that actually allow to create a kind of user-level config panel for the app (which is what I was investigating, to put it a bit differently)?
[22:25:55] <Aleks (he/him/il/lui)> (`type = 'user'` is the question type which is uuuuh documented somewhere ... probably 😬)
[22:30:56] <Aleks (he/him/il/lui)> ah it's here https://doc.yunohost.org/en/dev/forms ... meh, maybe not the most appropriate place
[22:35:44] <thomas> > sooo theoretically if you're using helpers 2.1, the `ynh_config_add_phpfpm` helper was totally reworked and it's now possible to define a `$php_max_children` setting, possibly from a config panel yes, just be aware that ynh_config_add_phpfpm needs to be re-called after changing the value to propagate to the actual conf
Woooookay... Not sure that I'll be able to master that kind of stuff. I'll probably give it a try, but I'm not very confident...
[22:52:06] <NemStudio18> Question peut être bête mais si mon app fait elle même ses mises a jours ça n'influence pas le système de yunohost ? Il détectera si le CMS utilise déjà la dernière version ?
[22:54:34] <Aleks (he/him/il/lui)> non il detectera pas, sélamerd 😬
[22:54:45] <miro5001> > <@m606:matrix.org> thanks, I've been reading [the doc](https://doc.yunohost.org/en/packaging_apps_resources) to get your suggestion, but:
> - permission: `type = "user"` can't find ref to it in the doc - did you mean "all_users" ? or $user (if that works) ?
> - data_dir: i read that it defaults to `/home/yunohost.app/__APP__`. $user would be a subdir to be created from a script ?
> But would that actually allow to create a kind of user-level config panel for the app (which is what I was investigating, to put it a bit differently)?

https://doc.yunohost.org/en/packaging_manifest#regarding-install-questio
[22:55:23] <miro5001> > The full list of question types is : string, text, select, tags, email, url, date, time, color, password, path, boolean, domain, user, group, number, range, alert, markdown, file, app.
[23:09:27] <miro5001> > <@m606:matrix.org> thanks, I've been reading [the doc](https://doc.yunohost.org/en/packaging_apps_resources) to get your suggestion, but:
> - permission: `type = "user"` can't find ref to it in the doc - did you mean "all_users" ? or $user (if that works) ?
> - data_dir: i read that it defaults to `/home/yunohost.app/__APP__`. $user would be a subdir to be created from a script ?
> But would that actually allow to create a kind of user-level config panel for the app (which is what I was investigating, to put it a bit differently)?

Since your app doesn't handle authentication, it would be better to have multiple instances of it and let yunohost handle the acl.
I wasn't clear. Make the install form to choose a user from the list of users to allow him access to the app, and no one else. This way, you will have to install it for every user.
For the data_dir, I don't know if the user needs to have access to that folder or not. For the first scenario, /home/$user/app would be better since every user has his own home and nextcloud have it configured. If the user doesn't have to deal with the data folder, set it in data_dir. Or if you think that allowing ssh access to the app folder for users is required, then the way my_webapp is structured is the way to go (/www inside the app sir, you can add /data outside /www).
[23:12:13] <miro5001> I am unable to edit files on github from android. On Firefox and Opera. Anyone else with the same issue?

[23:17:09] <Yunohost Git/Infra notifications> [penpot_ynh] y​unohost-bot opened [pull request #98](https://github.com/YunoHost-Apps/penpot_ynh/pull/98): Upgrade to v2.5.4
[23:17:49] <m606> > <@miro5001:matrix.org> Since your app doesn't handle authentication, it would be better to have multiple instances of it and let yunohost handle the acl.
> I wasn't clear. Make the install form to choose a user from the list of users to allow him access to the app, and no one else. This way, you will have to install it for every user.
> For the data_dir, I don't know if the user needs to have access to that folder or not. For the first scenario, /home/$user/app would be better since every user has his own home and nextcloud have it configured. If the user doesn't have to deal with the data folder, set it in data_dir. Or if you think that allowing ssh access to the app folder for users is required, then the way my_webapp is structured is the way to go (/www inside the app sir, you can add /data outside /www).

ok thanks for the clarification. I think I've got how to proceed!
[23:19:26] <m606> > <@m606:matrix.org> Hello, I have followed the steps in the doc to run autoupdater locally for test purpose: https://doc.yunohost.org/en/packaging_apps_resources#regarding-autoupdate and I get very little details and some errors:
> ```
> ./autoupdate_app_sources/autoupdate_app_sources.py '/path/to/jsoncrack_ynh'
> 0%| | 0/1 [00:00<?, ?it/s]WARNING:root:Could not get github: [Errno 2] No such file or directory: '/path/to/apps_tools/.github_login'
> 100%|#############################################| 1/1 [00:00<00:00, 2.39it/s]
> apps -> Autoupdater just ran, here are the results:
>
> WARNING:root:The logging sender tool /usr/bin/matrix-commander-rs does not exist.
> ```
> I don't remember encountering that in the past. Would have I had done something different back then ?

I had another question about app_tools' autoupdater script that ain't got answered yet if anyone has an idea (cf. linked message and the 2 following)
[23:22:38] <m606> > <@miro5001:matrix.org> I am unable to edit files on github from android. On Firefox and Opera. Anyone else with the same issue?
>

can't tell for Android, but I did edit files (resolving conflicts in a PR) via Github webUI earlier today from Firefox on Linux if that could help...