[00:07:26]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2774016178) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: Also having the current version of the package is important for packager. to be able to have it in the readme seems to m...
[00:07:29]
<m606> the goal is to pass the DB names to celery in the app's config template
```
[celery]
backend=redis://127.0.0.1/__REDIS_DB_BACKEND__
broker=redis://127.0.0.1/__REDIS_DB_BROKER__
```
[00:10:21]
<Yunohost Git/Infra notifications> [apps_tools] oleole39 [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2774019233) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: > Also having the current version of the package is important for packager. to be able to have it in the readme seems to...
[00:19:31]
<m606> well I though I may need it to pass $redis_db value to the other scripts:
- upgrade (or would it be ok if it assign a new redis_db, i.e. not the same than before upgrade? it is not clear for me how it works - are DB autodestroyed when not used in redis?)
- remove (`ynh_redis_remove_db $redis_db`).
[00:21:52]
<m606> well I though I may need it to pass $redis_db value to the other scripts:
- upgrade (or would it be ok if it assigns a new redis_db during upgrade script execution when re-hydrating the app's config template, i.e. potentially not the same redis_db number than before upgrade? it is not clear for me how redis works - are DB autodestroyed when not used so that we don't need to clear them?)
- remove (`ynh_redis_remove_db $redis_db`).
[00:22:26]
<m606> well I though I may need it to pass `$redis_db` value to the other scripts:
- upgrade (or would it be ok if it assigns a new `$redis_db` during upgrade script execution when re-hydrating the app's config template, i.e. potentially not the same `$redis_db` number than before upgrade? it is not clear for me how redis works - are DB autodestroyed when not used so that we don't need to clear them?)
- remove (`ynh_redis_remove_db $redis_db`).
[00:31:48]
<m606> and a separate topic, I see that for indico you have your own helper to install python (comparing to that one for instance - https://github.com/YunoHost-Apps/django_example_ynh/blob/9dab75c45f3a62b99d45e1100b5b4967ca95c8da/scripts/_common.sh#L50). Did you have a thought on that? Somehow I'd rather reuse yours as even if the other one is shorter, it calls a more complex third-party script.
[00:32:58]
<m606> and a separate topic, I see that for indico you have your own helper to install python (I mean compared to [that one from django_example app](https://github.com/YunoHost-Apps/django_example_ynh/blob/9dab75c45f3a62b99d45e1100b5b4967ca95c8da/scripts/_common.sh#L50) for instance). Did you have a thought on that? Somehow I'd rather reuse yours as even if the other one is shorter, it calls a more complex third-party script.
[00:38:10]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 [commented](https://github.com/YunoHost/apps_tools/pull/18#issuecomment-2774050370) on [issue #18](https://github.com/YunoHost/apps_tools/pull/18) Simpler READMEs: > > Also having the current version of the package is important for packager. to be able to have it in the readme seems ...
[00:47:59]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 opened [pull request #26](https://github.com/YunoHost/apps_tools/pull/26): Add link to the CI
[00:47:59]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 pushed 1 commit to add-ci-level: Update README.md.j2 ([6671d99b](https://github.com/YunoHost/apps_tools/commit/6671d99be7bba84539f48f9f2bce46db5dfc2550))
[00:47:59]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 created new branch add-ci-level
[00:51:15]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 [commented](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2025829303) on pull request #18 Simpler READMEs: Ive made a PR to have the link back to the CI: https://github.com/YunoHost/apps_tools/pull/26 The image of the version...
[00:58:13]
<Yunohost Git/Infra notifications> [apps_tools] OniriCorpe [commented](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2025833564) on pull request #18 Simpler READMEs: is this an easter egg? how the fuck am I supposed to guess that clicking on the version goes to the CI?
[08:27:59]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka opened [issue #233](https://github.com/YunoHost-Apps/roundcube_ynh/issues/233): Nextcloud cardav configuration not working
[09:15:43]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka opened [pull request #234](https://github.com/YunoHost-Apps/roundcube_ynh/pull/234): fix #233 nextcloud carddav default configuration
[09:23:25]
<miro5001> > <@m606:matrix.org> and a separate topic, I see that for indico you have your own helper to install python (comparing to that one for instance - https://github.com/YunoHost-Apps/django_example_ynh/blob/9dab75c45f3a62b99d45e1100b5b4967ca95c8da/scripts/_common.sh#L50). Have you had a special thinking about that ? Somehow I'd rather reuse yours as the other one calls a more complex third-party script.
Indico required a higher python version. I didn't realise there was an automated way to manage multiple python versions without breaking the one on yunohost
[09:24:49]
<miro5001> > <@m606:matrix.org> well I though I may need it to pass the db_name to the upgrade or remove script (`ynh_redis_remove_db $redis_db`).
> But I've never used redis before, and don't exactly understand why/how it works
Yes, from what I have read, the two redis db's need to be different to avoid conflicts. It doesn't matter what db number. Every worker needs its own db.
[09:27:32]
<miro5001> > <@Alekswag:matrix.org> i don't get why they would use a simple int indice as db name x_x
I just followed the official instructions
[09:38:09]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka opened [issue #235](https://github.com/YunoHost-Apps/roundcube_ynh/issues/235): Nextcloud file attachments
[11:07:09]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka opened [issue #236](https://github.com/YunoHost-Apps/roundcube_ynh/issues/236): Separate CardDAV plugin integration and Nextcloud default addressbok configuration
[11:09:52]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka edited [issue #235](https://github.com/YunoHost-Apps/roundcube_ynh/issues/235): Nextcloud file attachments
[11:10:58]
<Yunohost Git/Infra notifications> [roundcube_ynh] grubshka edited [issue #235](https://github.com/YunoHost-Apps/roundcube_ynh/issues/235): WebDAV integration and Nextcloud file attachments
[13:25:43]
<m606> > <@miro5001:matrix.org> Yes, from what I have read, the two redis db's need to be different to avoid conflicts. It doesn't matter what db number. Every worker needs its own db.
hmm like it doesn't matter what was on the DB before then ? it would be more like a "channel" than a historical set of data ? but if so, I wonder why YNH provides us with a helper to remove the `$redis_db`. Probably I'm still missing something
[13:29:22]
<m606> > <@miro5001:matrix.org> I just followed the official instructions
I understand his remark as a diatribe against Redis like "why Redis doesn't give a more complex unique ID - like a string maybe - to its databases name, rather than a mere figure" )
[14:21:05]
<Aleks (he/him/il/lui)> >I wonder why YNH provides us with a helper
don't overestimate what Yunohost provides, there's no guarantee that it's some universal truth or "Right way to do™" ;P
[14:49:18]
<miro5001> > <@m606:matrix.org> hmm like it doesn't matter what was on the DB before then ? it would be more like a "channel" than a historical set of data ? but if so, I wonder why YNH provides us with a helper to remove the `$redis_db`. Probably I'm still missing something
Yunohost provides an available redis db. In the remove script you should delete that so only used ones are registered in the settings. That's very convinient in case a user installs and removes multiple apps using redis so you won't have multiple unused redis db registered.
So if you install an app using 2 db's, install another one, remove the first, etc... You will have yunohost look for an available one for your next app to install.
About complex db ids, I don't see the point. Yunohost takes care of assigning db ids and the packager (and user) shouldn't care about finding an empty db Id.
Redis db is essentially for caching a service. It gets emptied when you restart the service
[15:09:30]
<m606> > <@miro5001:matrix.org> Yunohost provides an available redis db. In the remove script you should delete that so only used ones are registered in the settings. That's very convinient in case a user installs and removes multiple apps using redis so you won't have multiple unused redis db registered.
> So if you install an app using 2 db's, install another one, remove the first, etc... You will have yunohost look for an available one for your next app to install.
> About complex db ids, I don't see the point. Yunohost takes care of assigning db ids and the packager (and user) shouldn't care about finding an empty db Id.
> Redis db is essentially for caching a service. It gets emptied when you restart the service
Thanks for explaining. But now I don't get what you said earlier that you would rather consider avoiding `ynh_app_setting_set` for redis databases
[15:11:42]
<m606> like if it makes sense to remove one DB, you need to be able to track that DB ID, no ?
[16:25:22]
<Yunohost Git/Infra notifications> [borg_ynh] yalh76 merged [pull request #199](https://github.com/YunoHost-Apps/borg_ynh/pull/199): Improve
[16:31:10]
<Yunohost Git/Infra notifications> [apps_tools] yalh76 [commented](https://github.com/YunoHost/apps_tools/pull/18#discussion_r2027378511) on pull request #18 Simpler READMEs: > is this an easter egg? how the fuck am I supposed to guess that clicking on the version goes to the CI? nope. not an ...
[16:37:46]
<yalh76> There is a package_linter warning on all packages since the new readme...
``
! It looks like the README was not generated automatically by https://github.com/YunoHost/apps/tree/master/tools/README-generator. Note that nowadays you are not suppose to edit README.md, the yunohost bot will usually automatically update it if your app is hosted in the YunoHost-Apps org ... or you can also generate it by running the README-generator yourself.
``
[16:38:00]
<yalh76> Can be seen at https://ci-apps.yunohost.org/ci/
[16:40:03]
<Aleks (he/him/il/lui)> eurhg
[16:51:36]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar closed [pull request #25](https://github.com/YunoHost/apps_tools/pull/25): Translations update from Weblate
[16:53:12]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar [commented](https://github.com/YunoHost/apps_tools/pull/10#issuecomment-2776406700) on [issue #10](https://github.com/YunoHost/apps_tools/pull/10) Support latest commit on branch: Why didnt we merge this already ?
[16:53:20]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar approved [pull request #10](https://github.com/YunoHost/apps_tools/pull/10#pullrequestreview-2740579237) Support latest commit on branch
[16:53:55]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar merged [pull request #10](https://github.com/YunoHost/apps_tools/pull/10): Support latest commit on branch
[16:53:55]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar pushed 2 commits to main ([f41446431999...095a49406fcc](https://github.com/YunoHost/apps_tools/compare/f41446431999...095a49406fcc))
[16:53:56]
<Yunohost Git/Infra notifications> [apps_tools/main] Support latest commit on branch - orhtej2
[16:53:58]
<Yunohost Git/Infra notifications> [apps_tools/main] GL and Gitea - orhtej2
[16:56:11]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar [commented](https://github.com/YunoHost/apps_tools/pull/20#issuecomment-2776412983) on [issue #20](https://github.com/YunoHost/apps_tools/pull/20) Add specific upgrade instructions (if any) to PR body: yesyesyesyes Let me just create a documentation PR for this before merging. We dont want this feature to be lost in co...
[16:56:23]
<Yunohost Git/Infra notifications> [apps_tools] Salamandar approved [pull request #20](https://github.com/YunoHost/apps_tools/pull/20#pullrequestreview-2740588089) Add specific upgrade instructions (if any) to PR body
[19:02:25]
<Yunohost Git/Infra notifications> yalh76 deleted repository pinepods_ynh https://github.com/YunoHost-Apps/pinepods_ynh
[20:51:30]
<yalh76> In addition, in my opinion, the new readme miss a link to the CI: `https://ci-apps.yunohost.org/ci/apps/$app/` that would be very helpful to packagers ^^
https://github.com/YunoHost/apps_tools/pull/18
[20:54:08]
<Yunohost Git/Infra notifications> [mastodon_ynh] yalh76 merged [pull request #495](https://github.com/YunoHost-Apps/mastodon_ynh/pull/495): Upgrade to v4.3.7
[20:54:09]
<Aleks (he/him/il/lui)> yeah we should definitely re-add a badge with the level that link to ci, dunno why it got removed at some point ...
[20:54:14]
<Yunohost Git/Infra notifications> [mastodon_ynh] yalh76 deleted branch ci-auto-update-4.3.7
[20:54:38]
<Yunohost Git/Infra notifications> [mastodon_ynh] yalh76 opened [pull request #496](https://github.com/YunoHost-Apps/mastodon_ynh/pull/496): Upgrade to v4.3.7
[21:16:26]
<Yunohost Git/Infra notifications> [jellyfin_ynh] yalh76 pushed 1 commit to improve: Update manifest.toml ([130a5706](https://github.com/YunoHost-Apps/jellyfin_ynh/commit/130a570691621999162173808b66295dfa6a8e02))
[22:24:21]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 9 pending update PRs
- 9 new apps PRs
- 14 failed apps updates: appflowy, khatru-pyramid, kiwix, languagetool, lemmy, localai, misskey, ofbiz, opencloud, phpldapadmin, phpmyadmin, pixelfedglitch, snweb, stremio
See the full log here: https://paste.yunohost.org/raw/raqinugawo