Tuesday, August 15, 2023
apps@conference.yunohost.org
August
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
     
             

[03:54:48] <Yunohost Git/Infra notifications> App distbin goes down from level 8 to 6 in job [#17822](https://ci-apps.yunohost.org/ci/job/17822)
[09:21:40] <eric_G> I found this project for Synapse administration: https://yaky.dev/apps/synapse-admin/
[09:21:57] <eric_G> seems lighter than the one we have
[09:22:30] <eric_G> to be tested https://github.com/ericgaspar/Synapse-admin-page_ynh
[09:26:16] <lapineige> > <@ericg:matrix.org> seems lighter than the one we have

and that doesn't work 😅
[09:28:25] <eric_G> what doesn't work?
[09:28:25] <eric_G> and when using this https://yaky.dev/apps/synapse-admin/
[09:43:49] <Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[10:06:50] <Yunohost Git/Infra notifications> App z-push goes down from level 8 to 4 in job [#17833](https://ci-apps.yunohost.org/ci/job/17833)
[10:09:13] <Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[10:21:35] <lapineige> https://github.com/YunoHost-Apps/synapse-admin\_ynh/issues/15
This issue had been here for months unfortunatly :'
[10:21:36] <lapineige> https://github.com/YunoHost-Apps/synapse-admin\_ynh/issues/15
This issue had been here for months unfortunatly ☹️
[10:26:43] <eric_G> I am confused...
[10:28:25] <eric_G> are we still talking about this app? https://yaky.dev/apps/synapse-admin/
[12:15:28] <lapineige> Oh sorry it wasn't clear. No. I meant :

> \[the new one you are suggesting\] seems lighter than the one we have \[and the one we already have is broken anyway\]
[12:15:37] <lapineige> Oh sorry, it wasn't clear. No. I meant :

> \[the new one you are suggesting\] seems lighter than the one we have \[and the one we already have is broken anyway\]
[12:54:36] <tituspijean> The one we have already works for me and I'm desperately not understanding why it is not for others. 😅
[13:03:37] <lapineige> (IA powered quantum computing, most likely)
[13:03:42] <lapineige> quantum computing
[13:21:24] <Yunohost Git/Infra notifications> App wireguard_client failed all tests in job [#17834](https://ci-apps.yunohost.org/ci/job/17834) :(
[13:47:06] <Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[13:48:13] <Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[13:53:01] <Yunohost Git/Infra notifications> [my_webapp_ynh] @stilobique opened [pull request #119](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119): Setup 404 error code
[13:55:00] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to update_app_levels: levels: all regressions were fixed in packages, some still waiting for CI, but lets fix levels right away to move forwa... ([78f0e0ba](https://github.com/YunoHost/apps/commit/78f0e0ba354bc3cf881d9f917a59c5347c256822))
[13:55:10] <Yunohost Git/Infra notifications> [apps] @alexAubin edited [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[13:55:39] <Yunohost Git/Infra notifications> [apps] @alexAubin approved [pull request #1715](https://github.com/YunoHost/apps/pull/1715#pullrequestreview-1578610227) Update app levels according to CI results: Congratz on all the fixes o/
[13:58:16] <Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119#discussion_r1294633405) on pull request #119 Setup 404 error code: Cheers I would tend to have this option only in the config panel, because this is an advanced option and otherwise go...
[14:04:11] <Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119#discussion_r1294640183) on pull request #119 Setup 404 error code: Im confused because this setting value doesnt seem to have any effect whatsoever Imho a boolean would be more suitable...
[14:04:11] <Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin edited review [pull request #119](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119#pullrequestreview-1578625712): Setup 404 error code
[14:04:12] <Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119#discussion_r1294639437) on pull request #119 Setup 404 error code: This bit is already in the optional nginx-code-error.conf, shouldnt this block be removed ?
[14:04:12] <Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119#discussion_r1294636860) on pull request #119 Setup 404 error code: Hmmm it should probably do something similar in scrips/config ? Otherwise changing the setting will have no effect unt...
[14:53:34] <Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 3 commits to master ([aba591cd8faf...53027ff76a22](https://github.com/YunoHost/apps/compare/aba591cd8faf...53027ff76a22))
[14:53:34] <Yunohost Git/Infra notifications> [apps] @ericgaspar merged [pull request #1715](https://github.com/YunoHost/apps/pull/1715): Update app levels according to CI results
[14:53:36] <Yunohost Git/Infra notifications> [apps] @ericgaspar deleted branch update_app_levels
[14:53:38] <Yunohost Git/Infra notifications> [apps/master] Update app levels according to CI results - root
[14:53:42] <Yunohost Git/Infra notifications> [apps/master] Merge pull request #1715 from YunoHost/update_app_levels Update app levels according to CI results - Éric Gaspar
[14:53:43] <Yunohost Git/Infra notifications> [apps/master] levels: all regressions were fixed in packages, some still waiting for CI, but lets fix levels right away to move forwa... - Alexandre Aubin
[15:01:12] <Yunohost Git/Infra notifications> [my_webapp_ynh] @ericgaspar edited [pull request #119](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/119): Setup 404 error code
[16:50:11] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to app-store: Initial commit for new app store ([a057aab1](https://github.com/YunoHost/apps/commit/a057aab19803f33fadf0a09c4a5e0144507b0f70))
[16:50:12] <Yunohost Git/Infra notifications> [apps] @alexAubin created new branch app-store
[17:08:47] <Aleks (he/him/il/lui)> https://user-images.githubusercontent.com/4533074/260784106-571180a0-ba77-470d-9f36-c319d21c165b.png 👀
[17:11:32] *tituspijean bookmarks all the things
[17:12:08] <Yunohost Git/Infra notifications> [apps] @alexAubin opened [pull request #1717](https://github.com/YunoHost/apps/pull/1717): New app store
[17:14:43] <eric_G> Do we need so many colors for the tags?
[17:16:01] <eric_G> I think only outline (like system tools) should be enought
[17:16:01] <tituspijean> Nitpicking: should we call it "app store", though? I would expect a "store" to be the place where I can grab apps. (I know there will be the "Install with YunoHost" buttons, but it's rather indirect)
[17:16:02] <Aleks (he/him/il/lui)> yup maybe
[17:16:02] <tituspijean> It looks ***so*** great
[17:16:02] <Aleks (he/him/il/lui)> yeah it's a bit rainbowish, dunno what to think about it ... on the other hand if there's no color it feels too much black&white
[17:16:37] <eric_G> the app logos are colorfull enought 😅
[17:16:52] <Aleks (he/him/il/lui)> ah yes i forgot about the app logos haha
[17:16:53] <Aleks (he/him/il/lui)> will try the outline
[17:17:26] <eric_G> https://aria.im/_matrix/media/v1/download/matrix.org/hrhjhRasKtpqMnHAWBVFUZWJ
[17:17:35] <eric_G> what is this?
[17:18:20] <tituspijean> Number of votes for wishlist or "I'm using this app"
[17:19:03] <tituspijean> ("and I like it")
[17:19:04] <Yunohost Git/Infra notifications> WARNING: unknown pull_request action: converted_to_draft
[17:19:16] <Yunohost Git/Infra notifications> [apps] @alexAubin edited [pull request #1717](https://github.com/YunoHost/apps/pull/1717): New app store
[17:19:26] <Yunohost Git/Infra notifications> [apps] @alexAubin edited [pull request #1717](https://github.com/YunoHost/apps/pull/1717): New app store
[17:20:21] <Aleks (he/him/il/lui)> > <@ericg:matrix.org> sent an image.

low-level warning + number of votes (but yeah i'm not really conviced yet about the design, the transparency thing is a bit "eh")
[17:20:55] <Aleks (he/him/il/lui)> since i don't have any vote data yet i used 123 as a placeholder
[17:21:41] <eric_G> is the number of votes from GitHub app repo?
[17:22:28] <Aleks (he/him/il/lui)> also i don't know yet what semantic to use between "like", "thumbup", "vote", "bookmark", "favorite" ... naively "favorite" + "star icon" is an usual semantic, but so far we already used the star for level 8 apps so hmfng
[17:22:53] <Aleks (he/him/il/lui)> > <@ericg:matrix.org> is the number of votes from GitHub app repo?

no that's meant to be a mechanism where you can vote just by being logged on the forum
[17:24:12] <Aleks (he/him/il/lui)> https://aria.im/_matrix/media/v1/download/matrix.org/sUXOkcafkuFzkCDVDenIakcO
[17:24:27] <Aleks (he/him/il/lui)> quick attempt with only outline badge, it's indeed less overwhelming ;P
[17:25:21] <eric_G> and now black 😅
[17:25:45] <eric_G> I mean 14 categories, 14 colors...
[17:25:56] <Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[17:27:25] <Aleks (he/him/il/lui)> not to mention the sub-tags ;P
[18:38:03] <Yunohost Git/Infra notifications> [apps] @alexAubin edited [pull request #1717](https://github.com/YunoHost/apps/pull/1717): New app store
[20:46:51] <orhtej2> anyone actually using `cockpit`? While I got it running (https://github.com/YunoHost-Apps/cockpit_ynh/pull/21) I have some questions
[20:48:41] <orhtej2> (bonus question: would it be possible to have post-`apt` or post-`apticron` hook?)
[20:48:57] <orhtej2> namely if `change_url` **is** a band-aid for sh** breaking when `apt` updates, is `restore` actually restoring permissions and why are we not shipping version from `backports`
[20:54:56] <Aleks (he/him/il/lui)> > namely if `change_url` **is** a band-aid for sh** breaking when `apt` updates, is `restore` actually restoring permissions and why are we not shipping version from `backports`

uuuuh that's like 4 questions ? x_X
[20:55:14] <Aleks (he/him/il/lui)> what's the relation between change_url and apt and restore, and what's up with backports
[20:55:15] <orhtej2> > I have some question**s** :P
[20:58:43] <orhtej2> > <@Alekswag:matrix.org> what's the relation between change_url and apt and restore, and what's up with backports

so:
- `change_url` does black magic stuff to `/etc/cockpit/cockpit.conf` which seems redundant as well as updates `cockpit.socket` which is super unnecessary
- when you install newer version from `apt` the patching done to `cockpit.socket` is removed and unless there is a way to re-patch the file `cockpit` remains in broken state
- newer versions are no longer shipped in bullseye-main, instead arriving via bullseye-backports, hence my question if it's intentional or a foresight not to use newer source
[21:00:42] <Aleks (he/him/il/lui)> well i'd say, generally speaking, having apps ship their stuff through a "regular" apt/deb package is nice on paper, but in practice it causes a bunch of issues such as "version installed doesn't match the manifest.json/toml because it gets upgraded through apt"
[21:01:12] <Aleks (he/him/il/lui)> and "there is no pre/post-upgrade apt hook mechanism in the current state of things"
[21:01:50] <orhtej2> sure, classic, tbh it's the same with n8n not actually updating (as it ships from `npm`)
[21:03:24] <orhtej2> and since you like Monty Python references
[21:03:25] <orhtej2> https://www.youtube.com/watch?v=0hYZaqYCZyQ
[21:05:23] <orhtej2> imagine app having `$data_dir` with stuff inside. In `backup` you declare it as `--is_big` to skip backing it up on update. Now, when someone intentionally removes the app contents of `$data_dir` get left behind. Any way around that? It's not even explicitly told to the user.
[21:06:14] <orhtej2> second question in the same area: any way to declare `$data_dir` as `--is_big` but `$data_dir/single_specific_file` as... not big?
[21:06:23] <orhtej2> meaning to be included in pre-upgrade backup?
[21:06:44] <Aleks (he/him/il/lui)> eeeh there's the `--purge` option, which existed before packaging v2 was introduced, and now ideally there should be a checkbox when removing the app asking if you want to purge data (in the webadmin) but for now it's not implemented
[21:07:55] <Aleks (he/him/il/lui)> > second question in the same area: any way to declare `$data_dir` as `--is_big` but `$data_dir/single_specific_file` as... not big?

not in the current state of things
[21:07:55] <orhtej2> > <@Alekswag:matrix.org> eeeh there's the `--purge` option, which existed before packaging v2 was introduced, and now ideally there should be a checkbox when removing the app asking if you want to purge data (in the webadmin) but for now it's not implemented

any issue ID to track?
[21:07:55] <orhtej2> > meaning to be included in pre-upgrade backup?

(this is because https://github.com/YunoHost-Apps/trilium_ynh/issues/33 is caused by trilium using IIRC SQLite db stored in `$data_dir`)
[21:07:55] <Aleks (he/him/il/lui)> https://github.com/YunoHost/issues/issues/1854
[21:08:11] <Aleks (he/him/il/lui)> though the discussion was not really updated with the packaging v2 implications
[21:08:35] <Aleks (he/him/il/lui)> basically in packaging v1 there was no simple way to know about this ...
[21:08:36] <Aleks (he/him/il/lui)> annnd
[21:08:55] <Aleks (he/him/il/lui)> well i realize it's about the `--is-big` flag which is anyway still not handled declaratively
[21:09:10] <Aleks (he/him/il/lui)> so for now we'd need to somehow `grep --is-big` in the backup script i guess
[21:10:01] <Aleks (he/him/il/lui)> but the `data_dir` is not removed by default in packaging v2 i think
[21:10:32] <orhtej2> so __a simple__ way around this is to copy the file outside for back up, right?
[21:10:38] <Aleks (he/him/il/lui)> eeeh no idea, depends on specific stuff, maybe yes
[21:10:43] <orhtej2> so ~~a simple~~ way around this is to copy the file outside for back up, right?
[21:10:58] <orhtej2> kk, will have a look
[21:11:03] <orhtej2> thanks! :)
[21:12:45] <orhtej2> > anyone actually using `cockpit`? While I got it running (https://github.com/YunoHost-Apps/cockpit_ynh/pull/21) I have some questions

https://github.com/YunoHost-Apps/cockpit_ynh/blob/1bb1db656f85c9f7c8c2706a4d9c4a11b392eca3/manifest.toml#L10
[21:13:43] <Aleks (he/him/il/lui)> yeah never been super convinced about that maintainer field anyway