[13:38:05]
<Yunohost Git/Infra notifications> [example_ynh] @zamentur [commented](https://github.com/YunoHost/example_ynh/pull/201#discussion_r1118087631) on pull request #201 Simplify change_url syntax: "Is this really a thing ........" on my side, i have seen several webapp where its important to do it... I dont know e...
[13:38:13]
<Yunohost Git/Infra notifications> [example_ynh] @zamentur edited a [comment](https://github.com/YunoHost/example_ynh/pull/201#discussion_r1118087631) on pull request #201 Simplify change_url syntax: "Is this really a thing ........" on my side, i have seen several webapp where its important to do it... I dont know e...
[13:40:24]
<Yunohost Git/Infra notifications> [example_ynh] @alexAubin [commented](https://github.com/YunoHost/example_ynh/pull/201#discussion_r1118088097) on pull request #201 Simplify change_url syntax: It would still be quite interesting to have a way to reproduce the issue you are mentioning to know once and for all wet...
[13:44:24]
<Aleks (he/him/il/lui)> > <@ericg:matrix.org> can I, with config_panel set a new data\_dir directory and apply rights to it? cf this case: https://forum.yunohost.org/t/filebrowser-et-les-autres-dossier/23833
sooooo https://github.com/YunoHost/yunohost/blob/dev/src/utils/resources.py#L722-L728
[13:44:29]
<Aleks (he/him/il/lui)> so nope
[13:45:08]
<Aleks (he/him/il/lui)> but one way to effectively change the data location without changing the data_dir setting would be a symlink
[13:45:09]
<Aleks (he/him/il/lui)> (or mount bind)
[14:04:32]
<Aleks (he/him/il/lui)> hmmm i dunno if that fits the usecase for filebrowse though 😬
[15:06:25]
<tituspijean> I'm currently looking at updating `updater.sh` to handle `manifest.toml`. The only implementation of `yq` that supports TOML seems to be https://kislyuk.github.io/yq/#toml-support with this TOML lib: https://github.com/uiri/toml
This one rightfully ignores indentation but does not offer to add it back... are we OK with that?
[15:08:09]
<Aleks (he/him/il/lui)> ah yes i see
[15:08:10]
<Aleks (he/him/il/lui)> hmpf
[15:08:37]
<Aleks (he/him/il/lui)> imho keeping indentation is important ...
[15:08:54]
<Aleks (he/him/il/lui)> if this is just about updating the version, can't we just use `sed` ? :|
[15:09:30]
<tituspijean> we need to parse `version` and `upstream.code`
[15:10:09]
<tituspijean> but yeah indeed, we can do it with grep and replace with sed
[15:13:31]
<Aleks (he/him/il/lui)> parsing is easy, the hard part is editing the file while keeping comment + indent ;P
[15:14:48]
<tituspijean> oooor we leave like broken like that for the time being, and I focus on building the auto-updater core in python (but that won't solve my indentation issue if I want to use a proper lib)
[15:15:39]
<Aleks (he/him/il/lui)> +1 for having a common mechanism for all apps, and the thing about updating the version can be dealt with sed in that common mechanism too
[15:15:58]
<tituspijean> btw have you had the chance to read https://github.com/YunoHost/issues/discussions/2164 ?
[15:16:12]
<Aleks (he/him/il/lui)> ooooh, *discussions*
[15:16:39]
<Aleks (he/him/il/lui)> ugh, carabelloy posted an issue in there T_T
[15:16:52]
<tituspijean> I started a Matrix thread here but Salamanda r preferred a proper Discussion 😛
[15:17:16]
<tituspijean> > <@Alekswag:matrix.org> ugh, carabelloy posted an issue in there T_T
uh, I'll delete that.
[15:23:07]
<Aleks (he/him/il/lui)> > <@titus:pijean.ovh> btw have you had the chance to read https://github.com/YunoHost/issues/discussions/2164 ?
so yes +1, except that I don't know if we really do need a toml ... Like do we really need 'iii. How often should the auto-updater run' ? Otherwise I would naively just suggest defining some sort of `latest-releast-check.sh` or whatever as a "simple" bash script whose jobs is only to echo something like
```
LATEST_UPSTREAM_VERSION="1.2.3.4"
LATEST_UPSTREAM_VERSION_URL="https://foo.tld/bar/archive.tar.gz"
```
and then the python/whtaver "common" logic just use those info to update the manifest.toml/json + app.src
[15:23:24]
<Aleks (he/him/il/lui)> though of course things get more complexed for several-app.src apps
[15:24:44]
<Aleks (he/him/il/lui)> (Debian has some pretty minimalistic mechanism about this, in fact too minimalist imho : https://salsa.debian.org/python-team/packages/python-lexicon/-/blob/master/debian/watch )
[15:25:53]
<Aleks (he/him/il/lui)> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#watch
[15:26:42]
<Aleks (he/him/il/lui)> reading about the `uscan` command o.O
[15:29:22]
<Aleks (he/him/il/lui)> a toml file could allow to define one bash snippet per app.src tho
[15:31:26]
<Aleks (he/him/il/lui)> >defining some sort of latest-releast-check.sh or whatever as a "simple" bash script whose jobs is only to echo something
or maybe using a bash script snippet could be meant only for the too-complex use cases, and in the majority of cases, we'd only need the app's upstream git repo and check what's the latest non-rc tag ?
[15:31:49]
<Aleks (he/him/il/lui)> (and have some ad-hoc logic for gitlab/github/other forges to derive the corresponding archive url)
[15:39:17]
<Aleks (he/him/il/lui)> (this is effectively designing sort of a continous delivery workflow for upstream which we don't have any control over haha)
[15:39:28]
<tituspijean> > Like do we really need 'iii. How often should the auto-updater run' ?
Yeah, some upstream apps can create several new versions per day/week, that's a hassle
[15:39:38]
<Aleks (he/him/il/lui)> ugh
[15:42:43]
<Aleks (he/him/il/lui)> do we really want to check for new version more than e.g. once or twice a week though ?
[15:42:58]
<tituspijean> we could opt for once a week yeah
[15:43:56]
<Aleks (he/him/il/lui)> anyway we could also have a standard bash comment to store this metadata at the top like `# frequency: 1day` or idk
[15:46:37]
<Aleks (he/him/il/lui)> it really depends wether we go for a declarative-first approach (eg the package essentially provides a URL + regex or whatever and then the common logic handles the whole thing about checking what's the latest tag etc) (and for the complex cases we have something like inline-bash inside some .toml) OR there's too many specific case which we can't really factorize easily and then we go for a script which `echo`'s some info
[15:50:56]
<tituspijean> I'm a bit afraid we won't be able to factorize actually 😕 The standard case seem to be "monitor Github releases and update checksums and so in app.src", though how could we handle different architectures (naming nightmare between x64, x86\_64 and amd64...))
[15:51:28]
<tituspijean> diverging from a standard seems pretty easy
[15:52:47]
<tituspijean> then step 0 could be "let's leave the sh and py script as they are, and we browse the repositories to run them by ourselves" (with appropriate env variables)
[15:53:27]
<Aleks (he/him/il/lui)> hmmmmyeah but that doesn't quite solve all the maintenance issue of "switching to v2" and other similar issues we could have in the future
[15:54:06]
<Aleks (he/him/il/lui)> and we gotta be careful because there could be some malicious logic in these script, you don't want to yolo run them as root on our infra (or even as non-root, you'd want to at least chroot them somehow)
[15:54:21]
<tituspijean> For the "switching to v2", I can run my PyGithub scripts on all repositories that don't implement them yet, and create a new branch and PR
[15:54:48]
<tituspijean> that might incite maintainers to complete what your migration script started
[15:55:04]
<tituspijean> > <@Alekswag:matrix.org> and we gotta be careful because there could be some malicious logic in these script, you don't want to yolo run them as root on our infra (or even as non-root, you'd want to at least chroot them somehow)
erf yeah...
[15:58:58]
<Aleks (he/him/il/lui)> wokay i'm doing a small grep study in the app cache to try to have a more quantitative understanding of the use cases
[16:03:06]
<Aleks (he/him/il/lui)> a shitload of apps are using something that looks like the default update.sh
[16:03:08]
<Aleks (he/him/il/lui)> do they all work tho o.O
[16:03:48]
<tituspijean> you need to check they have a corresponding .yml
[16:04:30]
<tituspijean> 'coz now example_ynh includes the .sh but the Action is actually run if there is a .yml
[16:04:51]
<Aleks (he/him/il/lui)> yeah even with a .yml
[16:04:59]
<Aleks (he/him/il/lui)> 145 ô.o
[16:05:17]
<tituspijean> niiiice
[16:05:18]
<Aleks (he/him/il/lui)> (among 210 apps with an updater.sh)
[16:06:27]
<Aleks (he/him/il/lui)> hmmm
[16:06:43]
<Aleks (he/him/il/lui)> ah wait
[16:07:04]
<Aleks (he/him/il/lui)> that's 145 apps with an updater.yml i think
[16:09:03]
<tituspijean> https://aria.im/_matrix/media/v1/download/pijean.ovh/adeb1e34439c98b1a600ed27ee1d8658527babba8d3667b9a216eb56fed13963
[16:09:17]
<Aleks (he/him/il/lui)> xD
[16:10:12]
<Aleks (he/him/il/lui)> hmmm still 140 o.O
[16:10:48]
<Aleks (he/him/il/lui)> 140 apps among the 145 apps which do have an updater.yml do rely on simple github api o.O ?
[16:10:49]
<tituspijean> and among these,most use the standard .sh?
[16:10:55]
<Aleks (he/him/il/lui)> cant be right
[16:11:15]
<tituspijean> what's your grep command?
[16:13:01]
<Aleks (he/him/il/lui)> `cd /var/www/app_yunohost/apps/.apps_cache` (on saperlipopette)
```bash
for APP in $(ls); do
if test -e $APP/.github/workflows/updater.yml && grep 'version=' $APP/.github/workflows/updater.sh | grep -q 'api.github.com';
then
echo -n "$APP "; grep 'version=' $APP/.github/workflows/updater.sh | grep 'api.github';
fi;
done
```
[16:14:18]
<tituspijean> grep'ing the version from the API seems OK and standard (either with releases or tags), what might differ is the handling in the second part of the script
[16:15:07]
<Aleks (he/him/il/lui)> okay
[16:17:47]
<Aleks (he/him/il/lui)> missa furiously wants to refactor the whole ynh\_setup\_source's .src format mess and have a sources.toml instead ...
[16:19:41]
<yunohelper> Refactor? Have you said ***refactor***?!
[16:22:53]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon approved [pull request #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#pullrequestreview-1314696013) Apply example_ynh: ok
[16:24:50]
<Aleks (he/him/il/lui)> i see 118 apps (amound the 140ish?) that seem to obtain the asset url from github
[16:25:49]
<Aleks (he/him/il/lui)> some do have like `assets="https://github.com/Requarks/wiki/releases/download/$version/wiki-js.tar.gz"` but we could have some declarative stuff for this too idk
[16:26:09]
<Aleks (he/him/il/lui)> most of the time it's just getting the .tar.gz for the corresponding tag, standard git/github stuff
[16:37:58]
<Aleks (he/him/il/lui)> bon typiquement un cas relou c'est jitsi
[16:38:20]
<Aleks (he/him/il/lui)> mais pour le reste je vois pleins de truc factorisable
[16:38:56]
<Aleks (he/him/il/lui)> à mon avis on pourrait dire "pour les cas nominaux / classiques, on prévoit un truc déclaratif ultra simple, et pour les autres, pour le moment vous restez en updater.yml + updater.sh et voila"
[16:56:06]
<tituspijean> Does packaging v2 also loads settings for the config panel?
[16:58:40]
<Aleks (he/him/il/lui)> nope
[16:59:35]
<Aleks (he/him/il/lui)> sticto sensu stuff in config panel are not settings, they are just "options that live in the app conf files and are exposed in read/write via the config panel interface"
[17:00:14]
<Aleks (he/him/il/lui)> and because of some technical reason with the whole upgrade flow, ynh_add_config etc, you end up having to define them as setting too ...
[17:00:15]
<Aleks (he/him/il/lui)> but it's more a bug rather than a feature
[17:00:22]
<tituspijean> Yeah I agree ; I was merely hoping for `install_dir` to be automagically available 😛
[17:00:33]
<Aleks (he/him/il/lui)> (cf the mess with the mautrix bridges epic config panels)
[17:00:34]
<Aleks (he/him/il/lui)> ah
[17:00:38]
<Aleks (he/him/il/lui)> but install_dir is a standard setting
[17:00:49]
<Aleks (he/him/il/lui)> i mean any setting that exists is loaded
[17:00:57]
<Aleks (he/him/il/lui)> ah you mean *in the context of config panel*
[17:01:05]
<Aleks (he/him/il/lui)> ugh i understood the question the other way around
[17:01:11]
<tituspijean> Ah OK nice 🙂 I should have been clearer 🙂
[17:01:47]
<Aleks (he/him/il/lui)> sooooo reading the code
[17:02:10]
<Aleks (he/him/il/lui)> annnnnnd it's a mess
[17:02:25]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/src/app.py#L1874
[17:02:33]
<tituspijean> (I was *trying* to find the relevant part of the code 😛 those 3150 lines are hard to decipher :p)
[17:02:53]
<tituspijean> great thanks
[17:03:35]
<Aleks (he/him/il/lui)> to be consistent it should be calling `_make_environment_for_app_script` which adds a whole bunch of stuff ...
[17:09:40]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @lapineige [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/384#issuecomment-1445411435) on [issue #384](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/384) Migrate mysql db to utf8: Just to make sure, this will be updated automatically, nothing to do on our side ?
[17:23:14]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon pushed 3 commits to upgrade ([7c2d6a938a13...71a84a4cedaf](https://github.com/YunoHost-Apps/dokuwiki_ynh/compare/7c2d6a938a13...71a84a4cedaf))
[17:23:15]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon dismissed review [pull request #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#pullrequestreview-1314696013): Apply example_ynh
[17:23:22]
<Yunohost Git/Infra notifications> [dokuwiki_ynh/upgrade] Fix "php conf location" breaking backup script See https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/96 the bug: >... - Gofannon
[17:23:23]
<Yunohost Git/Infra notifications> [dokuwiki_ynh/upgrade] enh use helper "ynh_add_config" to manage file - Gofannon
[17:23:23]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @yunohost-bot pushed 1 commit to upgrade: Auto-update README ([3724fcd4](https://github.com/YunoHost-Apps/dokuwiki_ynh/commit/3724fcd4bf85248d4926eb785a90d960d34d9304))
[17:23:29]
<Yunohost Git/Infra notifications> [dokuwiki_ynh/upgrade] bump package version and changelog - Gofannon
[17:41:41]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon commented [pull request #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#pullrequestreview-1314705470) Apply example_ynh: Fix tested successfully on my side for https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/96 tests done: 1. new ...
[17:43:07]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/96#issuecomment-1445417821) on [issue #96](https://github.com/YunoHost-Apps/dokuwiki_ynh/issues/96) Cannot make a backup: Thanks for the bug report. Should be fixed with a new version See https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95...
[17:44:57]
<Aleks (he/him/il/lui)> tituspijean: so i'm on my way to adding support for a `sources.toml` to replace the boring `app.src` and I think we could add a new key in those, like for each source, have a `watch_for_new_releases` or whatever, and then we could build the updater logic for just that
[17:45:28]
<Aleks (he/him/il/lui)> (again in the nominal case where such release can be obtained from just checking the git tag or github releases)
[18:03:49]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @yunohost-bot [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#issuecomment-1445421874) on [issue #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95) Apply example_ynh: :carousel_horse:
[[Test Badge](https://img.shields.io/endpoint?url=https://ci-apps-dev.yunohost.org/ci/api/job/5872/bad...
[18:03:49]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @Gofannon [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#issuecomment-1445421866) on [issue #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95) Apply example_ynh: testme
[18:13:48]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @alexAubin edited review [pull request #95](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#pullrequestreview-1314708756): Apply example_ynh
[18:13:48]
<Yunohost Git/Infra notifications> [dokuwiki_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/dokuwiki_ynh/pull/95#discussion_r1118128717) on pull request #95 Apply example_ynh: (I would entirely remove that file ... maintaining CHANGELOG.md for every app is not a thing, and it contains only stuff...
[21:49:11]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label enhancement
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label invalid
[21:49:12]
<Yunohost Git/Infra notifications> @kay0u created repository qBittorrent_ynh https://github.com/YunoHost/qBittorrent_ynh
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label duplicate
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label documentation
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label good first issue
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label bug
[21:49:12]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label question
[21:49:13]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u pushed 1 commit to master: Initial commit ([c595f8ce](https://github.com/YunoHost/qBittorrent_ynh/commit/c595f8ce237cdedff57fee1b6227afc2353d461c))
[21:49:13]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u created label wontfix
[22:14:51]
<Yunohost Git/Infra notifications> [qBittorrent_ynh] @kay0u pushed 1 commit to master: First commit ([bb52d6ae](https://github.com/YunoHost/qBittorrent_ynh/commit/bb52d6ae6172a536e53a045b9d444c74bf6d8a51))
[23:17:43]
<Aleks (he/him/il/lui)> never understood what apps are reported by the matrix notification
[23:17:44]
<Aleks (he/him/il/lui)> hmmm yeah that's weird o_O
[23:17:44]
<kayou> Why so much notifications for a random repo?
[23:18:04]
<Aleks (he/him/il/lui)> ah
[23:18:09]
<Aleks (he/him/il/lui)> it's on the yunohost org, not yunohost-apps
[23:49:56]
<kayou> Oupsi
[23:50:22]
<kayou> I changed that