[00:30:37]
<Yunohost Git/Infra notifications> Application synapse-admin rises from level (unknown) to level 8 on https://ci-apps.yunohost.org/ci/job/13515
[02:38:40]
<Yunohost Git/Infra notifications> Application yunorunner stays at level 2 on https://ci-apps.yunohost.org/ci/job/13517
[11:51:04]
<eric_G[m]> `yunohost permission list` or `permissions` don't seem to exist... But `yunohost user permission list`output is :
```
element.main:
allowed: visitors
```
[11:51:08]
<eric_G[m]> During element_ynh (v2) app install I have those permissions to choose from:
```
Who should have access to this app? (This can later be changed) [all_users | visitors | user1 |user2 | admins |
synapse]
```
[11:51:08]
<eric_G[m]> `all_users` permission seem to be missing
[11:51:09]
<eric_G[m]> How is `[install.init_main_permission]` working? It looks that you have to choose between `visitors` or `all_users`, can't we have both permissions? (is public/private setting deprecated?)
[11:51:09]
<Yunohost Git/Infra notifications> While testing blogotext: Package check aborted, timeout reached (180 min).
[11:52:33]
<Aleks (he/him/il/lui)> > <@ericg:matrix.org> `yunohost permission list` or `permissions` don't seem to exist... But `yunohost user permission list`output is :
> ```
> element.main:
> allowed: visitors
> ```
hmmm that sounds okay, "all_users" is implied by the fact that "visitors" is allowed (i mean it basically means the app is public)
[11:52:34]
<Aleks (he/him/il/lui)> we should check with `--full` to have the detail, espectially that the `tile` thing is set to true
[11:53:25]
<Aleks (he/him/il/lui)> > <@ericg:matrix.org> During element_ynh (v2) app install I have those permissions to choose from:
> ```
> Who should have access to this app? (This can later be changed) [all_users | visitors | user1 |user2 | admins |
> synapse]
> ```
hmyeah it's a bit funky to see the whole user list in there, maybe we should ignore primary groups (= single users) in there
[11:53:59]
<Aleks (he/him/il/lui)> > <@ericg:matrix.org> How is `[install.init_main_permission]` working? It looks that you have to choose between `visitors` or `all_users`, can't we have both permissions? (is public/private setting deprecated?)
public/private is replaced by init_main_permission yeah, and visitors implicitly means that also all_users have access
[11:57:58]
<eric_G[m]> > <@Alekswag:matrix.org> we should check with `--full` to have the detail, espectially that the `tile` thing is set to true
```
element.main:
additional_urls:
allowed: visitors
auth_header: True
corresponding_users:
label: Element
protected: False
show_tile: True
url: domain.tld/element
```
[11:58:17]
<Aleks (he/him/il/lui)> eeeeh
[12:00:16]
<Aleks (he/him/il/lui)> hmyeah it should work, the tile should be displayed ? x_x
[12:01:08]
<eric_G[m]> maybe, but I can't see it 😬
[12:01:22]
<Aleks (he/him/il/lui)> wtf :D
[12:01:32]
<Aleks (he/him/il/lui)> and you're sure it's the same server right ? 😅
[12:01:45]
<eric_G[m]> yes
[12:03:39]
<eric_G[m]> in the webadmin I can't see Element in all_users panel
[12:04:03]
<Aleks (he/him/il/lui)> yeah it's expected
[12:06:33]
<eric_G[m]> but if `visitors` implicitly means that also `all_users` have access, we should have Element in `all_users` list no?
[12:28:24]
<Aleks (he/him/il/lui)> i mean, it means that people logged in the user portal should see the tile anyway
[12:28:53]
<Aleks (he/him/il/lui)> i have one app (h5ai) on my server, with `allowed: visitors` and can perfectly see the tile in the user portal
[12:30:09]
<Aleks (he/him/il/lui)> well actually i can see no shit because on my personal server /yunohost/sso currently gives me a 404 😅
[12:34:01]
<eric_G[m]> is h5ai app using package v2?
[12:34:18]
<Aleks (he/him/il/lui)> nope 😅
[12:34:41]
<Aleks (he/him/il/lui)> but that shouldnt matter because my point is the permission is configured in the same way
[12:35:06]
<Aleks (he/him/il/lui)> i guess we could double check the "element.main" block in /etc/ssowat/conf.json
[12:37:45]
<eric_G[m]> `"users": []` is empty
[12:39:34]
<Aleks (he/him/il/lui)> yes that's expected, because `public` should be true 😅
[12:40:48]
<Aleks (he/him/il/lui)> should look like:
```json
"h5ai.main": {
"auth_header": true,
"label": "H5AI",
"public": true,
"show_tile": true,
"uris": [
"domain.tld/path"
],
"use_remote_user_var_in_nginx_conf": true,
"users": []
},
```
[12:43:42]
<eric_G[m]> `"use_remote_user_var_in_nginx_conf": false,` this is set to false for me
[12:43:48]
<eric_G[m]> ```
"element.main": {
"auth_header": true,
"label": "Element",
"public": true,
"show_tile": true,
"uris": [
"domain.tld/element"
],
"use_remote_user_var_in_nginx_conf": false,
"users": []
},
```
[12:43:50]
<Aleks (he/him/il/lui)> yeah that doesnt really matter for the user portal, that's more about authentication stuff
[12:43:55]
<Aleks (he/him/il/lui)> I don't understand why the tile wouldnt be in your portal x_x
[12:44:18]
<eric_G[m]> maybe someone can test from https://github.com/YunoHost-Apps/element_ynh/tree/v2.
[12:47:12]
<Aleks (he/him/il/lui)> (maybe i'm completely mistaking and the `users` list should list users, I'm trying to triple-check this 😬)
[12:50:51]
<Aleks (he/him/il/lui)> thinking intensifies
[12:53:00]
<Aleks (he/him/il/lui)> uuuuuuuhu
[12:53:20]
<Aleks (he/him/il/lui)> indeed on saperlipopette still on 4.x public apps have the user list in the conf.json x_X
[12:53:35]
<Aleks (he/him/il/lui)> eeeeeeh
[12:53:36]
<Aleks (he/him/il/lui)> wtf how did nobody complain about this earlier
[12:53:44]
<Aleks (he/him/il/lui)> uuuuh
[12:54:04]
<Aleks (he/him/il/lui)> 🙀
[12:55:29]
<Aleks (he/him/il/lui)> zomg my h5ai is in fact not in the portal
[12:55:29]
<Aleks (he/him/il/lui)> t
[12:55:29]
<Aleks (he/him/il/lui)> wuuuu
[13:01:16]
<Aleks (he/him/il/lui)> aaaaaaa
[13:03:38]
<yunohelper> Hello! It looks like you are panicking. Have you tried refactoring?
[13:03:58]
<Aleks (he/him/il/lui)> omg titus x)
[13:06:02]
<Aleks (he/him/il/lui)> my god you were right on everything eric_G, the perm should include all_users too x_x
[13:06:04]
<Aleks (he/him/il/lui)> I think ?
[13:07:10]
<tituspijean> IIRC that was the default behavior before, if we said the app was public in the installation form. Or rather, `all_users` was always given access to any installed apps, whether it is selected as public or not.
[13:07:58]
<Aleks (he/him/il/lui)> ah yes and then `visitors` was added if it's public : https://github.com/YunoHost-Apps/my_webapp_ynh/blob/master/scripts/install#L185
[13:08:10]
<Aleks (he/him/il/lui)> okay so the new permission thingy should just do that
[13:39:14]
<eric_G[m]> aaa
[13:39:54]
<eric_G[m]> with 3 a, looks like i am not panicking...
[13:52:11]
<tituspijean> (I was merely triggering the bot manually with a custom sentence, but I could definitely implement that 🙃)
[13:54:31]
<eric_G[m]> damn it! I was hoping some chatGPT bot implementation. I am disappointed
[13:56:34]
<tituspijean> ooof I hope not, have you seen how talkative it is? 😆 It would not stop interrupting the flow of the conversation like... oh no, _I do_ 😥
[15:36:24]
<Aleks (he/him/il/lui)> sooooo i'm gonna try to take care of deploying the new yunorunner/package_check in a couple minutes/hours to improve the situation with locks etc
[15:58:03]
<tituspijean> SNAFU incoming 😛
[15:58:36]
<eric_G[m]> Snappymail should be the first app in master using package v2 (after 20euros of course)
[16:02:27]
<tituspijean> 'twas a *snappy* update 😛
[16:10:21]
<Guillaume Bouzige> hi there, can anyone remind me the dates / times of the next two upcoming meetings ? I would love to join but I need to block my agenda
[16:10:25]
<Aleks (he/him/il/lui)> SNAFU ? 🤔
[16:10:47]
<Aleks (he/him/il/lui)> Guillaume Bouzige: we meet every 1st and 3rd thursday of every month
[16:11:03]
<Aleks (he/him/il/lui)> next one is Thrusday 16th
[16:11:14]
<Aleks (he/him/il/lui)> and there's a "Contributor meeting" thread on the forum
[16:11:21]
<Aleks (he/him/il/lui)> in the Contribute Room section
[16:12:11]
<Guillaume Bouzige> great thanks aleks!
[16:17:02]
<tituspijean> > <@Alekswag:matrix.org> SNAFU ? 🤔
https://www.urbandictionary.com/define.php?term=SNAFU 😇
[16:18:39]
<Aleks (he/him/il/lui)> haha xD
[16:27:29]
<Yunohost Git/Infra notifications> Application ihatemoney stays at level 1 on https://ci-apps.yunohost.org/ci/job/13526
[16:32:54]
<Guillaume Bouzige> > <@Alekswag:matrix.org> Guillaume Bouzige: we meet every 1st and 3rd thursday of every month
at what time ?
[16:34:20]
<Aleks (he/him/il/lui)> 8:30 (pm), though it usually really start at 8:45~9ish
[16:34:39]
<Guillaume Bouzige> okay
[16:34:47]
<Guillaume Bouzige> paris time I guess
[17:02:23]
<p4p4j0hn> Is it possible to use a local copy of an app repository with the ynh-dev container?
[17:03:52]
<p4p4j0hn> For testing before pushing to my repo.
[17:11:43]
<Aleks (he/him/il/lui)> yes
[17:11:51]
<Aleks (he/him/il/lui)> you can `yunohost app install /some/local/path`
[17:12:05]
<Aleks (he/him/il/lui)> e.g `yunohost app install /ynh-dev/path/to/your/app`
[17:12:57]
<p4p4j0hn> Ok, great! I was trying to pass -u file:///ynh-dev/...
[17:14:57]
<p4p4j0hn> Is it possible to upgrade an app that way as well?
[17:16:25]
<Aleks (he/him/il/lui)> yup, that one is slightly less straightfoward : `yunohost app upgrade --file /path/to/your/app`
[17:16:35]
<Aleks (he/him/il/lui)> (or `-f` instead of `--file`)
[17:17:39]
<Aleks (he/him/il/lui)> aaaand if you're upgrading from the same version (ie the "version" key in the manifest didnt change) you'll want to `--force`
[17:17:40]
<Aleks (he/him/il/lui)> `--force` is also useful for the install actually, 'cause YunoHost will complain that you might be installing a third party app
[17:17:45]
<Aleks (he/him/il/lui)> (to avoid typing 'Yes, I understand')
[17:20:43]
<p4p4j0hn> Ok, thank you so much! :-)
[17:24:54]
<Aleks (he/him/il/lui)> @room beware I'm merging which has some non-backward compatible changes (naming of the full_log / result.json / summary.png) when used with yunorunner https://github.com/YunoHost/package_check/pull/137 so be sure to upgrade yunorunner if you're your own yunorunner instance ;P
[17:33:38]
<Yunohost Git/Infra notifications> [package_check] @alexAubin merged [pull request #137](https://github.com/YunoHost/package_check/pull/137): Moar refactoring
[17:33:39]
<Yunohost Git/Infra notifications> [package_check] @alexAubin pushed 3 commits to master ([83d4d8f292a4...af359e9dfec3](https://github.com/YunoHost/package_check/compare/83d4d8f292a4...af359e9dfec3))
[17:33:40]
<Yunohost Git/Infra notifications> [package_check/master] Moar refactoring - Alexandre Aubin
[17:34:05]
<Yunohost Git/Infra notifications> [package_check/master] Merge pull request #137 from YunoHost/moar-refactoring Moar refactoring - Alexandre Aubin
[17:34:05]
<Yunohost Git/Infra notifications> [package_check/master] Fixes after tests on the battlefield - Alexandre Aubin
[17:34:06]
<Yunohost Git/Infra notifications> [package_check] @alexAubin deleted branch moar-refactoring
[17:49:07]
<Aleks (he/him/il/lui)> (and i'm also gonna restart yunorunner a few time which is gonna mess with the jobs on ci-apps-dev and ci-apps)
[18:04:57]
<p4p4j0hn> I can't seem to add lxc remote add yunohost https://devbaseimgs.yunohost.org --public
[18:05:17]
<p4p4j0hn> Error: Get "https://devbaseimgs.yunohost.org:8443": Unable to connect to: devbaseimgs.yunohost.org:8443 ([dial tcp 80.67.172.144:8443: i/o timeout dial tcp [2001:910:1410::1]:8443: connect: network is unreachable])
[18:05:41]
<Aleks (he/him/il/lui)> uuuugh yeah there was just a small outage on the infrastructure right now 😅
[18:06:02]
<Aleks (he/him/il/lui)> maybe retry now or in a couple minutes
[18:08:26]
<p4p4j0hn> Ok
[18:19:21]
<p4p4j0hn> Is there a way to require a previous package version for upgrading?
[18:22:47]
<Yunohost Git/Infra notifications> While testing matrix-puppet-discord: It looks like package_check did not finish properly ... on https://ci-apps.yunohost.org/ci/job/13529
[18:29:54]
<Yunohost Git/Infra notifications> While testing mediawiki: It looks like package_check did not finish properly ... on https://ci-apps.yunohost.org/ci/job/13530
[18:30:28]
<Aleks (he/him/il/lui)> > <p4p4j0hn> Is there a way to require a previous package version for upgrading?
not sure what you mean
[18:40:23]
<p4p4j0hn> Say an admin did not upgrade an app for a while and several versions passed. Now the package cannot be upgraded from the currently installed version to the latest version. Are there checks for that? Is there a way to specify which versions are able to upgrade to the latest?
[18:41:50]
<p4p4j0hn> Castopod in beta was an example of this. Each minor version had database migrations that if they weren't followed exactly in order, the app upgrade would fail if skipping versions.
[18:43:34]
<Aleks (he/him/il/lui)> not really, but you can implement it in the upgrade script, somthing like `if dpkg --compare-version $current\_version lt 1.2.3; ynh\_print\_error "Upgrading from that version is not supported"; exit 1; fi`
[18:43:45]
<Aleks (he/him/il/lui)> not really, but you can implement it in the upgrade script, somthing like `if dpkg --compare-version $current_version lt 1.2.3; ynh_print_error "Upgrading from that version is not supported"; exit 1; fi`
[18:44:01]
<Aleks (he/him/il/lui)> (not sure about the exact syntax or helpers to use, but you get the idea)
[18:45:33]
<Aleks (he/him/il/lui)> with packaging v2, you could add a disclaimer in `doc/PRE_UPGRADE.d/1.2.3.md` which will only be displayed for people coming from a version lower than `1.2.3`
[18:45:36]
<Aleks (he/him/il/lui)> (though that wont prevent them from actually running the upgrade)
[18:47:55]
<p4p4j0hn> Ok, thanks. I've been working on the trilium notes package. I really like using it and I noticed that it wasn't being kept up so I'm working on getting it up to the current version.
[22:45:48]
<ljf> i finally fixed the postgresql migration for mattermost :)
[22:53:32]
<oufmilo[m]> > <@Alekswag:matrix.org> @room beware I'm merging which has some non-backward compatible changes (naming of the full_log / result.json / summary.png) when used with yunorunner https://github.com/YunoHost/package_check/pull/137 so be sure to upgrade yunorunner if you're your own yunorunner instance ;P
Just a git pull is enough for the upgrade?
[22:54:31]
<Aleks (he/him/il/lui)> hmmm
[22:54:31]
<Aleks (he/him/il/lui)> no 😅
[22:55:00]
<Aleks (he/him/il/lui)> maybe you need to add `YNH_BRANCH="stable"` to config.py, though in fact i should add this as a default
[22:55:13]
<Aleks (he/him/il/lui)> `PATH_TO_ANALYZER` becomes irrelevant so might be better to remove it
[22:55:23]
<Aleks (he/him/il/lui)> but that should be all I think
[22:59:14]
<Yunohost Git/Infra notifications> [package_check] @alexAubin pushed 1 commit to master: Add a damn retry system when failing to stop LXC or restore snapshot ... ([ba3a19cf](https://github.com/YunoHost/package_check/commit/ba3a19cfcd856efa9615549029d5cebc68d84db6))
[22:59:48]
<Yunohost Git/Infra notifications> [package_check] @alexAubin pushed 1 commit to master: Typo :| ([5094fbee](https://github.com/YunoHost/package_check/commit/5094fbee722a13fdfbb4f0a6c4f5a398e0b2be73))
[23:03:50]
<Yunohost Git/Infra notifications> [package_check] @alexAubin pushed 1 commit to master: Typos ([a315eacf](https://github.com/YunoHost/package_check/commit/a315eacfa718ae10e7d6feb1b66abca944f41d32))
[23:12:21]
<oufmilo[m]> > <@Alekswag:matrix.org> `PATH_TO_ANALYZER` becomes irrelevant so might be better to remove it
Always in config.py ? I don't have it
[23:12:52]
<Aleks (he/him/il/lui)> hmmm maybe not
[23:13:03]
<Aleks (he/him/il/lui)> if it's not there then cool i guess