[05:07:52]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly merged [pull request #543](https://github.com/YunoHost-Apps/searxng_ynh/pull/543) : Upgrade to v2026.10.04
[05:08:01]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly deleted branch ci-auto-update-2026.10.04
[05:08:07]
<Yunohost Git/Infra notifications> [searxng_ynh] github-actions[bot] opened [pull request #544](https://github.com/YunoHost-Apps/searxng_ynh/pull/544) : Upgrade master from testing
[05:08:26]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly merged [pull request #544](https://github.com/YunoHost-Apps/searxng_ynh/pull/544) : Upgrade master from testing
[05:08:35]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly deleted branch master-promotion
[07:08:22]
<Yunohost Git/Infra notifications> [piped_ynh] orhtej2 merged [pull request #317](https://github.com/YunoHost-Apps/piped_ynh/pull/317) : Upgrade sources
[07:08:26]
<Yunohost Git/Infra notifications> [piped_ynh] orhtej2 deleted branch ci-auto-update-sources-c5408e3a
[07:08:49]
<Yunohost Git/Infra notifications> [piped_ynh] orhtej2 opened [pull request #318](https://github.com/YunoHost-Apps/piped_ynh/pull/318) : Testing
[07:09:01]
<Yunohost Git/Infra notifications> [piped_ynh] orhtej2 merged [pull request #318](https://github.com/YunoHost-Apps/piped_ynh/pull/318) : Testing
[09:51:10]
<Yunohost Git/Infra notifications> Job [#40003](https://ci-apps.yunohost.org/ci/job/40003) for qr failed miserably :(
[10:53:09]
<m606> i don't have the editing rights to fix it but there is a typo in the Github repo "About" field on the right there : https://github.com/YunoHost-Apps/wiki-go_ynh: "packafe" --> "package"
[11:21:09]
<Yunohost Git/Infra notifications> orhtej2 edited repository wiki-go_ynh: Wiki-go package for YunoHost https://github.com/YunoHost-Apps/wiki-go_ynh
[12:45:12]
<Yunohost Git/Infra notifications> App journiv failed all tests in job [#40010](https://ci-apps.yunohost.org/ci/job/40010) !
[14:45:16]
<Yunohost Git/Infra notifications> Job [#40012](https://ci-apps.yunohost.org/ci/job/40012) for qr failed miserably :(
[16:01:29]
<Yunohost Git/Infra notifications> oleole39 transferred repository feedme_ynh: feedme package for YunoHost. Turn any web page into a RSS feed. https://github.com/YunoHost-Apps/feedme_ynh
[16:11:06]
<Yunohost Git/Infra notifications> [apps] orhtej2 [commented](https://github.com/YunoHost/apps/pull/3640#issuecomment-5998348242) on [issue #3640](https://github.com/YunoHost/apps/pull/3640) Add starling to wishlist: Seems to be bound to Cloudflare APIs, namely D1 DB. While SQLite shim is provided - is it production grade?
[17:07:39]
<Yunohost Git/Infra notifications> App wekan goes down from level 8 to 2 in job [#40014](https://ci-apps.yunohost.org/ci/job/40014)
[17:38:59]
<m606> I tested successfully this upgrade containing security fixes but can't merge it to `master` due to "protected branch" status. Can someone merge it? https://github.com/YunoHost-Apps/shaarli_ynh/pull/119
Also, would you know the reasoning for protecting some branches and not others?
[17:46:33]
<Thomas> Mmh my approval is not enough, I don't have the rights either
[17:55:11]
<m606> that's strange as you are the last one who merged a PR on this repo. I'm not too familiar with Github's branch protection feature 😖
[17:56:26]
<Thomas> Me neither, and it's quite strange indeed!
[17:57:24]
<otm33> m606: maybe asking for a 2nd review.
[17:57:52]
<m606> to anyone?
[17:57:54]
<otm33> Maybe the rulesets require 2, 3, 4, 10… reviews.
[17:58:47]
<m606> you won a free review 😁
[17:59:59]
<otm33> I completely trust you!
[18:00:38]
<otm33> Seems that eric_G review is required, then...
[18:01:46]
<Thomas> Or we have to raise m606 as admin 🎖️
[18:03:14]
<m606> an admin able to access repo setting can probably unprotect the branch if it has no specific reason to be so (which is kind of strange as it is only one among many)
[18:08:07]
<otm33> m606: Can you merge this [PR](https://github.com/YunoHost-Apps/gonic_ynh/pull/7) ?
[18:13:49]
<otm33> Actually, this repo's main branch is protected, but its rulesets don’t prevent others from merging a PR. So shaarli's rulesets may be more strict.
[18:51:21]
<m606> in upgrade script, values from config panel are not automatically loaded as bash variables? This get me confused: https://github.com/YunoHost/example_ynh/blob/7befdcd48318e3f9042a29293cc3a29142500464/scripts/upgrade#L10
[19:17:51]
<Thomas> Indeed, to my knowledge you have to save the setting from config_panel
[20:07:22]
<m606> like this in the upgrade script you mean I guess? `admin_token="$(ynh_app_setting_get --key=admin_token)"`
[20:14:03]
<Thomas> For my use case I added it in the config script, like this https://github.com/YunoHost-Apps/calibreweb-nextgen_ynh/blob/40aec44aebab79bce31a463482c7caf632091b57/scripts/config#L17
[20:42:48]
<m606> oh not sure whether we talk of the same thing or... would you mean that only setting saved in config panel are then autoloaded at the beginning of the upgrade script (does not seem to match the result of my experiment)?
I initiated values in install script (or say they were set via install questions in manifest). Those can be edited in config panel (without config script, just default helpers triggered via the `bind` property). Now I need these values loaded at the beginning of upgrade script.
It happens that adding `admin_token="$(ynh_app_setting_get --key=admin_token)"` at the beginning of the upgrade script works fine. Just thought that the setting could be automatically loaded.
[20:54:17]
<ewilly> I always use ynh_app_seting_get too, I never saw that comment in the example_ynh... Totally new for me too and never tested on my side
[21:07:02]
<m606> unless @thovi98:matrix.org has a different take on this, I think it's just the comment in the example_ynh that could be a bit more precise. I now assume this line actually refers exclusively to core variables (`$domain`, `$path`, etc.).
[21:16:20]
<m606> cf. https://ci-apps-dev.yunohost.org/ci/job/25376
> WARNING - Variable $admin_token wasn't initialized when trying to replace __ADMIN_TOKEN__ in /etc/systemd/system/feedme.service`
Where `$admin_token` is initially set via an install question, but for which I had not yet added `admin_token="$(ynh_app_setting_get --key=admin_token)"` to the upgrade script .
[21:16:25]
<m606> cf. https://ci-apps-dev.yunohost.org/ci/job/25376
> WARNING - Variable $admin_token wasn't initialized when trying to replace __ADMIN_TOKEN__ in /etc/systemd/system/feedme.service`
Where `$admin_token` is initially set via an install question, but for which I had not yet added `admin_token="$(ynh_app_setting_get --key=admin_token)"` to the upgrade script .
[21:16:41]
<m606> cf. https://ci-apps-dev.yunohost.org/ci/job/25376
> WARNING - Variable $admin_token wasn't initialized when trying to replace __ADMIN_TOKEN__ in /etc/systemd/system/feedme.service
Where `$admin_token` is initially set via an install question, but for which I had not yet added `admin_token="$(ynh_app_setting_get --key=admin_token)"` to the upgrade script .
[22:22:42]
<otm33> m606: string or password type ?
[22:24:18]
<otm33> 'password' type are not stored as setting
[22:34:06]
<m606> Hmm yes password type. However I had the same issue with `boolean` in https://ci-apps-dev.yunohost.org/ci/job/25370 so I don't think it changes my point?
> 15281 ERROR Failed to upgrade feedme: An error occurred inside the app upgrade script : Variable $allow_private wasn't initialized when trying to replace __ALLOW_PRIVATE__ in /home/yunohost.app/feedme/config.yaml
[22:40:55]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 52 pending update PRs
- 16 new apps PRs: dokos, fider, freshrss, homarr, jackett, kimai2, leantime, libredb_studio, n8n, nodebb, penpot, photoview, rutorrent, tooljet, wekan, wetty
- 10 failed apps updates: automad, benevalibre, castopod, domoticz, gamja, gitea, leafwiki, loki, projectsend, stirling-pdf
See the full log here: https://paste.yunohost.org/raw/uqunatucov
Autoupdate dashboard: https://apps.yunohost.org/dash?filter=autoupdate
[22:45:44]
<m606> @otm33:matrix.org where are password stored?!
so to reuse this admin token in upgrade script I'd rather type it as string with `redacted = true` I guess
[22:48:48]
<otm33> My understanding is that upgrade script reads the settings to fill placeholders. If allow\_private or admin\_token is/are not present in settings, the upgrade will fail. That's why you need to initialize them in the upgrade script.
[22:51:37]
<otm33> My understanding is that upgrade script reads the settings to fill placeholders. If allow\_private or admin\_token is/are not present in settings, the upgrade will fail. That's why you need to initialize them in the upgrade script (with empty values I guess ynh_app_setting_get will return nothing?)
[22:56:12]
<otm33> I can only see this property for password
[23:06:49]
<otm33> m606: And you know what's funny ? You cannot store in settings a password "from" manifest but you can from config_panel.
[23:07:24]
<m606> https://doc.yunohost.org/en/dev/core/forms#properties-4
[23:09:56]
<otm33> my apologies;)
[23:11:36]
<m606> @otm33:matrix.org do you know whether it is documented that password are not stored in settings.yml? you are right, but I can't find track of it
[23:13:18]
<otm33> found it : https://doc.yunohost.org/fr/dev/packaging/manifest#regarding-install-question-types
[23:24:02]
<otm33> m606: And what about `ynh_app_setting_set --key=admin_token --value=$admin_token` in install script ? Seems dummy but it will do the trick...
Unless you don't want to store any password in settings.yml of course.
[23:25:02]
<otm33> and keeping password as type in manifest.
[23:35:54]
<otm33> Anyway any admin_token change via the config panel will store it in settings, so...
[23:36:25]
<m606> I was considering the advice on the link you pasted, i.e. avoid storing a user-chosen password if not as a hash. However I only need that token to populate a template tag in systemd service (in various scripts) so it will be stored somewhere anyway (it is upstream that should support comparing user entry to hashes I guess).
So I guess it won't hurt too much to store it in settings as well.
[23:37:27]
<m606> Ah yes?! so something defined as password type in config panel is saved in settings?
[23:38:12]
<otm33>
> m606: And you know what's funny ? You cannot store in settings a password "from" manifest but you can from config_panel.
[23:39:40]
<m606> so yes I'll do as you say, thanks!
[23:43:26]
<otm33> have a good night (or day)!
[23:44:42]
<otm33> My understanding is that upgrade script reads the settings to fill placeholders. If allow\_private or admin\_token is/are not present in settings, the upgrade will fail. That's why you need to initialize them in the upgrade script (with empty values I guess ynh\_app\_setting\_get will return nothing)
[23:54:17]
<otm33> > However I only need that token to populate a template tag in systemd service
I couldn't sleep with that in mind ;)
> Ahem, and if token contains double quotes ?
[23:54:31]
<otm33> > However I only need that token to populate a template tag in systemd service
I couldn't sleep with that in mind ;)
Ahem, and if token contains double quotes ?
[23:55:02]
<m606> errr
[23:55:13]
<m606> right, i need validation
[23:55:39]
<otm33> is generating an random string in install script an option?
[23:56:35]
<m606> it is but the user has to know it, because the token serves to enter an admin area in the app
[23:56:57]
<m606> and user must be able to change it as well
[23:56:58]
<m606> (in config panel)
[23:58:25]
<m606> `pattern.regexp = '^["].*$'`
[23:58:39]
<m606> will test this )