Monday, June 19, 2023
apps@conference.yunohost.org
June
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
   
             

[04:52:54] <Yunohost Git/Infra notifications> App veloren failed all tests in job [#16537](https://ci-apps.yunohost.org/ci/job/16537) :(
[10:17:52] <Yunohost Git/Infra notifications> [gitlab_ynh] @kay0u merged [pull request #222](https://github.com/YunoHost-Apps/gitlab_ynh/pull/222): Testing
[10:17:52] <Yunohost Git/Infra notifications> [gitlab_ynh] @kay0u pushed 3 commits to master ([7445b76f6b04...df1e676766ff](https://github.com/YunoHost-Apps/gitlab_ynh/compare/7445b76f6b04...df1e676766ff))
[10:17:55] <Yunohost Git/Infra notifications> [gitlab_ynh/master] 16.0.4 - Kay0u
[10:17:58] <Yunohost Git/Infra notifications> [gitlab_ynh/master] Auto-update README - yunohost-bot
[10:17:59] <Yunohost Git/Infra notifications> [gitlab_ynh/master] Merge pull request #222 from YunoHost-Apps/testing Testing - Kayou
[14:16:49] <Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 1 commit to master: Complain about the usage of YNH_DEFAULT_PHP_VERSION in _common.sh ([809c4560](https://github.com/YunoHost/package_linter/commit/809c45601d9dfbc397ca8479e4a9e08215049e38))
[14:20:37] <Tag> @_@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169
[14:21:05] <Aleks (he/him/il/lui)> 😬
[14:21:13] <Tag> (looks like it's the only app that have this not in a _common.sh tho)
[14:21:13] <Aleks (he/him/il/lui)> aaaaand that is why we need declarative format
[14:22:01] <Aleks (he/him/il/lui)> seems somewhat legit though ... though naively I'd think that just calling the previous command with `phpX.Y` (which it does) should be enough ...
[14:24:15] <Tag> yup
[14:24:22] <Tag> lets remove this line o/
[15:30:58] <tituspijean> > <@tag:lostpod.me> @_@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169

In reply to @tag:lostpod.me
@_@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169

https://i.giphy.com/media/8vUEXZA2me7vnuUvrs/giphy.webp
[15:31:12] <tituspijean> > <@tag:lostpod.me> @_@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169

In reply to Tag
@@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169


https://i.giphy.com/media/8vUEXZA2me7vnuUvrs/giphy.webp

[15:31:48] <tituspijean> > <@tag:lostpod.me> @_@ https://github.com/YunoHost-Apps/kimai2_ynh/blob/master/scripts/install#L169

https://i.giphy.com/media/8vUEXZA2me7vnuUvrs/giphy.webp

[16:40:23] <Tag> again ? :o
https://ci-apps-bookworm.yunohost.org/ci/job/27
[16:40:38] <Tag> 6695 INFO WARNING - /usr/share/yunohost/helpers.d/php: line 229: php-fpm8.2: command not found
[16:40:51] <Aleks (he/him/il/lui)> yes, for other reasons
[16:41:07] <Aleks (he/him/il/lui)> basically that's app not declaring an apt dependency to php whatsoever
[16:41:40] <Aleks (he/him/il/lui)> like this app has no apt dependency at all
[16:41:44] <Tag> aaaah yup mmhmh
[16:41:48] <Aleks (he/him/il/lui)> because it was assumed php would be installed etc
[16:43:02] <Tag> eeeh okay, I guess it's easier to patch them in this case (hoping there's not too many)
[16:43:02] <Aleks (he/him/il/lui)> yeah :/
[16:43:31] <Aleks (he/him/il/lui)> we can also tweak the core to detect that the app calls ynh_add_fpm_config with no "$app-ynh-deps" existing in dpkg
[16:43:38] <Aleks (he/him/il/lui)> to have a proper error message
[16:44:32] <Tag> mmmh well in chtickynotes there's no dependency at all... the $app-ynh-deps is still created in that case ?
[16:44:38] <Aleks (he/him/il/lui)> nope
[16:45:37] <Tag> > <@Alekswag:matrix.org> to have a proper error message

ah, yup!!
[16:46:29] <Tag> proper error message is good for mental health!!
[16:48:45] <Tag> > <@Alekswag:matrix.org> we can also tweak the core to detect that the app calls ynh_add_fpm_config with no "$app-ynh-deps" existing in dpkg

or maybe... doing this in the linter is enough ?
[16:49:15] <Aleks (he/him/il/lui)> the whole thing may feel a bit like nitpicking or something, like why suddenly force apps to declare php dependency when Debian's default PHP version is fine ... but there is in fact a real technical stake behind this, which is that when we upgrade between two major Debian version, it would help a lot to have a proper and formal definition of what php version + php dependency each app relies on ... otherwise we end up in a fuzzy state where some old phpX.Y-foobar packages may be uninstalled, yet might still be necessary for apps, etc ...
[16:50:18] <Tag> well, bozon breaks because of some PHP deprecated stuff so it seems legit to mee https://ci-apps-bookworm.yunohost.org/ci/job/21
[16:51:46] <Tag> [resource.php]
version = ""
!!!!!!
[16:51:59] <Aleks (he/him/il/lui)> > <@tag:lostpod.me> or maybe... doing this in the linter is enough ?

why not but having it in the core would avoid the misleading/confusing error message about missing php8.2-fpm command ... like it's "just" about having some sort of "if "$app-ynh-deps" not listed in dpkg --list; ynh_die "blah blah" " in here https://github.com/YunoHost/yunohost/blob/dev/helpers/php#L59 😅
[16:53:01] <Tag> let's ressource.all_the_thing o/
well that might be "too much" in this case
[16:53:59] <Aleks (he/him/il/lui)> yeah there is some temptation to have a declarative stuff for the technologies used by apps such as PHP version, Node version, etc ...
[16:54:30] <Tag> but that ressource.php could setup config_panel questions and ... yup
[16:55:09] <Aleks (he/him/il/lui)> the thing is that if you require some php version, you will want to have it listed in the apt dependencies ... so if you want to avoid duplicating the info, you end up willing to derive the php version from the apt package list ... otherwise you end up having to implement some consistency check between the PHP version declared, and the APT package list ... and meeeeh
[16:55:34] <Aleks (he/him/il/lui)> yet at the same time, it would be neat to have such a single "technologies" resources listing all tech versions in a single place
[16:55:55] <Aleks (he/him/il/lui)> https://botsin.space/@scream
[16:57:12] <Tag> that ressource.php could add dependencies in the ressource.apt, like under the hood or something
[16:58:26] <Tag> like dependencies gets automagically generated from a
```
[ressource.php]
version = "8.2"
extensions = "gd mysql"
```
[16:59:26] <Aleks (he/him/il/lui)> hmm yeah that would indeed be a more compact/readable way to write the super long `phpX.Y-foo phpX.Y-bar phpX.Y-baz`
[17:00:28] <Aleks (he/him/il/lui)> but not sure it really solves any issue w.r.t to the current issue bookworm CI, the affected apps are not even in packaging v2 yet 😅
[17:02:10] <Aleks (he/him/il/lui)> this should be kept for packaging v3, personally I'd like to try to think about a more global approach about all usual tech like nodejs, ruby etc, i.e. something like

```
[resource.tech]
php.version = "8.2"
php.extensions = "gd mysql"
nodejs.version = "12.2.0"
```
[17:02:51] <Aleks (he/him/il/lui)> or separate stuff with `[resource.php]` on one side, `[resource.nodejs]` on another, idk ...
[17:03:24] <Aleks (he/him/il/lui)> so many design considerations :|
[17:04:21] <Aleks (he/him/il/lui)> thing is, there's also the php (and others) configuration management which gotta be turned into declarative format somehow
[17:04:22] <Tag> mmmh resource.tech can make sense
[17:04:37] <Tag> and having resource.tech.php, resource.tech.ruby...
[17:04:58] <Aleks (he/him/il/lui)> java™
[17:05:24] <Tag> jawhat ?
[17:05:26] <Tag> :D
[17:05:33] <Aleks (he/him/il/lui)> https://media.tenor.com/yM8FVKbpJ7EAAAAC/technology-oh-my-god.gif
[17:07:36] <Tag> php.ini ressemble vite fait à du toml :D
[17:07:40] <Tag> les petites victoires
[18:29:57] <Carlos Solís> Currently trying to package Kbin: https://github.com/csolisr/kbin_ynh
[18:30:12] <Carlos Solís> Extra eyes are welcome - I'm not exactly an expert in packaging
[18:31:02] <Aleks (he/him/il/lui)> how are you proceeding to test it ?
[18:31:02] <Aleks (he/him/il/lui)> nice
[18:31:14] <Carlos Solís> I still haven't reached that point, I'm having several blockers
[18:31:25] <Carlos Solís> For starters, kbin still doesn't release stable tarballs
[18:31:39] <Carlos Solís> So I can't even use version 2 packaging yet
[18:46:19] <lapineige> it doesn't support a commit number ? (with the proper link on github you can have a tarball for any commit)
[19:05:44] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to master: autoupdate_app_sources: stupid fix for apps with tag like v.x.y.z ([24d49284](https://github.com/YunoHost/apps/commit/24d49284fbd0254240638fb65fab98e021227c3d))
[19:19:29] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to master: autoupdate_app_sources: boring special case for dokuwiki ([14002cc5](https://github.com/YunoHost/apps/commit/14002cc5e7f40ae711162987ab13f868e6132c3a))
[20:13:48] <Carlos Solís> > it doesn't support a commit number ? (with the proper link on github you can have a tarball for any commit)

It's hosted in Codeberg, so, no idea of how to force a tarball out of a commit from Gitea
[20:15:49] <Tag> > <@csolisr:azkware.net> It's hosted in Codeberg, so, no idea of how to force a tarball out of a commit from Gitea

https://codeberg.org/Kbin/kbin-core/archive/edb4380fa26eef709b36f1014853d796b28a79d0.tar.gz ;)
[20:16:01] <Carlos Solís> That helps a lot, thanks
[20:16:10] <Carlos Solís> How did you get it?
[20:17:40] <Tag> Well it's a hell of a UX. From a commit page, "Browse source" and then "Download as .tar.gz" from the 3-dots dropdown
[20:18:41] <Tag> I guess there's some API that we could use too, but I don't know Codeberg that much
[20:25:31] <lapineige> > <@csolisr:azkware.net> It's hosted in Codeberg, so, no idea of how to force a tarball out of a commit from Gitea

oh yeah, same issue for me.
What I did as a temporary workaround is close the repo on a github repo and make a release with it
[21:08:41] <Carlos Solís> So, now I'm stuck in the part related to Composer
[21:09:32] <Carlos Solís> ```
composer dump-env prod
composer install --prefer-dist --no-dev --no-autoloader --no-scripts --no-progress
APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear
composer clear-cache
sudo chown kbin:www-data public/media
sudo chmod 777 public/media
```
[21:09:46] <Carlos Solís> How am I supposed to run those lines directly from the install script?
[21:16:45] <Tag> Introducing the composer helper :D
[21:19:56] <Tag> You can have a look at flarum_ynh too
[21:20:15] <Tag> https://yunohost.org/en/packaging_apps_helpers#ynh-composer-install
[21:20:31] <Tag> https://yunohost.org/en/packaging_apps_helpers#ynh_install_composer
[22:12:50] <Carlos Solís> Gotta check that one, thanks again!
[22:13:25] <Carlos Solís> Also, I went and made a list of all my current gripes packaging Kbin, in Kbin: https://kbin.social/m/selfhosted/t/57779/
[23:35:03] <Yunohost Git/Infra notifications> App django-fmd rises from level 7 to 8 in job [#16544](https://ci-apps.yunohost.org/ci/job/16544) !