[01:54:22]
<Yunohost Git/Infra notifications> Job [#14993](https://ci-apps.yunohost.org/ci/job/14993) for etherpad_mypads failed miserably :(
[02:08:12]
<Yunohost Git/Infra notifications> App akkoma failed all tests in job [#15194](https://ci-apps.yunohost.org/ci/job/15194) :(
[02:32:04]
<Yunohost Git/Infra notifications> App rportd rises from level 7 to 8 in job [#15205](https://ci-apps.yunohost.org/ci/job/15205) !
[02:39:34]
<Yunohost Git/Infra notifications> App emailpoubelle rises from level 2 to 6 in job [#15260](https://ci-apps.yunohost.org/ci/job/15260) !
[05:11:18]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @tomdereub opened [issue #569](https://github.com/YunoHost-Apps/nextcloud_ynh/issues/569): Connection with email address proposed, but doesnt work
[07:16:11]
<lapineige> > pass NPM pass to the command ?
It fails.
[07:17:17]
<lapineige> Does anyone have an idea on how to fix this ? https://forum.yunohost.org/t/pixelfed-pictures-not-loading/24244/34
TL;DR : in Pixelfed, new folders created by the app are owned by pixelfed:pixelfed, instead of pixelfed:www-data.
How can we change that ?
[07:52:20]
<orhtej2> as per [the best docs](https://github.com/YunoHost/yunohost/blob/dev/helpers/nodejs#L28) you should run `$ynh_node_load_PATH $final_path/script_that_use_npm.sh` or likely in your case `$ynh_node_load_PATH just js-deps-get`
[07:53:51]
<orhtej2> or even more likely `ynh_exec_as $app $ynh_node_load_PATH just js-deps-get`
[08:30:38]
<Yunohost Git/Infra notifications> App lufi rises from level 6 to 8 in job [#15278](https://ci-apps.yunohost.org/ci/job/15278) !
[09:29:47]
<lapineige> > Does anyone have an idea on how to fix this ? https://forum.yunohost.org/t/pixelfed-pictures-not-loading/24244/34
> TL;DR : in Pixelfed, new folders created by the app are owned by pixelfed:pixelfed, instead of pixelfed:www-data.
> How can we change that ?
Is it safe to change /var/www/pixelfed owner to be www-data ?
That's the proposed solution...
[09:56:09]
<lapineige> > or even more likely `ynh_exec_as $app $ynh_node_load_PATH just js-deps-get`
I don't run just js-deps-get by the way. I'll try for other just commands
[10:23:25]
<lapineige> Also if I need to patch all files (but not directories) permissions in a dir sub-dirs, is there a safe way to do that only for upgrade comming from 2 specific versions ?
The upgrade script seems to do things like that but I'm usure about how to reproduce it *and* check any version between 0.11.5 and 0.11.6~ynh*1*
[10:55:00]
<orhtej2> > I don't run just js-deps-get by the way. I'll try for other just commands
BTW this daemon-launch at the end of `install` is wrong, you need proper `systemd` integration
[11:01:31]
<lapineige> Oh yes good point.
I did it the simple way to check if that would work with as few complexity as possible.
[11:01:52]
<lapineige> Do you mean it won't work at all, or just that's it's bad practice ?
[12:02:35]
<orhtej2> > Do you mean it won't work at all, or just that's it's bad practice ?
It will not start up again if system ever reboots so I'd say it's incorrect
[12:26:02]
<lapineige> Ok so that's fine for me right now
[12:30:57]
<lapineige> My goal is to have a basic working software (in CI at least) with the simplest test scenario. Making a fully featured working app will come next. It's already difficult enough ^^
[13:50:18]
<Guillaume Bouzige> hello, I am doing some testing on fresh yunohost install on a VPS server and I have those errors ```./15-nginx: line 145: $1: unbound variable
Could not run script: /usr/share/yunohost/hooks/conf_regen/15-nginx
./19-postfix: line 71: $1: unbound variable
Could not run script: /usr/share/yunohost/hooks/conf_regen/19-postfix```
[13:51:28]
<Aleks (he/him/il/lui)> can you share the full log
[13:51:46]
<Guillaume Bouzige> this is the install script I am testing https://github.com/YunoHost-Apps/cryptpad_ynh/blob/autoupdate/scripts/install and there is nothing regarding those hooks
[13:52:18]
<Guillaume Bouzige> the install is finished now, how can I get the full log ?
[13:53:14]
<Aleks (he/him/il/lui)> i dunno, cant you scroll the terminal ?
[13:53:15]
<Guillaume Bouzige> I got it
[13:53:32]
<Guillaume Bouzige> https://paste.yunohost.org/raw/kowumodeva
[13:54:17]
<Guillaume Bouzige> I see it is just after the infamous ` yunohost domain add sandbox-docs.maindomain.tld`
[13:57:04]
<Aleks (he/him/il/lui)> meh i dont understand why it would say $1 aint defined
[13:57:19]
<Guillaume Bouzige> but yeah it is in yellow so it is just a warning...no
[13:57:20]
<Aleks (he/him/il/lui)> or at least why it would only bug in that case and we would never see that kind of issue otherwise
[13:57:56]
<Aleks (he/him/il/lui)> ah yeah the legend of "It's just a warning so you can ignore it" 😅
[13:58:20]
<Guillaume Bouzige> ahahah yeah that is the one
[13:58:38]
<Aleks (he/him/il/lui)> Warning = you should carefully read it and decide wether or not it's important in your case
[13:59:02]
<Guillaume Bouzige> yeah I agree
[13:59:22]
<Guillaume Bouzige> just to mention the app went into the install and seems to work nicely...
[13:59:28]
<Aleks (he/him/il/lui)> and in that case the regen conf crashes so the domain you're trying to add will definitely not work properly
[13:59:50]
<Guillaume Bouzige> ah yeah ? I did generate the certificate for it tho
[14:00:35]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[14:00:44]
<Guillaume Bouzige> weird...
[14:02:21]
<Guillaume Bouzige> I will report more if there is more issues
[14:03:09]
<Aleks (he/him/il/lui)> if you have access to the webadmin, you should be able to find the detailed log for the regen conf by going to Tools > Logs > the install attempt > the "sub logs" thing at the top should list child operations including the regen conf
[14:04:20]
<Guillaume Bouzige> who so many logs so cool
[14:05:27]
<Guillaume Bouzige> this one it must be https://paste.yunohost.org/raw/javunaqate
[14:06:35]
<Guillaume Bouzige> at least I can see the postfix regen error
[14:08:07]
<Guillaume Bouzige> and here is the one for nginx regen error https://paste.yunohost.org/raw/saluyiyaji
[14:13:12]
<Aleks (he/him/il/lui)> hmyeah idk it looks like a bug in the core, in some legit case the regen conf hook is called with empty arg, which translates into "missing arg" at some point and boom
[14:14:19]
<Aleks (he/him/il/lui)> but i'm confused that we didn't see that error more often
[14:15:41]
<Guillaume Bouzige> well I saw it, even it was just a warning
[14:17:32]
<Guillaume Bouzige> to be honest, I would might have not reported it since it doesnt block anything at all, like silent bugs...
[14:20:19]
<Aleks (he/him/il/lui)> well yeah but warnings are not stuff to blindly ignore, they exist for a reason, and in some cases are symptomatic of larger issues which one way or another will pop up to the surface in a more explosive fashion ...
[14:20:57]
<Guillaume Bouzige> 😅
[14:20:57]
<Guillaume Bouzige> I know I know...that is why I am here now at the end
[14:22:18]
<Aleks (he/him/il/lui)> anyway, thanks for the report, i'll push a fix in the core ;P
[14:23:50]
<Guillaume Bouzige> thanks for the fix
[14:27:15]
<Aleks (he/him/il/lui)> aaah i might have an idea as to why we only see this happening now ?
[14:27:40]
<Guillaume Bouzige> tell me tell me
[14:29:01]
<Aleks (he/him/il/lui)> are you in packaging v2 context ?
[14:29:09]
<Guillaume Bouzige> I think so yes
[14:29:52]
<Aleks (he/him/il/lui)> so what's confusing is that here https://github.com/YunoHost/yunohost/blob/dev/hooks/conf_regen/15-nginx#L3
[14:30:13]
<Aleks (he/him/il/lui)> we only set `set -e`, such that the script crashes if a command fail (which is not bash's default ...)
[14:30:34]
<Guillaume Bouzige> yes
[14:30:46]
<Aleks (he/him/il/lui)> *but* that doesn't mean that `foo=$1` will crash if `$1` is not set, this only happens if you define `set -u` too, which triggers an error when using undefined variable
[14:30:47]
<Aleks (he/him/il/lui)> but
[14:30:49]
<Yunohost Git/Infra notifications> Job [#15286](https://ci-apps.yunohost.org/ci/job/15286) for jenkins failed miserably :(
[14:31:01]
<Aleks (he/him/il/lui)> we also call `. /usr/share/yunohost/helpers` right after
[14:32:15]
<Aleks (he/him/il/lui)> which in the past did not trigger the `set -eu` thing, but now it does for packaging v2 apps : https://github.com/YunoHost/yunohost/blob/dev/helpers/utils#L61-L71
[14:32:27]
<Guillaume Bouzige> aahh I see
[14:32:48]
<Guillaume Bouzige> that could be probematic indeed
[14:33:14]
<Aleks (he/him/il/lui)> but this behavior is based on the fact that `$YNH_APP_PACKAGING_FORMAT` should be set to 2 (or higher) which is not expected to happen in the regen-conf context because the regen-conf is something handled by the core and somewhat independant of apps
[14:33:20]
<Aleks (he/him/il/lui)> but
[14:33:33]
<Aleks (he/him/il/lui)> my guess is that somehow it's defined in your install script, and it's forwarded to the `yunohost add domain` command and forwarded again to the regen conf script
[14:33:59]
<Aleks (he/him/il/lui)> and therefore it sets `set -eu`
[14:34:15]
<Aleks (he/him/il/lui)> so that's why it's new because to get this you need to call a yunohost command which will trigger a regen-conf .. in a packaging v2 context
[14:34:42]
<Aleks (he/him/il/lui)> but it's somewhat worrying because so far the script were not designed with the `set -u` constrain ... so that may trigger bigger issues
[14:34:54]
<Guillaume Bouzige> I am looking into the install script to see if I found something
[14:35:42]
<Guillaume Bouzige> there is not `set -eu` in it
[14:41:10]
<Aleks (he/him/il/lui)> yes because it's automatically set by https://github.com/YunoHost/yunohost/blob/dev/helpers/utils#L61-L71
[14:44:02]
<Aleks (he/him/il/lui)> yeah nevermind it's hella confusing if you ain't familiar with the way helpers are loaded etc 😅
[14:45:21]
<Guillaume Bouzige> confusion there is but learning path is the way to go
[14:54:04]
<Yunohost Git/Infra notifications> App libreto stays at level 2 in job [#15287](https://ci-apps.yunohost.org/ci/job/15287)
[14:58:57]
<Yunohost Git/Infra notifications> App pmwiki failed all tests in job [#15307](https://ci-apps.yunohost.org/ci/job/15307) :(
[15:10:21]
<Aleks (he/him/il/lui)> should be fixed by https://github.com/YunoHost/yunohost/commit/a7350a7eae0b6e6208ff86590bd256ffe576f13c
[15:12:23]
<Guillaume Bouzige> I am trying to keep some value in config file during upgrade of an app (cryptpad) but I am not sure I am doing it right, do you have an idea ? https://github.com/YunoHost-Apps/cryptpad_ynh/blob/ffc722b90157fab97c0cc4a81d50911663aea0d2/scripts/upgrade#L125-L131
[15:13:02]
<Guillaume Bouzige> I have just try to test this branch but no success...I don't see the variable I was trying to echo
[15:13:18]
<Aleks (he/him/il/lui)> the full logs 😬
[15:16:27]
<Guillaume Bouzige> https://paste.yunohost.org/raw/akowiwepoj
[15:18:39]
<Aleks (he/him/il/lui)> so hm yeah it reads empty string for the first one and `[` for the second one
[15:19:13]
<Aleks (he/him/il/lui)> ah yeah adminKeys is a list
[15:19:14]
<Guillaume Bouzige> I also noticed that the install script detect that the conf was modified and keep it somewhere...
[15:19:31]
<Guillaume Bouzige> yeah both are I guess
[15:19:34]
<Aleks (he/him/il/lui)> `supportMailboxPublicKey` seems to be legit empty string
[15:19:44]
<Aleks (he/him/il/lui)> i mean that's the default value in https://github.com/YunoHost-Apps/cryptpad_ynh/blob/ffc722b90157fab97c0cc4a81d50911663aea0d2/conf/config.js
[15:20:13]
<Guillaume Bouzige> yeah this one is empty is normal for now
[15:20:48]
<Aleks (he/him/il/lui)> reading lists using the ynh_read_var_thing helper aint trivial i think x_x
[15:21:31]
<Guillaume Bouzige> arf...is it not common to have some conf you wanna keep when you upgrade an app ?
[15:26:21]
<Aleks (he/him/il/lui)> i think it is, but i dunno how people usually handle this :P
[15:32:54]
<Guillaume Bouzige> there must be a way to do it right
[15:33:45]
<Aleks (he/him/il/lui)> the hard part here is the fact that you want to read a list, and it's inside a .js file (things would be easier with a .yml or more common format which can be parsed easily)
[15:34:57]
<Guillaume Bouzige> it is kind of js standard...
[15:35:37]
<Guillaume Bouzige> lolilol
[15:37:05]
<Guillaume Bouzige> anyway I am looking for solutions and ways to do this so I am open for advices
[16:18:27]
<Aleks (he/him/il/lui)> yeah unfortunately there's no simple, standard way of doing this ...
[16:19:11]
<Aleks (he/him/il/lui)> i mean ultimately if you really want a real "clean" way, you want some sort of merge mechanism that would keep every existing setting but add whatever new setting defined by the upstream
[16:19:59]
<Aleks (he/him/il/lui)> one way of achieving this would be to have every setting being a yunohost-handled app setting, and have a way to regenerate the entire conf file from those settings
[16:20:32]
<Aleks (he/him/il/lui)> but it's kinda cumbersome
[16:21:14]
<Aleks (he/him/il/lui)> (and it doesnt solve some questions such as "what if the user manually edit the app's conf file" ...)
[16:56:43]
<Guillaume Bouzige> > <@Alekswag:matrix.org> one way of achieving this would be to have every setting being a yunohost-handled app setting, and have a way to regenerate the entire conf file from those settings
it is cumbersome
[16:56:56]
<Aleks (he/him/il/lui)> yup
[16:57:13]
<Guillaume Bouzige> > <@Alekswag:matrix.org> yeah unfortunately there's no simple, standard way of doing this ...
a 'just working' way could do
[17:38:04]
<lapineige> > Is it safe to change /var/www/pixelfed owner to be www-data ?
> That's the proposed solution...
https://github.com/YunoHost-Apps/pixelfed_ynh/issues/211?notification_referrer_id=NT_kwDOAH93qLI2MjM1MzYyNjk1OjgzNTM3MDQ#issuecomment-1535026590
Do you have any recommendation about this matter ?
Can we make sure pixelfed PHP process create files with www-data as group owner ?
[17:44:59]
<Aleks (he/him/il/lui)> maybe changing the `group =` statement here : https://github.com/YunoHost/yunohost/blob/dev/helpers/php#L164
[17:45:21]
<Aleks (he/him/il/lui)> or rather here : https://github.com/YunoHost-Apps/pixelfed_ynh/blob/master/conf/php-fpm.conf#L24
[21:41:26]
<lapineige> So the package linter is unhappy 😂
> ✘ DO NOT run the app PHP worker as root or www-data! Use a dedicated system user for this app!
[21:41:35]
<lapineige> So the package linter is unhappy 😂
> ✘ DO NOT run the app PHP worker as root or www-data! Use a dedicated system user for this app!
(but it's only the group)
[21:45:54]
<Aleks (he/him/il/lui)> qh yes
[21:45:56]
<Aleks (he/him/il/lui)> hmm
[21:46:46]
<Aleks (he/him/il/lui)> well i guess Group = "www-data" is legit
[21:47:18]
<Aleks (he/him/il/lui)> let's remove the check as it was probably meant to force people to replace both values in legacy apps
[21:47:53]
<lapineige> maybe it could check for user only ?
[21:47:56]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin created new branch alexAubin-patch-1
[21:47:56]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 1 commit to alexAubin-patch-1: having group = www-data is a legit use case in php conf ([8fe93728](https://github.com/YunoHost/package_linter/commit/8fe93728bf24b7dc326b91f53114d4ad9900ec7b))
[21:47:58]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin opened [pull request #112](https://github.com/YunoHost/package_linter/pull/112): having group = www-data is a legit use case in php conf
[21:48:04]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin merged [pull request #112](https://github.com/YunoHost/package_linter/pull/112): having group = www-data is a legit use case in php conf
[21:48:05]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 2 commits to master ([e5b29238b225...5c6da773a2f0](https://github.com/YunoHost/package_linter/compare/e5b29238b225...5c6da773a2f0))
[21:48:08]
<Yunohost Git/Infra notifications> [package_linter/master] having group = www-data is a legit use case in php conf - Alexandre Aubin
[21:48:09]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin deleted branch alexAubin-patch-1
[21:48:09]
<Aleks (he/him/il/lui)> yup, cf ^
[21:48:11]
<Yunohost Git/Infra notifications> [package_linter/master] Merge pull request #112 from YunoHost/alexAubin-patch-1 having group = www-data is a legit use case in php conf - Alexandre Aubin
[21:48:24]
<lapineige> oh you mean it's 2 checks and you can remove one ?
[21:48:30]
<Aleks (he/him/il/lui)> yup
[21:48:39]
<Aleks (he/him/il/lui)> well it was a regex
[21:48:42]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/package_linter/pull/112/files
[21:57:11]
<Yunohost Git/Infra notifications> Job [#15352](https://ci-apps.yunohost.org/ci/job/15352) for ampache failed miserably :(
[22:10:39]
<lapineige> I guess I should not rerun the CI ?
[22:14:58]
<Aleks (he/him/il/lui)> nah it's ok