Thursday, December 28, 2023
apps@conference.yunohost.org
December
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
             

[01:54:05] <Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-faircamp
[01:54:05] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-faircamp: Add Faircamp to wishlist ([26968428](https://github.com/YunoHost/apps/commit/26968428804da9a410a8c209c310d5164311a7ae))
[01:54:08] <Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1939](https://github.com/YunoHost/apps/pull/1939): Add Faircamp to wishlist
[01:56:17] <Yunohost Git/Infra notifications> [apps] @alexAubin merged [pull request #1939](https://github.com/YunoHost/apps/pull/1939): Add Faircamp to wishlist
[01:56:18] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 2 commits to master ([81a11f905c67...a78b586b15f0](https://github.com/YunoHost/apps/compare/81a11f905c67...a78b586b15f0))
[01:56:21] <Yunohost Git/Infra notifications> [apps] @alexAubin deleted branch add-to-wishlist-faircamp
[01:56:22] <Yunohost Git/Infra notifications> [apps/master] Add Faircamp to wishlist - yunohost-bot
[01:56:26] <Yunohost Git/Infra notifications> [apps/master] Merge pull request #1939 from YunoHost/add-to-wishlist-faircamp Add Faircamp to wishlist - Alexandre Aubin
[02:19:24] <Yunohost Git/Infra notifications> App headphones failed all tests in job [#21722](https://ci-apps.yunohost.org/ci/job/21722) :(
[02:24:38] <Yunohost Git/Infra notifications> App luckysheet failed all tests in job [#21723](https://ci-apps.yunohost.org/ci/job/21723) :(
[02:29:57] <Yunohost Git/Infra notifications> App miniflux failed all tests in job [#21724](https://ci-apps.yunohost.org/ci/job/21724) :(
[02:34:24] <Yunohost Git/Infra notifications> App mosquitto failed all tests in job [#21725](https://ci-apps.yunohost.org/ci/job/21725) :(
[02:41:34] <Yunohost Git/Infra notifications> App headphones failed all tests in job [#21722](https://ci-apps.yunohost.org/ci/job/21722) :(
[02:47:13] <Yunohost Git/Infra notifications> App luckysheet failed all tests in job [#21723](https://ci-apps.yunohost.org/ci/job/21723) :(
[02:47:21] <Aleks (he/him/il/lui)> thisisfine.jpg
[02:47:24] <Yunohost Git/Infra notifications> App miniflux failed all tests in job [#21724](https://ci-apps.yunohost.org/ci/job/21724) :(
[02:47:28] <Yunohost Git/Infra notifications> App mosquitto failed all tests in job [#21725](https://ci-apps.yunohost.org/ci/job/21725) :(
[03:27:28] <Émy - OniriCorpe> is there a way for CI additional tests to provide a custom script to verify if the additionnal test is sucessful or not?
[03:32:40] <Aleks (he/him/il/lui)> nope, but it would be a welcome addition to (horror movie jingle) package_check
[03:38:33] <Émy - OniriCorpe> I open an issue for that :")
[03:41:52] <Yunohost Git/Infra notifications> [package_check] @OniriCorpe opened [issue #147](https://github.com/YunoHost/package_check/issues/147): [enh] possibility to add a script to validate custom tests
[03:47:30] <Yunohost Git/Infra notifications> [gitlab_ynh] @ChvckN0rri5 [commented](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237#issuecomment-1870795859) on [issue #237](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237) WIP: Pages: ### Comment from the Peanut Gallery: **Can we integrate the pages, registry, and Mattermost please?** Thank you, Chvck...
[03:55:57] <Yunohost Git/Infra notifications> [gitlab_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237#issuecomment-1870799115) on [issue #237](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237) WIP: Pages: This is not the place for feature request.
[03:56:38] <Yunohost Git/Infra notifications> [package_check] @alexAubin [commented](https://github.com/YunoHost/package_check/issues/22#issuecomment-1870799370) on [issue #22](https://github.com/YunoHost/package_check/issues/22) Allow to select tests to be paused via --interrupt: Closing because its 6 years old and I doubt anybody really does run package check manually and needs this ...
[03:56:38] <Yunohost Git/Infra notifications> [package_check] @alexAubin closed [issue #22](https://github.com/YunoHost/package_check/issues/22): Allow to select tests to be paused via --interrupt
[03:57:51] <Yunohost Git/Infra notifications> [package_check] @alexAubin closed [issue #123](https://github.com/YunoHost/package_check/issues/123): Sometimes private test fails
[03:57:51] <Yunohost Git/Infra notifications> [package_check] @alexAubin [commented](https://github.com/YunoHost/package_check/issues/123#issuecomment-1870799780) on [issue #123](https://github.com/YunoHost/package_check/issues/123) Sometimes private test fails: Closing because starting with bookworm i have disabled private test which are not really relevant, sometimes they are re...
[03:58:42] <Yunohost Git/Infra notifications> [package_check] @alexAubin [commented](https://github.com/YunoHost/package_check/issues/93#issuecomment-1870800039) on [issue #93](https://github.com/YunoHost/package_check/issues/93) Run package-check via github actions?: Closing because we cant realistically run big LXC stuff in github actions and its not practical for various reasons
[03:58:42] <Yunohost Git/Infra notifications> [package_check] @alexAubin closed [issue #93](https://github.com/YunoHost/package_check/issues/93): Run package-check via github actions?
[04:15:44] <Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 1 commit to master: Complain about using --line_match=Started/Stopped which is irrelevant/counterproductive ([c989679b](https://github.com/YunoHost/package_linter/commit/c989679ba3c00668b46d52b39b6a19f23522aa47))
[05:30:50] <Yunohost Git/Infra notifications> App peertube rises from level 6 to 8 in job [#21726](https://ci-apps.yunohost.org/ci/job/21726) !
[06:55:47] <Yunohost Git/Infra notifications> App sonarr failed all tests in job [#21731](https://ci-apps.yunohost.org/ci/job/21731) :(
[17:19:56] <Yunohost Git/Infra notifications> [example_ynh] @OniriCorpe [commented](https://github.com/YunoHost/example_ynh/pull/198#issuecomment-1871359124) on [issue #198](https://github.com/YunoHost/example_ynh/pull/198) Create application log directory in restore: Maybe it will be better if the core handle this with the v2 packaging?

So the core would create "/var/log/app" at in...
[17:38:09] <Yunohost Git/Infra notifications> [example_ynh] @Salamandar [commented](https://github.com/YunoHost/example_ynh/pull/198#issuecomment-1871370528) on [issue #198](https://github.com/YunoHost/example_ynh/pull/198) Create application log directory in restore: Yes, this is actually in the packaging v3 "wish list"
[18:18:07] <kayou> > <@yunohostinfra:matrix.org> [gitlab_ynh] @ChvckN0rri5 [commented](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237#issuecomment-1870795859) on [issue #237](https://github.com/YunoHost-Apps/gitlab_ynh/pull/237) WIP: Pages: ### Comment from the Peanut Gallery: **Can we integrate the pages, registry, and Mattermost please?** Thank you, Chvck...

Ça fait partie des raisons pour lesquelles j'ai pris mes distances avec YNH, c'est tellement usant ce genre de comportement. Faire sa liste de courses en espérant que ça tombe tout cuit dans la bouche.
Bon de toute façon j'hésitais encore entre mettre une option lors de l'install pour ajouter ces fonctionnalités ou juste écrire de la Doc en disant "démerdez vous à le conf vous même si vous voulez, PR welcome"
[18:26:15] <kayou> About https://github.com/YunoHost-Apps/netdata_ynh/pull/133
Do you think is a bad idea to add `^` for each app? We want to match the whole path anyway
[18:27:53] <Aleks (he/him/il/lui)> hmmm not sure to understand why you'd need this o.O
[18:28:54] <Aleks (he/him/il/lui)> maybe that's related to using a regex, which nginx will match "anywhere in the URI" but in the nominal case / most app, we use a simple string (not a regex) ?
[18:28:54] <kayou> Here we need it because of `~` I think
[18:29:24] <kayou> Yeah probably 🤔
[18:30:15] <Aleks (he/him/il/lui)> but forgetting that ^ when using ~ looks like an easy mistake yeah
[18:31:10] <kayou> I'm not sure we use it a lot
[18:32:19] <Aleks (he/him/il/lui)> ```
> grep -nr "location ~ __PATH" */conf
dex/conf/nginx.conf:2:location ~ __PATH__/$ {
dex/conf/nginx.conf:8:location ~ __PATH__/.+ {
dokuwiki/conf/nginx.conf:37: location ~ __PATH__/\.ht {
galette/conf/nginx.conf:28:#location ~ __PATH__/(data|config|lib)/ {
kresus/conf/nginx.conf:10:location ~ __PATH__/\.(css|js|png|jpe?g|svg|eot|woff2?)$ {
matomo/conf/nginx.conf:56: location ~ __PATH__/\.ht {
mattermost/conf/nginx.conf:3:location ~ __PATH__/api/v[0-9]+/(users/)?websocket$ {
phpbb/conf/nginx.conf:26: location ~ __PATH__/(config\.php|common\.php|cache|files|images/avatars/upload|includes|(?<!ext/)phpbb(?!\w+)|store|vendor) {
prowlarr/conf/nginx.conf:22:#location ~ __PATH__/[0-9]+/api {
```
[18:32:44] <kayou> Master of grep <3
[18:34:09] <kayou> I think it's not a problem if the location ^ __PATH/... Is inside another location __PATH/
[18:35:05] <nicofrand> Uh, why have I been hl'ed by that grep?
[18:35:37] <kayou> ¯\_(ツ)_/¯
[18:36:07] <Aleks (he/him/il/lui)> do you have a hook on kresus or something ?
[18:36:29] <nicofrand> Yes! Did not see Kresus in it though?
[18:36:40] <kayou> We can do that in matrix O.o
[18:36:41] <nicofrand> Ahhh my bad
[18:37:15] <kayou> > <@kayou:matrix.org> We can do that in matrix O.o

Yes we can, didn't know that
[18:38:10] <Aleks (he/him/il/lui)> so grepping only line with location at the very beginning (no space suggesting that it's inside another location bloc) that leaves us with : dex, kresus, mattermost, though only the dex one seems really "too wide" to be problematic
[18:38:55] <nicofrand> Is there a problem with Kresus' nginx config?
[18:42:10] <kayou> > Is there a problem with Kresus' nginx config?

I don't think so
[18:43:21] <eric_G> I have this issue with version 2 of netdata where The removal script relies on the `netdata-uninstaller.sh` script to remove the application. since the user is deleted automatically before running this script, we get errors on CI. `ERROR Failed to delete system user for netdata`
[18:43:21] <Aleks (he/him/il/lui)> it's very minor, the `location ~ __PATH__/\.(css|js|png|jpe?g|svg|eot|woff2?)$ {` could match anything such as `whatever/foo/bar/baz/__PATH__/something.css`, ie something that should probably be handled by another route, and the fix for this is to write`location ~ ^PATH` (not the additional `^`)
[18:43:24] <eric_G> https://github.com/YunoHost-Apps/netdata_ynh/pull/135
[18:43:30] <kayou> The problem is only when there is a location ~ .. at the beginning
[18:44:54] <Aleks (he/him/il/lui)> > <@ericg:matrix.org> I have this issue with version 2 of netdata where The removal script relies on the `netdata-uninstaller.sh` script to remove the application. since the user is deleted automatically before running this script, we get errors on CI. `ERROR Failed to delete system user for netdata`

uuh it looks more like the user is deleted *after* the remove script yet some process is still running somewhere using that user ?
[18:45:20] <Aleks (he/him/il/lui)> like maybe the service needs to be actually stopped ?
[18:45:22] <eric_G> I have tried to remove from the script the code that delete user https://github.com/YunoHost-Apps/netdata_ynh/pull/136
[18:46:26] <kayou> > <@kayou:matrix.org> The problem is only when there is a location ~ .. at the beginning

Well in fact there is indeed a small problem here
https://github.com/YunoHost-Apps/kresus_ynh/blob/master/conf%2Fnginx.conf#L10
[18:46:48] <kayou> I'll add a warning in package_linter
[18:48:28] <Aleks (he/him/il/lui)> eric_G: ah i see, you mean this script removes the user before yunohost's attempt to remove the user ...
[18:48:32] <Aleks (he/him/il/lui)> meh honestly i don't understand why that script exists, it really looks super convoluted
[18:50:00] <thatoo> Good evening,


I'm still trying to figure out if I can make a Dokos package.
In the install  script, I need to run a command that require mysql CREATE USER privilege. Even if I create the user and the database in advance and I pass them as arguments, the command needs it. Either is asks (prompt) for the mysql root password or I should pass it as argument or I should pass as arguments a specific user and its password who has CREATE USER privilege : 


If I create the db $db_name and its user $db_name with password $db_user_pass
`` bench new-site $site_name --db-name $db_name --db-password $db_user_pass --force --admin-password $admin_pass ``
or if I let it create random db/user/password
`` bench new-site $site_name --admin-password $admin_pass ``
in both case it would ask/prompt for mysql root password
or
`` bench new-site $site_name --db-root-password $mysql_root_pass --admin-password $admin_pass ``
then I pass mysql root password as argument so it won't prompt for it
or I can create an other user with CREATE USER privilege
`` bench new-site $site_name --db-root-username $user_can_create_user --db-root-password $special_user_pass --admin-password $admin_pass ``
Could you tell me how I could integrate safely one of this command inside a yunohost package install script?
[18:52:31] <Aleks (he/him/il/lui)> i don't understand why it would need to prompt for the mysql root password, that makes no sense ... are you sure the credentials are correct, like are you sure about `--db-password $db_user_pass` ? The standard variable is supposed to be `$db_pwd` in packaging v2 ...
[18:52:32] <Aleks (he/him/il/lui)> also it's weird that there not `--db-user` in this command
[18:52:50] <Aleks (he/him/il/lui)> usually the app needs the 3 infos : db name, db user (usually equal to db name), and db password
[18:54:15] <Aleks (he/him/il/lui)> or maybe not in this case ... https://frappeframework.com/docs/user/en/bench/reference/new-site#options
[18:54:28] <Aleks (he/him/il/lui)> but i'm seeing `--db-type` which should be `mariadb` probably
[18:54:39] <Aleks (he/him/il/lui)> (ah, that's the default)
[18:55:11] <thatoo> db user is always equal to db name, that's why they don't require it
[18:56:04] <Aleks (he/him/il/lui)> so what about `$db_user_pass` instead of `$db_pwd`
[18:56:13] <Aleks (he/him/il/lui)> it would help if you can share a link to the actual code and logs ...
[18:57:05] <thatoo> > <@Alekswag:matrix.org> so what about `$db_user_pass` instead of `$db_pwd`

that's ok. I didn't choose a standard name, sorry
[18:57:21] <thatoo> I edit my writting
[18:57:43] <thatoo> Good evening,


I'm still trying to figure out if I can make a Dokos package.
In the install  script, I need to run a command that require mysql CREATE USER privilege. Even if I create the user and the database in advance and I pass them as arguments, the command needs it. Either is asks (prompt) for the mysql root password or I should pass it as argument or I should pass as arguments a specific user and its password who has CREATE USER privilege : 


If I create the db $db_name and its user $db_name with password $db_user_pass
`` bench new-site $site_name --db-name $db_name --db-password $db_pwd --force --admin-password $admin_pass ``
or if I let it create random db/user/password
`` bench new-site $site_name --admin-password $admin_pass ``
in both case it would ask/prompt for mysql root password
or
`` bench new-site $site_name --db-root-password $mysql_root_pass --admin-password $admin_pass ``
then I pass mysql root password as argument so it won't prompt for it
or I can create an other user with CREATE USER privilege
`` bench new-site $site_name --db-root-username $user_can_create_user --db-root-password $special_user_pass --admin-password $admin_pass ``
Could you tell me how I could integrate safely one of this command inside a yunohost package install script?
[18:57:51] <Aleks (he/him/il/lui)> but like you shouldnt even have to "choose" the name in packaging v2 x_x
[18:58:29] <thatoo> Good evening,


I'm still trying to figure out if I can make a Dokos package.
In the install  script, I need to run a command that require mysql CREATE USER privilege. Even if I create the user and the database in advance and I pass them as arguments, the command needs it. Either is asks (prompt) for the mysql root password or I should pass it as argument or I should pass as arguments a specific user and its password who has CREATE USER privilege : 


If I create the db $db_name and its user $db_name with password $db_user_pass
`` bench new-site $site_name --db-name $db_name --db-password $db_pwd --force --admin-password $admin_pwd ``
or if I let it create random db/user/password
`` bench new-site $site_name --admin-password $admin_pwd ``
in both case it would ask/prompt for mysql root password
or
`` bench new-site $site_name --db-root-password $mysql_root_pass --admin-password $admin_pwd ``
then I pass mysql root password as argument so it won't prompt for it
or I can create an other user with CREATE USER privilege
`` bench new-site $site_name --db-root-username $user_can_create_user --db-root-password $special_user_pwd --admin-password $admin_pwd ``
Could you tell me how I could integrate safely one of this command inside a yunohost package install script?
[19:04:15] <thatoo> Well, that's fine, the pbm isn't here.
Let's say yunohost create a db, a user with same name and a db_pwd and we pass them to the bench command like that
`` db_name=ynh_app_setting_set --app=$app --key=db_name --value=$db_name ``
`` db_pwd=ynh_app_setting_set --app=$app --key=db_pw --value=$db_pwd ``
`` bench new-site $site_name --db-name $db_name --db-password $db_pwd --force --admin-password $admin_pwd ``
then bench command will still ask/prompt for mysql root password
[19:05:03] <Aleks (he/him/il/lui)> still would be nice to clarify wether or not you are using packaging v1 or v2, seeing the full code and the full log ...
[19:06:03] <Aleks (he/him/il/lui)> `db_pwd=ynh_app_setting_set --app=$app --key=db_pw --value=$db_pwd` < you are reading `db_pw` instead of `db_pwd`, which is most likely empty, and anyway if you are using packaging v2 you do not need to load the settings manually ...
[19:06:28] <thatoo> Well, that's fine, the pbm isn't here.
Let's say yunohost create a db, a user with same name and a db_pwd and we pass them to the bench command like that
`` db_name=ynh_app_setting_get --app=$app --key=db_name ``
`` db_pwd=ynh_app_setting_get --app=$app --key=db_pw  ``
`` bench new-site $site_name --db-name $db_name --db-password $db_pwd --force --admin-password $admin_pwd ``
then bench command will still ask/prompt for mysql root password
[19:07:30] <thatoo> sorry, I confuse, I modify from set to get (on previous message)
[19:09:54] <thatoo> let me show you
[19:10:17] <thatoo> https://aria.im/_matrix/media/v1/download/defis.info/avGLyXQdHwKonCZVrTQawzNT
[19:11:14] <Aleks (he/him/il/lui)> and you absolutely positive that the crendentials are correct and that such a DB indeed exist with the appropriate user and password also configured ...?
[19:11:21] <thatoo> or with passing the mysql root password it works like that
[19:11:23] <thatoo> https://aria.im/_matrix/media/v1/download/defis.info/qYwaxkTLmSRpOiNWkTVNkExh
[19:11:52] <thatoo> > <@Alekswag:matrix.org> and you absolutely positive that the crendentials are correct and that such a DB indeed exist with the appropriate user and password also configured ...?

yes and if it was not existing, then I would not need --force
[19:14:19] <Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[19:14:47] <thatoo> or I can let bench create db/user and db_pwd randomly but I thought it would be better if yunohost create them before so I use --force.
[19:15:02] <thatoo> https://aria.im/_matrix/media/v1/download/defis.info/UsYDZNaFuyAJLyoZdpKMizFK
[19:15:50] <thatoo> in that last case site_config.json shows me these credential : 
`` { ``
``  "db_name": "_5868ce4709c645d7", ``
``  "db_password": "AVs65q4Y4VBdnccO", ``
``  "db_type": "mariadb" ``
`` } ``
[19:16:23] <Aleks (he/him/il/lui)> yes yunohost should definitely create the DB itself, i can't see any reason why the software would like to create the DB itself, this just look like bad design because separation of concern is just a fundamental design pattern
[19:16:27] <thatoo> you warn me that was not an easy package to start with. Well I guess you were right :-)
[19:17:25] <thatoo> yeah, I found bench command quiet gloomy
[19:19:40] <thatoo> If there is a solution to this issue, then the next step ti to understand what `` bench setup production `` command does, taking care of nginx fail2ban and stuff... that should be taken care by yunohost of course..
[19:20:54] <thatoo> but I won't chalenge that if there is no solution about this db issue first
[19:22:29] <thatoo> If you want, I can share you my install script (simple bash install script, not yunohost script)
[19:29:25] <thatoo> and, just in case, here is the error I get if I try to launch the `` bench new-site `` command without CREATE USER privilege
[19:30:11] <thatoo> https://aria.im/_matrix/media/v1/download/defis.info/kxgkFspePwrkMwcSkgVMFfsu
[19:31:59] <thatoo> of course the user "DatabaseName" (same name as db) have all privilege on the db "DatabaseName" but don't have CREATE USER privilege.
[19:34:18] <thatoo> if you tell me there is no solution to solve this, I'll let go the idea of a dokos package.
[19:35:35] <Aleks (he/him/il/lui)> i don't know but i can just confirm that this sound like heresy, this program should not need to create the DB itself ..
[19:35:54] <Aleks (he/him/il/lui)> or maybe this tool is somethow precisely designed to create the DB, which we should not need because yunohost is supposed to handle this
[19:36:19] <Aleks (he/him/il/lui)> from the documentation: https://frappeframework.com/docs/user/en/bench/reference/new-site

>Create a new Frappe site. This operation creates a new folder under ./sites which will contain all the site information for the site and also creates a new database in your DBMS with all of Frappe's Modules and DocTypes installed.
>
>The site config, which can be found under ./sites/{site}/site_config.json maintains information about the site's state. For more information about it, checkout this guide.
[19:36:59] <Aleks (he/him/il/lui)> i'm not sure what it does more that generating the `site_config.json`, but if it's only doing this, we could write that `site_config.json` ourselves...
[19:41:26] <thatoo> Well, in the doc, it says 
> This operation creates a new folder under ./sites which will contain all the site information for the site __and also creates a new database in your DBMS with all of Frappe's Modules and DocTypes installed__
[19:42:13] <Aleks (he/him/il/lui)> yes, I don't know what these modules and doctypes are
[19:42:35] <Aleks (he/him/il/lui)> there is also the "--install-app" option, so it looks like maybe it does and doesn't do some things depending on the options
[19:42:46] <thatoo> > <@thatoo:defis.info> sent an image.

Unfortunatly, it does not only generate `` site_config.json `` as you can see in this screenshot
[19:42:49] <Aleks (he/him/il/lui)> i don't know, it just looks like a mess
[19:42:59] <nicofrand> > <@kayou:matrix.org> Well in fact there is indeed a small problem here
> https://github.com/YunoHost-Apps/kresus_ynh/blob/master/conf%2Fnginx.conf#L10

Could you open an issue then? I'll take a look. Thx
[19:43:19] <thatoo> the `` Updating DocTypes for frappe `` take some time, I'd say around 10 s
[19:45:06] <thatoo> Well the --install-app, I do it in a second command in my script because I wanted to deal first with this db issue but I'm stuck
[19:45:51] <Aleks (he/him/il/lui)> just ... forget about the DB stuff via `bench new-site` ... Try creating the `site_config.json` yourself ...
[19:45:57] <thatoo> I'm opening en issue on the frappe github asking not to force the need of CREATE USER privilege if the db/user and db_pwd had been created before
[19:46:11] <thatoo> > <@Alekswag:matrix.org> just ... forget about the DB stuff via `bench new-site` ... Try creating the `site_config.json` yourself ...

ok, I'll try that
[19:46:22] <Aleks (he/him/il/lui)> though i'm saying this but maybe the new-site thing does initialize the tables inside the DB so we're fucked
[19:46:39] <thatoo> I can check that
[19:46:47] <Aleks (he/him/il/lui)> tbh this is just fucked up, the application should not need the root mysql password, period
[19:48:41] <thatoo> it does initialize the db
[19:52:11] <Aleks (he/him/il/lui)> yes, that's what i'm saying, it should not need to create the DB, it's lack of separation of concerns, this is just like services trying to be like "i'm gonna handle the SSL certificate myself" like, yeah, nope
[20:01:28] <thatoo> Here is the issue I opened : https://github.com/frappe/frappe/issues/24016
[20:02:01] <thatoo> don't hesitate to comment of course.
[20:02:52] <thatoo> I'll stop trying to make a package for Dokos for now.
[20:02:54] <thatoo> Thank you <a data-mention-type="user" href="https://matrix.to/#/@Alekswag:matrix.org" contenteditable="false">Aleks (he/him/il/lui)</a> for your help and time.
[20:28:11] <Yunohost Git/Infra notifications> App 13ft stays at level 1 in job [#21749](https://ci-apps.yunohost.org/ci/job/21749)
[21:17:09] <Aleks (he/him/il/lui)> hmm i think you can go to https://github.com/settings/notifications and disable "Automatically watch repositories"
[21:20:29] <Yunohost Git/Infra notifications> App cryptpad goes down from level 8 to 1 in job [#21750](https://ci-apps.yunohost.org/ci/job/21750)
[21:25:54] <Aleks (he/him/il/lui)> ah there's another job already wtf 🤔
[21:33:57] <lapineige> > <@Alekswag:matrix.org> hmm i think you can go to https://github.com/settings/notifications and disable "Automatically watch repositories"

yeah but then I'll forget to do it on the repo I create 😅
[21:40:55] <Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-heimdall
[21:40:58] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-heimdall: Add Heimdall to wishlist ([8fd63841](https://github.com/YunoHost/apps/commit/8fd6384102486a8203657aecfda25ebbed039309))
[21:41:00] <Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1940](https://github.com/YunoHost/apps/pull/1940): Add Heimdall to wishlist
[21:49:36] <Yunohost Git/Infra notifications> App 13ft stays at level 1 in job [#21753](https://ci-apps.yunohost.org/ci/job/21753)
[21:57:53] <lapineige> I resign 🤣
[21:57:55] <lapineige> > you shouldn't have ^^

Yeah now I'm notified of every new repository creation and so on, please cancel this Aleks (he/him/il/lui): 😅😅😅
[21:57:56] <eric_G> lapineige: with power comes great responsibility. welcome to the club
[21:57:57] <Aleks (he/him/il/lui)> hmm i think you can go to https://github.com/settings/notifications and disable "Automatically watch repositories"
[21:58:02] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-heimdall: Add Heimdall to wishlist ([8fd63841](https://github.com/YunoHost/apps/commit/8fd6384102486a8203657aecfda25ebbed039309))
[21:58:02] <lapineige> > <@Alekswag:matrix.org> hmm i think you can go to https://github.com/settings/notifications and disable "Automatically watch repositories"

yeah but then I'll forget to do it on the repo I create 😅
[21:58:04] <Yunohost Git/Infra notifications> App cryptpad goes down from level 8 to 1 in job [#21750](https://ci-apps.yunohost.org/ci/job/21750)
[21:58:05] <Yunohost Git/Infra notifications> App 13ft stays at level 1 in job [#21753](https://ci-apps.yunohost.org/ci/job/21753)
[21:58:05] <Aleks (he/him/il/lui)> ah there's another job already wtf 🤔
[21:58:05] <Aleks (he/him/il/lui)> tmp network issue, relaunching
[21:58:24] <Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1940](https://github.com/YunoHost/apps/pull/1940): Add Heimdall to wishlist
[21:58:24] <Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-heimdall
[22:17:16] <Nadine> Hi,
I'm not yet familiar with defining YNH test cases. Can I define a test that installs the app on another port than the default port? If yes, how? My goal is to test upgrade and restore scripts if the app is installed on a non-default port. To give some more context. I'm talking about https://github.com/YunoHost-Apps/jenkins_ynh/pull/131 . Thanks.
[22:26:53] <Aleks (he/him/il/lui)> i'm not sure to understand why it matters wether or not the app is using the default port ...
[22:27:16] <Aleks (he/him/il/lui)> tried to read https://github.com/YunoHost-Apps/jenkins_ynh/issues/121 but still confused
[22:28:14] <Aleks (he/him/il/lui)> ah yeah seems related to https://github.com/YunoHost-Apps/jenkins_ynh/issues/108, great
[22:34:16] <Nadine> > <@Alekswag:matrix.org> ah yeah seems related to https://github.com/YunoHost-Apps/jenkins_ynh/issues/108, great

Right, any idea how to include this case in tests?
[22:35:39] <Aleks (he/him/il/lui)> still not clear what you mean by "this case"
[22:35:45] <Aleks (he/him/il/lui)> in some issue you mention that "your jenkins doesn't use port 8080" but that's expected because yunohost modifies the port jenkins is using apparently
[22:35:53] <Nadine> By "this case" I mean installation on another port than 8080. The problem in the issue is that upgrade and restore fail IF Jenkins runs on another port than 8080.
[22:36:34] <Aleks (he/him/il/lui)> if "it fails" then it would be nice to see what's the actual error message
[22:36:52] <Aleks (he/him/il/lui)> but in any case, as far I understand, jenkins .deb uses port 8080 by default, and then yunohost modifies it
[22:37:02] <Aleks (he/him/il/lui)> so the end state is always "the port used is not 8080"
[22:37:22] <Nadine> > <@Alekswag:matrix.org> if "it fails" then it would be nice to see what's the actual error message

The logs for that are all in the issue. The problem is that the port is only changed in install script, not in upgrade and restore scripts.
[22:37:30] <Aleks (he/him/il/lui)> which issue x_x
[22:37:49] <Nadine> > <@Alekswag:matrix.org> which issue x_x

https://github.com/YunoHost-Apps/jenkins_ynh/issues/121
[22:40:44] <Nadine> > The logs for that are all in the issue. The problem is that the port is only changed in install script, not in upgrade and restore scripts.

It fails because it tries to use default port 8080 again when upgrading / restoring although port 8080 is already in use. So, the fix is to check in upgrade and restore script if port 8080 is already in use and if yes, use another port. I included these fixes in my PR already. Just wondering if there is a way to test it in CI.
[22:45:45] <Aleks (he/him/il/lui)> then i don't understand how it can pass the regular "self upgrade" in the CI in the first place, i'm having a look ...
[22:46:54] <Aleks (he/him/il/lui)> ah it passes because no other program uses port 8080 at that time
[22:46:55] <Aleks (he/him/il/lui)> hmpf
[22:48:08] <Aleks (he/him/il/lui)> to me the appropriate fix would be to create a systemd override conf before the `dpkg -i`
[22:48:19] <Aleks (he/him/il/lui)> something like `/etc/systemd/system/jenkins.service.d/ynh-override.conf`
[22:48:54] <Aleks (he/him/il/lui)> containing something like

```
[Unit]
Environment="JENKINS_PORT=the_appropriate_port_number"
```
[22:49:00] <Aleks (he/him/il/lui)> that way it will never use the damn port 8080 in the first place
[22:49:13] <Aleks (he/him/il/lui)> we do this for other stuff in yunohost core, cf for example: https://github.com/YunoHost/yunohost/blob/dev/hooks/conf_regen/01-yunohost#L127
[23:03:42] <kayou> > <@kayou:matrix.org> I'll add a warning in package_linter

i tried to put my nose in the code but, god, i don't understand anything here
https://github.com/YunoHost/package_linter/blob/master/package_linter.py#L1442
[23:06:30] <Aleks (he/him/il/lui)> that's some "actual parsing" of the nginx conf, i don't know if we really want to use that, imho i would just add a simple grep ...
[23:07:01] <Aleks (he/him/il/lui)> or something like https://github.com/YunoHost/package_linter/blob/master/package_linter.py#L1442
[23:07:41] <Aleks (he/him/il/lui)> or like https://github.com/YunoHost/package_linter/blob/master/package_linter.py#L1442 (for the grep style)
[23:34:08] <kayou> Uuh that the same copy pasta
[23:34:19] <kayou> L1442 & L1442
[23:34:42] <kayou> But yeah, just a grep should be enough
[23:47:23] <Aleks (he/him/il/lui)> zbleuarg
[23:48:12] <Aleks (he/him/il/lui)> i meant line 1328 and 2548
[23:49:34] <Yunohost Git/Infra notifications> [package_linter] @kay0u created new branch nginx-check-regex-in-location-field
[23:49:36] <Yunohost Git/Infra notifications> [package_linter] @kay0u pushed 1 commit to nginx-check-regex-in-location-field: nginx check regex in location field ([5baae31c](https://github.com/YunoHost/package_linter/commit/5baae31c1fd54e73dc0ed47e3372bdaea37a27ee))
[23:49:53] <Yunohost Git/Infra notifications> [package_linter] @kay0u opened [pull request #124](https://github.com/YunoHost/package_linter/pull/124): nginx check regex in location field
[23:50:03] <Yunohost Git/Infra notifications> [package_linter] @kay0u edited [pull request #124](https://github.com/YunoHost/package_linter/pull/124): nginx check regex in location field
[23:52:37] <Yunohost Git/Infra notifications> [package_linter] @kay0u pushed 1 commit to nginx-check-regex-in-location-field: oupsie ([74d39d91](https://github.com/YunoHost/package_linter/commit/74d39d910c3a9dd0205daa6a914284869bb331e9))
[23:53:45] <Yunohost Git/Infra notifications> [package_linter] @kay0u edited [pull request #124](https://github.com/YunoHost/package_linter/pull/124): nginx check regex in location field