[00:22:15]
<Yunohost Git/Infra notifications> App wordpress goes down from level 8 to 3 in job [#16499](https://ci-apps.yunohost.org/ci/job/16499)
[01:54:56]
<Yunohost Git/Infra notifications> App akkoma goes down from level 6 to 1 in job [#16501](https://ci-apps.yunohost.org/ci/job/16501)
[06:47:25]
<Yunohost Git/Infra notifications> App onlyoffice failed all tests in job [#16511](https://ci-apps.yunohost.org/ci/job/16511) :(
[07:27:48]
<Yunohost Git/Infra notifications> App wordpress failed all tests in job [#16499](https://ci-apps.yunohost.org/ci/job/16499) :(
[07:54:56]
<tituspijean> > <@yunohostinfra:matrix.org> App wordpress failed all tests in job [#16499](https://ci-apps.yunohost.org/ci/job/16499) :(
Sury issues like in the Support channel: https://github.com/oerdnj/deb.sury.org/issues/1980
[08:18:28]
<Yunohost Git/Infra notifications> App snweb failed all tests in job [#16515](https://ci-apps.yunohost.org/ci/job/16515) :(
[14:19:14]
<lapineige> In package V2, how can we set up the PHP user/group to use ?
Just as in https://github.com/YunoHost-Apps/pixelfed_ynh/blob/ebe6680ca7fbfa14423dc52591a8b307a170c4e5/conf/php-fpm.conf#L24
[14:22:40]
<lapineige> (Another example of brute force conversion to package v2 not beeing a good idea on packages that have an important history of various tweaks to make them work… and CI limitations to check that they actually work)
[14:28:10]
<Aleks (he/him/il/lui)> not sure to understand what you mean ... as far as I know, packaging v2 doesn't change anything w.r.t to how php confs are handled ...
[14:28:48]
<Aleks (he/him/il/lui)> though independently of packaging v2, we now encourage using the `--usage`/`--footprint` options of the php helpers to avoid having a huge php conf with 90% comments
[14:29:13]
<lapineige> Is that a good way to go ? https://github.com/YunoHost-Apps/pixelfed_ynh/pull/224/files#diff-8f2d268a76791d1c76e0ecf323e3609be1e73c9e6e384649712263392c3ad518
[14:29:43]
<Aleks (he/him/il/lui)> might be, yes, let me check the helper code in case there's an alternative to this
[14:30:04]
<lapineige> Well the (automated I guess ?) conversion eric_G made on the package removed all php-fpm.conf stuff except the 2 lines in php-extra-fpm.conf. So I suppose it changes something ?
[14:30:24]
<Aleks (he/him/il/lui)> maybe he just applied other recommendations from the linter in the same commit
[14:31:15]
<Aleks (he/him/il/lui)> anyway, indeed there's no way to tweak the group using the auto-generated php conf
[14:31:38]
<Aleks (he/him/il/lui)> i'm curious though why you'd need it to be www-data, does this trigger a specific bug/issue ?
[14:36:56]
<lapineige> Wanna read the (several months) longs threads linked to this ? https://github.com/YunoHost-Apps/pixelfed_ynh/pull/224 😁
[14:38:50]
<Aleks (he/him/il/lui)> hmf so the software creates folders with `700` permissions so www-data can't reach the content of folders ~_~
[14:38:53]
<Aleks (he/him/il/lui)> great
[14:40:31]
<lapineige> To summarize the mess: Pixelfed merged an hardcoded files&folders rights change in the code in version 0.11.5. Which is not compatible with Yunohost.
So I had to :
- fix buggy files created after the change
- change those hardcoded values
- set propers rights so we can use minimal rights (not 777), and proper php user so the process that handles files creation can leave them readable to the one serving file to NGINX and then final users
This was a huge mess to understand… and automated upgrade to v2 broke the fix.
Hopefully, it seems that this time the fix is easy (because the issue is understood this time *I think*).
[14:41:05]
<lapineige> Without the help of several pixelfed-savy people I wouldn't have even understand the issue…
[14:43:25]
<Yunohost Git/Infra notifications> [example_ynh] @ericgaspar closed [pull request #208](https://github.com/YunoHost/example_ynh/pull/208): extra_php-fpm.conf
[14:44:52]
<lapineige> *(It was not the case here, but a reminder to never merge a big but seemingly innocent change without a packager review and user testing… I'm not knowledgeable in this field so it was longer, but it took me months and some help to actually figure out what's at stake and what to look out for, this can't be guessed ^^)*
[14:45:35]
<Yunohost Git/Infra notifications> [example_ynh] @alexAubin commented [pull request #208](https://github.com/YunoHost/example_ynh/pull/208#pullrequestreview-1485129077) extra_php-fpm.conf: Eeeeeh this is a good change though bro Just ideally would like to improve the situation with the management of the f...
[14:55:10]
<lapineige> Off-topic question: is it planned to allow people to upgrade an app to a specific PR from the admin GUI, by using an URL ?
In some case it would be super handy not to have them rely on CLI to apply a testing upgrade that can fix their situation (yes, I thinking about that Pixelfed issue). This also reduce the barrier for testing
[14:56:43]
<Guillaume Bouzige> I think it is already the case, in the app catalog at the bottom of the page
[14:58:22]
<Aleks (he/him/il/lui)> hmmmm 1) i don't think anything is ever really "planned", everything happens only if people decide to actually implement them ... 2) i think there is maybe an issue about facilitating the upgrade to testing ... i'm usure if we really want to allow upgrading to random PR .. or at least no "advertising" them because people have a tendency to yolo-click buttons
[14:58:49]
<Aleks (he/him/il/lui)> but yes as the ticket in the bugtracker says, would be nice to be able to upgrade to testing (at least) without using the CLI
[15:25:43]
<lapineige> It could be hidden in the web admin
[15:25:43]
<lapineige> It's already a lot easier
[15:25:43]
<Aleks (he/him/il/lui)> yes, as usual the hard part is finding somebody with time, energy and knowledge to actually implement this
[15:25:43]
<lapineige> As long as I can teach someone where it is
[15:26:05]
<Aleks (he/him/il/lui)> So I resetted the bookworm CI, with 1 st job being succesful o/ https://ci-apps-bookworm.yunohost.org/ci/job/1
[15:26:42]
<Aleks (he/him/il/lui)> Will be adding bookworm to https://dash.yunohost.org/ to have the usual comparison "bullseye vs bookworm"
[16:40:09]
<lapineige> > <@Alekswag:matrix.org> yes, as usual the hard part is finding somebody with time, energy and knowledge to actually implement this
With some guidance I might volunteer :)
[16:41:03]
<lapineige> Basically it's exposing in the web admin a field that takes an URL as argument and then trigger `yunohost app upgrade -u URLgiven`, right ?
[16:41:25]
<lapineige> This would even fail if it's not a proper URL so that's a good failsafe
[16:41:39]
<lapineige> And if it's for testing only it's even easier
[16:42:44]
<Aleks (he/him/il/lui)> weeeell if you're familiar with VueJS, the app info view is here for example : https://github.com/YunoHost/yunohost-admin/blob/dev/app/src/views/app/AppInfo.vue
[16:43:32]
<Aleks (he/him/il/lui)> (btw just having a button "Upgrade" in this view when an upgrade is available for that app (compared to just having it in the upgrade view) would be cool)
[16:44:13]
<lapineige> > <@Alekswag:matrix.org> weeeell if you're familiar with VueJS, the app info view is here for example : https://github.com/YunoHost/yunohost-admin/blob/dev/app/src/views/app/AppInfo.vue
Oh yeah I forgot it's JS and not python 😂
I might try anyway ^^
[16:45:27]
<lapineige> > <@Alekswag:matrix.org> (btw just having a button "Upgrade" in this view when an upgrade is available for that app (compared to just having it in the upgrade view) would be cool)
It's also dangerous to automate it without user getting the proper PR status first. You might create a failing PR and user would upgrade right away before it's fixed
[16:46:16]
<Aleks (he/him/il/lui)> i mean a button for regular Upgrade
[16:47:25]
<lapineige> On the app view ?
[16:47:38]
<Aleks (he/him/il/lui)> yeah idk
[23:25:22]
<Yunohost Git/Infra notifications> App photonix failed all tests in job [#16525](https://ci-apps.yunohost.org/ci/job/16525) :(