Friday, March 10, 2023
apps@conference.yunohost.org
March
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
   
             

[18:11:40] <eric_G> at one point it will be easier to move to `.deb` 😂
[18:15:19] <Yunohost Git/Infra notifications> App borg stays at level 4 in job [#14193](https://ci-apps.yunohost.org/ci/job/14193)
[18:15:30] <Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1652](https://github.com/YunoHost/apps/pull/1652): Update app levels according to CI results
[18:15:37] <Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch update_app_levels
[18:15:45] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to update_app_levels: Update app levels according to CI results ([4936aadc](https://github.com/YunoHost/apps/commit/4936aadc1e2472312a2a595aadd19dd09971b666))
[18:17:48] <Aleks (he/him/il/lui)> (had to retrigger it manually, dunno why >_>, #oneday things will just work >_>)
[18:18:32] <Yunohost Git/Infra notifications> App synapse failed all tests in job [#14161](https://ci-apps.yunohost.org/ci/job/14161) :(
[18:18:33] <m606> Hello, I am packaging a simple web app consisting basically of HTML & JS files without any server-side activity.
1. On app's dev repo are available either a built archive than could be simply extracted and used as-is, or the source code to be built with a NodeJS stack (to download, source code is like 10M lighter if it matters). What is the preferred way of doing at YNH in such case (I would personally choose the built archive)?
2. The update script (packaging v2) is only meant to compare version between the ones available locally and in YNH package repo, right ? Setting a dynamic download link at [resources.sources](https://yunohost.org/fr/packaging_apps_resources#sources), such as `{...}/release/latest`, to retrieve automatically upstream updates from app's dev repo and some scripting to modify version number and filename in a few files is I assume out of the current YNH scope?
[18:28:55] <Salamandar> No it seems perfectly fine
[18:29:14] <Salamandar> The thing is, every time a new version is released upstream, you need to edit your app
[18:29:21] <Salamandar> more precisely, conf/app.src
[18:29:55] <Salamandar> this file will contain the url to the latest sources AND a checksum for those sources
[18:42:02] <Aleks (he/him/il/lui)> (app.src is being replaced by `[resources.sources]` mentioned by m606, but that's like, since yesterday 😝)
[19:01:13] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to master: outline is not totally free (cf the README) ([909ca3aa](https://github.com/YunoHost/apps/commit/909ca3aa5d1bf5f3e3ca54b6b4dfe8aade8ea614))
[19:08:59] <Aleks (he/him/il/lui)> m606:
1. imho the recommendation is indeed "if you can avoid building stuff on the desination machine, don't and use the pre-built version instead"
2. i'm confused but there's an "auto-updater" mechanism currently based on github actions / CI where one defines a bash script to check for newer version and updates the files accordingly ... the goal is to adapt this mechanism to have a simple and minimal syntax to just explain "check for new tags on repo X" and then have some automagic logic handled by the yunohost-apps org that update the file ... but for now we're with that `.github` flow ;P