[00:31:27]
<Yunohost Git/Infra notifications> App cockpit goes down from level 8 to 6 in job [#18432](https://ci-apps.yunohost.org/ci/job/18432)
[05:55:24]
<Yunohost Git/Infra notifications> App jackett stays at level 1 in job [#18444](https://ci-apps.yunohost.org/ci/job/18444)
[10:48:00]
<Yunohost Git/Infra notifications> [wordpress_ynh] @ericgaspar pushed 1 commit to testing: Update manifest.toml ([ca4dbc0f](https://github.com/YunoHost-Apps/wordpress_ynh/commit/ca4dbc0f3dda7156743e3d664807ec66e438b479))
[10:48:26]
<Yunohost Git/Infra notifications> [wordpress_ynh] @ericgaspar [commented](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#issuecomment-1713636162) on [issue #228](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228) fix maintenance: testme
[10:48:28]
<Yunohost Git/Infra notifications> [wordpress_ynh] @yunohost-bot [commented](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#issuecomment-1713636224) on [issue #228](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228) fix maintenance: May the CI gods be with you
[[Test Badge](https://img.shields.io/endpoint?url=https://ci-apps-dev.yunohost.org/ci/api/...
[11:03:50]
<Yunohost Git/Infra notifications> [apps] @alexAubin approved [pull request #1727](https://github.com/YunoHost/apps/pull/1727#pullrequestreview-1619720131) Update app levels according to CI results
[11:05:05]
<Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to update_app_levels: Fix levels for concrete5 and dex ([99d06001](https://github.com/YunoHost/apps/commit/99d06001f0509e84181fb732e333addf7e283cb3))
[11:07:13]
<Yunohost Git/Infra notifications> [apps] @ericgaspar merged [pull request #1727](https://github.com/YunoHost/apps/pull/1727): Update app levels according to CI results
[11:07:17]
<Yunohost Git/Infra notifications> [apps/master] Fix headscale level - yalh76
[11:07:22]
<Yunohost Git/Infra notifications> [apps/master] Fix levels for concrete5 and dex - Alexandre Aubin
[11:07:29]
<Yunohost Git/Infra notifications> [apps/master] Merge pull request #1727 from YunoHost/update_app_levels Update app levels according to CI results - eric_G
[11:21:49]
<mrflos> is there a delay to expect for using yunohost ci bot for a PR ?
cf. https://github.com/YunoHost-Apps/yeswiki_ynh/pull/68
[11:25:18]
<orhtej2> > <@mrfloss:matrix.org> is there a delay to expect for using yunohost ci bot for a PR ?
> cf. https://github.com/YunoHost-Apps/yeswiki_ynh/pull/68
you need to be a member of YunoHost-Apps org to invoke CI bot
[11:26:27]
<mrflos> oh.. snif i thought i belonged to this club, i even showed them some of my nude pictures to get onboard...
[11:27:14]
<mrflos> but thanks anyway
[11:29:56]
<Aleks (he/him/il/lui)> you ain't in the yunohost-apps org ? unacceptable !
[11:30:03]
<Aleks (he/him/il/lui)> https://www.youtube.com/watch?v=brLNcJeSAhw
[11:31:06]
<Aleks (he/him/il/lui)> sent an invitation
[11:35:43]
<mrflos> thanks a lot Aleks (he/him/il/lui) , i promise to behave almost as if i were a nice person! 😄
[12:30:38]
<eric_G> do we have `allow_email=true` in manifest v2 documented somewhere?
[12:36:01]
<Thomas> https://yunohost.org/fr/packaging_apps_resources#system-user
[13:08:30]
<Tio> Guys maybe we can work on this a bit https://github.com/YunoHost-Apps/friendica_ynh/issues/111 ? I am willing to do any tests that need to be done. I will ask some more knowledgeable friends to have a look too. But basically Friendica's backup solution does not work for bigger instances and does not backup the files at all
[13:32:13]
<orhtej2> > <@tio:matrix.trom.tf> Guys maybe we can work on this a bit https://github.com/YunoHost-Apps/friendica_ynh/issues/111 ? I am willing to do any tests that need to be done. I will ask some more knowledgeable friends to have a look too. But basically Friendica's backup solution does not work for bigger instances and does not backup the files at all
was this ever brought up in context of Nextcloud? I'm asking because theoretically you can enter maintenance mode at the start of backup operation then exit maintenance mode in post-backup hook I guess. But this looks like a fragile pipeline
[13:32:37]
<orhtej2> (IDK if post-backup hooks are called if backup fails for example)
[13:33:30]
<orhtej2> > was this ever brought up in context of Nextcloud? I'm asking because theoretically you can enter maintenance mode at the start of backup operation then exit maintenance mode in post-backup hook I guess. But this looks like a fragile pipeline
ahh we already do that https://github.com/YunoHost-Apps/friendica_ynh/blob/7e5de9455362fb9f1740a1cb59148b6ff73aeae2/scripts/backup#L18
[13:33:44]
<orhtej2> is this still a problem with recent version?
[13:34:37]
<eric_G> maybe the backup script is not meant to be used for daily backup
[13:34:37]
<Tio> Like I mentioned in the issue this is what we tried to do. Currently it does not work but it must be an issue with the code for the backup script because I tested it with a more simplified code and works. However putting Friendica in maintenance mode can mean to have it unavailable for hours every day
[13:35:47]
<Tio> what do you mean?
[13:35:47]
<Tio> you mean to backup friendica once every other day?
[13:36:33]
<orhtej2> > <@tio:matrix.trom.tf> Like I mentioned in the issue this is what we tried to do. Currently it does not work but it must be an issue with the code for the backup script because I tested it with a more simplified code and works. However putting Friendica in maintenance mode can mean to have it unavailable for hours every day
do you have log files from such 'not working maintenance mode' attempt?
[13:36:42]
<Tio> > do you have log files from such 'not working maintenance mode' attempt?
Yes I put all in that issue
[13:37:42]
<Tio> https://paste.yunohost.org/raw/icukubaxiz
[14:01:58]
<orhtej2> > <@tio:matrix.trom.tf> https://paste.yunohost.org/raw/icukubaxiz
I mean due to script failing miserably it never exited maintenance mode, it run for ~15 minutes according to log. One thing that may cause DML on `post-delivery` table is cron job, perhaps that one needs to be temporarily disabled as well?
[14:03:09]
<Tio> but I monitored my instance and it was never into maintenance mode....
[14:03:09]
<orhtej2> > <@tio:matrix.trom.tf> but I monitored my instance and it was never into maintenance mode....
¯\_(ツ)_/¯
[14:03:17]
<Tio> we are also using a daemon and have disabled cron for friendica
[14:22:02]
<orhtej2> > <@tio:matrix.trom.tf> we are also using a daemon and have disabled cron for friendica
this one? https://github.com/YunoHost-Apps/friendica_ynh/blob/master/conf/cron
[14:23:26]
<Tio> yes for us this is commented out
[14:25:00]
<Tio> we use a daemon like here https://nequalsonelifestyle.com/2022/08/04/setting-up-friendica-daemon-systemd-service/
[14:37:41]
<eric_G> BTW, daemon branch needs to be fixed! https://github.com/YunoHost-Apps/friendica_ynh/tree/Daemon
[15:01:16]
<orhtej2> > <@tio:matrix.trom.tf> but I monitored my instance and it was never into maintenance mode....
ok, that I think I fixed, checking now: https://github.com/YunoHost-Apps/friendica_ynh/pull/112
[15:04:57]
<orhtej2> > ok, that I think I fixed, checking now: https://github.com/YunoHost-Apps/friendica_ynh/pull/112
fell flat on it's face due to cron config missing x_x https://paste.yunohost.org/raw/gaqaponote
[15:05:18]
<orhtej2> (but entered and exited maintenance, yay!)
[15:31:10]
<Yunohost Git/Infra notifications> App seafile failed all tests in job [#18454](https://ci-apps.yunohost.org/ci/job/18454) :(
[15:33:00]
<Tio> > <@ericg:matrix.org> BTW, daemon branch needs to be fixed! https://github.com/YunoHost-Apps/friendica_ynh/tree/Daemon
yes indeed. we did it manually tho and it works. as far as I understand you could not make the systemd process start
[15:33:40]
<Tio> > fell flat on it's face due to cron config missing x_x https://paste.yunohost.org/raw/gaqaponote
cant we ignore that file if it is not available?
[15:59:20]
<orhtej2> > fell flat on it's face due to cron config missing x_x https://paste.yunohost.org/raw/gaqaponote
Idk what was the rationale here https://github.com/YunoHost-Apps/friendica_ynh/blob/7e5de9455362fb9f1740a1cb59148b6ff73aeae2/scripts/upgrade#L30
[16:00:19]
<orhtej2> It is added during `install` then removed in `upgrade`
[16:04:57]
<eric_G> it is a left over from the daemon branch I guess
[16:28:10]
<Tio> testing looks good so far
[17:00:56]
<Tio> I wonder if there is a way to grab the filepath for where the files are stored for friendica. I mean it is with MariaDB `[friendica]> select * from config where cat like '%storage%'` but to integrate into the backup script so we backup the files too
[17:39:11]
<orhtej2> > <@tio:matrix.trom.tf> I wonder if there is a way to grab the filepath for where the files are stored for friendica. I mean it is with MariaDB `[friendica]> select * from config where cat like '%storage%'` but to integrate into the backup script so we backup the files too
How does one even restore from plain files afterwards?
[17:54:00]
<Tio> the files are stored like nextcloud stores files in another directory
[17:54:08]
<Tio> is exactly as that
[17:55:38]
<Tio> these files are simply images basically
[17:57:11]
<Tio> and you basically restore the folder like you would do for nextcloud, at the specified locaiton
[18:00:41]
<Tio> to make it clear these are the media files that people upload to friendica or are cached from my understanding
[18:16:01]
<Yunohost Git/Infra notifications> [gitlab_ynh] @Plumeros [commented](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229#issuecomment-1714364043) on [issue #229](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229) Error installingGitLab: I was waiting for about 4h, I think the installation should not take that long. Thanks for the hints, I will follow them...
[20:14:35]
<Yunohost Git/Infra notifications> [example_ynh] @Tagadda pushed 2 commits to master ([159a81468cc9...e6517305562c](https://github.com/YunoHost/example_ynh/compare/159a81468cc9...e6517305562c))
[20:14:41]
<Yunohost Git/Infra notifications> [example_ynh/master] Split comment lines to reduce the line length in manifest.toml and tests.toml - Félix Piédallu
[20:14:42]
<Yunohost Git/Infra notifications> [example_ynh/master] Merge pull request #212 from Salamandar/line_length Split comment lines to reduce the line length in manifest.toml and ... - Tagada
[20:16:10]
<Yunohost Git/Infra notifications> [package_linter] @Tagadda [commented](https://github.com/YunoHost/package_linter/pull/120#discussion_r1322028951) on pull request #120 Warn when the apt packages list is a string, not a list: suggestion yield Info(
[20:36:52]
<Émy - OniriCorpe> the CI returns me an error:
> Do not use 'add_header' in the NGINX conf. Use 'more_set_headers' instead. (See https://www.peterbe.com/plog/be-very-careful-with-your-add_header-in-nginx and https://github.com/openresty/headers-more-nginx-module#more_set_headers )
But ynh already handles the case, using an include in the "server" part of the domain name.
so normally I can use "add_header" without any problem
but the CI blocks me with a fatal error
[20:37:22]
<Émy - OniriCorpe> my code:
https://github.com/YunoHost-Apps/gotosocial_ynh/pull/101/files#diff-8e371ad49c2a106a2f6b14d3cb01445c4f7d5c3694f50892d95932b48f42671cR24-R39
[20:37:43]
<Émy - OniriCorpe> what do you think of this?
[20:38:03]
<orhtej2> > It is added during `install` then removed in `upgrade`
thanks for fixing eric_G
[20:38:29]
<orhtej2> > I mean due to script failing miserably it never exited maintenance mode, it run for ~15 minutes according to log. One thing that may cause DML on `post-delivery` table is cron job, perhaps that one needs to be temporarily disabled as well?
actually cron job respects maintenance mode when entered properly: https://github.com/friendica/friendica/blob/c6c4d93b3b90f92905cec4a3080ab1af6ae742bb/bin/worker.php#L71
[20:47:12]
<Tag> > <@oniricorpe:im.emelyne.eu> the CI returns me an error:
> > Do not use 'add_header' in the NGINX conf. Use 'more_set_headers' instead. (See https://www.peterbe.com/plog/be-very-careful-with-your-add_header-in-nginx and https://github.com/openresty/headers-more-nginx-module#more_set_headers )
>
> But ynh already handles the case, using an include in the "server" part of the domain name.
> so normally I can use "add_header" without any problem
> but the CI blocks me with a fatal error
If I understand correctly, you'll have to include this at server "level" and at each location "level" when you want to use add_header
[20:48:19]
<Tag> That's why the good practice is to use more_set_headers so we don't have to care about including this at every level
[20:48:49]
<Émy - OniriCorpe> yes, i tryied but it doesn't work :/
[20:49:06]
<Tag> wdym it doesn't work ? The headers are not set ?
[20:49:12]
<Émy - OniriCorpe> `more_set_headers "Cache-Control: public";` does not work
[20:49:17]
<Émy - OniriCorpe> yes
[20:55:27]
<Émy - OniriCorpe> with the `add_header Cache-Control "public";``:
```
HTTP/2 200
server: nginx
date: Mon, 11 Sep 2023 20:49:26 GMT
content-type: image/png
content-length: 27204
last-modified: Mon, 21 Aug 2023 15:34:40 GMT
x-sso-wat: You've just been SSOed
etag: "64e38410-6a44"
content-security-policy: upgrade-insecure-requests
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
permissions-policy: interest-cohort=()
strict-transport-security: max-age=63072000; includeSubDomains; preload
expires: Mon, 11 Sep 2023 20:54:26 GMT
cache-control: max-age=300
cache-control: public
accept-ranges: bytes
```
with `more_set_headers "Cache-Control: public";`:
```
HTTP/2 200
server: nginx
date: Mon, 11 Sep 2023 20:49:52 GMT
content-type: image/png
content-length: 27204
last-modified: Mon, 21 Aug 2023 15:34:40 GMT
x-sso-wat: You've just been SSOed
etag: "64e38410-6a44"
content-security-policy: upgrade-insecure-requests
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
permissions-policy: interest-cohort=()
strict-transport-security: max-age=63072000; includeSubDomains; preload
cache-control: max-age=300
expires: Mon, 11 Sep 2023 20:54:52 GMT
accept-ranges: bytes
```
The only difference is the missing `cache-control: public` with `more_set_headers`
[20:57:19]
<Tag> Mmmh looks like there's an issue with Cache-Control and more_set_headers somehow... I have this issue with at least another app (kresus)
[21:00:11]
<Tag> It's working for yunorunner_ynh https://github.com/YunoHost-Apps/yunorunner_ynh/blob/d3320d892e77f5d3f7007d6f46a2c074feeb787f/conf/nginx.conf#L23
[21:07:48]
<Émy - OniriCorpe> are you sure? i can't access https://ci-apps-dev.yunohost.org/summary/ to verify
[21:09:51]
<Tag> try https://ci-apps-dev.yunohost.org/ci/summary/9514.png
[21:13:53]
<Émy - OniriCorpe> hum it works yes
[21:14:05]
<Émy - OniriCorpe> ```
HTTP/2 200
server: nginx
date: Mon, 11 Sep 2023 21:13:16 GMT
content-type: image/png
content-length: 29866
last-modified: Mon, 11 Sep 2023 18:40:31 GMT
x-sso-wat: You've just been SSOed
content-security-policy: upgrade-insecure-requests
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-frame-options: SAMEORIGIN
permissions-policy: interest-cohort=()
strict-transport-security: max-age=63072000; includeSubDomains; preload
cache-control: max-age=300, s-maxage=300
accept-ranges: bytes
```
[21:16:32]
<Émy - OniriCorpe> If I put the exact same line (more\_set\_headers (`Cache-control: max-age=300, s-maxage=300";`) in my conf, it doesn't appear in my test requests
[21:19:03]
<Tag> Oh, can you try to move the 2 location blocks outside of the first one ?
[21:20:27]
<Émy - OniriCorpe> uhhh a friend helped me and it's a genius
[21:20:39]
<Tag> Oh!!!
[21:20:41]
<Émy - OniriCorpe> > AH ATTENDS j’ai peut-être une idée. Je pense que le max-age=300 viens de expires 5m; ligne 163. Si tu enleve cette ligne et que tu mets du more_set_header partout, je te parie une demie baguette que ça fonctionne
[21:20:46]
<Émy - OniriCorpe> and it works
[21:20:47]
<Émy - OniriCorpe> sigh
[21:21:07]
<Tag> grocervocosmic
[21:21:20]
<Émy - OniriCorpe> for non francophone ppl, I just commented the `expires 5m;` line and it works
[21:26:25]
<Émy - OniriCorpe> anyway, thank you Tag <3
[21:40:17]
<Yunohost Git/Infra notifications> [package_linter] @OniriCorpe opened [issue #123](https://github.com/YunoHost/package_linter/issues/123): bad_ynh_exec_syntax() false positive