[14:27:10]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin [commented](https://github.com/YunoHost/package_linter/pull/122#discussion_r1319140749) on pull request #122 Fixed (most) linter complaints.: yeah im not sure what the heck, but apparently in Python, both s = "\w" and s = "\\w" will result in the same strin...
[14:27:11]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin approved [pull request #122](https://github.com/YunoHost/package_linter/pull/122#pullrequestreview-1616273534) Fixed (most) linter complaints.
[14:27:11]
<Yunohost Git/Infra notifications> [package_linter/master] Merge pull request #122 from orhtej2/flake8 Fixed (most) linter complaints. - Alexandre Aubin
[14:27:11]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin merged [pull request #122](https://github.com/YunoHost/package_linter/pull/122): Fixed (most) linter complaints.
[14:27:11]
<Yunohost Git/Infra notifications> Job [#18344](https://ci-apps.yunohost.org/ci/job/18344) for calibreweb failed miserably :(
[14:27:11]
<Yunohost Git/Infra notifications> [package_linter/master] Fixed (most) linter complaints. - orhtej2
[14:27:11]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 2 commits to master ([b5b40510c973...cb892f1c4203](https://github.com/YunoHost/package_linter/compare/b5b40510c973...cb892f1c4203))
[14:27:12]
<Yunohost Git/Infra notifications> App dex goes down from level 8 to 2 in job [#18346](https://ci-apps.yunohost.org/ci/job/18346)
[14:27:12]
<Yunohost Git/Infra notifications> App concrete5 goes down from level 8 to 1 in job [#18345](https://ci-apps.yunohost.org/ci/job/18345)
[14:27:21]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1710532494) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: (Another thing waiting in the design decision was that toml auto-format creates that kinds of multi-line list : https://...
[14:27:22]
<Aleks (he/him/il/lui)> @room : it's contributor's meeting oclock o/ Feel free to ask us for a link that we'll share in DM if you wanna join
[14:27:22]
<Yunohost Git/Infra notifications> Job [#18344](https://ci-apps.yunohost.org/ci/job/18344) for calibreweb failed miserably :(
[14:27:22]
<Émy - OniriCorpe> > <@Alekswag:matrix.org> @room : it's contributor's meeting oclock o/ Feel free to ask us for a link that we'll share in DM if you wanna join
I would like the link ^w^
[14:27:22]
*Aleks (he/him/il/lui) realise que ci-apps-dev est à moitié pété depuis hier à cause de bugs dans le schema / linter x_x
[14:27:23]
<Yunohost Git/Infra notifications> [package_linter] @ewilly opened [issue #121](https://github.com/YunoHost/package_linter/issues/121): Manifest toml false positive in key resources > owner and group
[14:27:25]
<orhtej2> > Will do later
it's here: https://github.com/YunoHost/yunohost/pull/1710
[14:27:25]
<Aleks (he/him/il/lui)> Yologen be like 🪤
[14:27:39]
<Yunohost Git/Infra notifications> App my_capsule failed all tests in job [#18349](https://ci-apps.yunohost.org/ci/job/18349) :(
[14:27:43]
<Yunohost Git/Infra notifications> [apps] @tituspijean pushed 1 commit to tituspijean-patch-1: Searx is no longer maintained cf. https://github.com/searx/searx/commit/276ffd3f01cdd823f75676c51231fad4040059d3 ([54cad64a](https://github.com/YunoHost/apps/commit/54cad64a676e2c24b7a4ebb8f2e6298b25250bd7))
[14:27:43]
<Yunohost Git/Infra notifications> [apps] @tituspijean created new branch tituspijean-patch-1
[14:27:44]
<Yunohost Git/Infra notifications> [apps] @tituspijean opened [pull request #1726](https://github.com/YunoHost/apps/pull/1726): Searx is no longer maintained
[14:27:44]
<Yunohost Git/Infra notifications> Job [#18355](https://ci-apps.yunohost.org/ci/job/18355) for yeswiki failed miserably :(
[14:27:44]
<Yunohost Git/Infra notifications> App sutom goes down from level 8 to 6 in job [#18353](https://ci-apps.yunohost.org/ci/job/18353)
[14:27:44]
<Yunohost Git/Infra notifications> Job [#18354](https://ci-apps.yunohost.org/ci/job/18354) for uptime-kuma failed miserably :(
[14:27:45]
<12b> c’est la nouvelle release yeswiki qui a fait ça?
[14:27:45]
<12b> > <@yunohostinfra:matrix.org> Job [#18355](https://ci-apps.yunohost.org/ci/job/18355) for yeswiki failed miserably :(
mrflos:
[14:27:45]
<orhtej2> > c’est la nouvelle release yeswiki qui a fait ça?
https://github.com/YunoHost-Apps/yeswiki_ynh/blob/cca9ed8d5d263940396b07165db315570bc31f05/manifest.toml#L8 it got updated indeed, but no logs = no clue what went wrong
[14:27:46]
<orhtej2> (pardon my (lack of) french)
[14:27:46]
<Thomas> Is there a way to see yesterday's meeting pad? 😇
(I hope one day I will be able to be there!)
[14:27:46]
<tituspijean> Voici ! https://pad.pijean.ovh/pad/#/2/pad/view/r2lPbUQXE7ll4TRE-FAuBzw3sY-LT83jKpqOPGLKUvk/embed/ :)
[14:27:46]
<12b> my bad, I forgot this is an english speaking chanel
[14:27:46]
<orhtej2> > my bad, I forgot this is an english speaking chanel
no worries, I don't think there's any policy mandating one language over another
[14:27:46]
<mrflos> > c’est la nouvelle release yeswiki qui a fait ça?
While checking the tests on the PR , nothing was wrong, i suppose it was all fake news😝
[14:27:46]
<orhtej2> job seems to be passing now so likely some CI hiccup
[15:41:32]
<Aleks (he/him/il/lui)> a wild 12b and mrflos appearz
[15:42:04]
<Aleks (he/him/il/lui)> the test failed because of some lock glitch on the CI, nothing related to yeswiki, i yolo-restarted the job and it went okay
[15:42:10]
<Aleks (he/him/il/lui)> sorry for the fake news /o\
[17:00:47]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1727](https://github.com/YunoHost/apps/pull/1727): Update app levels according to CI results
[17:01:03]
<Yunohost Git/Infra notifications> [apps/update_app_levels] Add manifest URL in conversion script manifestv1 -> manifestv2 - Félix Piédallu
[17:01:09]
<Yunohost Git/Infra notifications> [apps/update_app_levels] Merge pull request #1725 from Salamandar/autopatch-schema Add schema URLs via autopatch and convert_app_to_manifestv2 - Alexandre Aubin
[17:01:11]
<Yunohost Git/Infra notifications> [apps/update_app_levels] Update app levels according to CI results - root
[17:24:37]
<Salamandar> > <@titus:pijean.ovh> I see Sal's suggesting to use schema checkers, but I'm wondering if we could have that on our infra. We already have webhooks monitoring the commits, so we could have a python script run the schema testers and use PyGithub to set a "checked" mark like Gitlab already does for apps.toml
IMHO linters have their place as github actions (on push), not on yunohost's infra (but yunohost CI is good on your inra)
[17:25:09]
<Yunohost Git/Infra notifications> [package_linter] @Salamandar [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1711999903) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: > (Another thing waiting in the design decision was that toml auto-format creates that kinds of multi-line list : https:...
[17:25:31]
<Yunohost Git/Infra notifications> [package_linter] @Salamandar [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1711999903) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: > (Another thing waiting in the design decision was that toml auto-format creates that kinds of multi-line list : https:...
[17:38:03]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> IMHO linters have their place as github actions (on push), not on yunohost's infra (but yunohost CI is good on your inra)
yeah we could definitely run the linter as github action ... the thing is that we have 600ish repo and there's basically no mechanism to configure CI stuff "en masse" for all repos, like, you're supposed to create the workflow files in every repo, and sooner or later we'll want to update them and then we have to push on every repo *again*
[17:39:42]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1712016674) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: Sure but is it really that big of a deal, we have more important stuff to work on imho ...
[17:40:50]
<Salamandar> Maybe this ? https://docs.github.com/en/actions/using-workflows/reusing-workflows
[17:42:22]
<Aleks (he/him/il/lui)> pretty sure you'll have to push some file to every repo anyway, and we wouldnt gain that much, we already run the linter inside yunorunner so
[17:42:42]
<Aleks (he/him/il/lui)> like sure we can have linter run on every commit but meh
[17:44:16]
<lapineige> The amount of spam can have backfire effects
[17:45:05]
<Aleks (he/him/il/lui)> ah yes, like uh, the failed github actions auto-updater for a bunch of apps which fail every day ... every morning i get like 6 emails because of these 😅
[17:45:36]
<Aleks (he/him/il/lui)> airsonic_ynh] Run failed: Check for new upstream releases hurr durr herp derp
[18:57:05]
<Yunohost Git/Infra notifications> [gitlab_ynh] @Plumeros [commented](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229#issuecomment-1712099216) on [issue #229](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229) Error installingGitLab: Hi, thanks for the answer. I just re-tried the installation which is easy on a virtual machine. The network issue persis...
[19:44:04]
<orhtej2> Anyone willing to take a look at https://github.com/YunoHost-Apps/cockpit_ynh/pull/21 ?
[19:44:19]
<Solrac> Hello, Sorry to bother again but I thin I
[19:56:59]
<Solrac> Hello, Sorry to bother again but I think I'm dealing with a permissions issue. The last CI indicates that the app doesn't have have write permission despite being chmod 644 (what motioneye does by default, tested on a debian vm) and even chmod 777, with or without chown. But speaking of chown, I believe that motioneye makes its own group and user (both called motion), and that's who owns the respective files and folders.
I guess the question I'm having is; should I follow what motioneye is doing or should I continue to try doing it the yunohost way? (chown $app:$app/www_data)
[19:57:10]
<Yunohost Git/Infra notifications> [gitlab_ynh] @Plumeros [commented](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229#issuecomment-1712158532) on [issue #229](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229) Error installingGitLab: The installation proceeded further. It was able to copy the pre-loaded file. But then the next issue occurs. See also ht...
[20:26:45]
<Yunohost Git/Infra notifications> [gitlab_ynh] @kay0u [commented](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229#issuecomment-1712185510) on [issue #229](https://github.com/YunoHost-Apps/gitlab_ynh/issues/229) Error installingGitLab: x86-64 should be ne pre-loaded file, not a folder where you put the file
[20:36:18]
<kayou> > <@Alekswag:matrix.org> ah yes, like uh, the failed github actions auto-updater for a bunch of apps which fail every day ... every morning i get like 6 emails because of these 😅
every time you make a commit in the Yunohost repo, I get an email about the success or failure of the CI tests :-°
[20:37:21]
<Aleks (he/him/il/lui)> 😬
[20:43:06]
<Yunohost Git/Infra notifications> [apps] @ericgaspar created new branch Froxlor
[20:43:07]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to Froxlor: Add Froxlor to catalog ([66123a2e](https://github.com/YunoHost/apps/commit/66123a2e26b3c89eb231827231d724235997743b))
[20:43:13]
<Yunohost Git/Infra notifications> [apps] @ericgaspar opened [pull request #1728](https://github.com/YunoHost/apps/pull/1728): Add Froxlor to catalog
[20:46:37]
<lapineige> > But speaking of chown, I believe that motioneye makes its own group and user (both called motion), and that's who owns the respective files and folders.
That's the Yunohost way too, for the user at least.
> I guess the question I'm having is; should I follow what motioneye is doing or should I continue to try doing it the yunohost way? (chown $app:$app/www_data)
As a first attempt, keep it has simple as possible for you. Then you will refine it 🙂
[20:53:15]
<Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1727](https://github.com/YunoHost/apps/pull/1727): Update app levels according to CI results
[20:53:32]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([1c792716](https://github.com/YunoHost/apps/commit/1c79271608bf11af18e974901d83e2aef80512f0))
[20:57:11]
<Solrac> > > But speaking of chown, I believe that motioneye makes its own group and user (both called motion), and that's who owns the respective files and folders.
>
> That's the Yunohost way too, for the user at least.
>
> > I guess the question I'm having is; should I follow what motioneye is doing or should I continue to try doing it the yunohost way? (chown $app:$app/www_data)
>
> As a first attempt, keep it has simple as possible for you. Then you will refine it 🙂
Aye, it is, but that's the small difference, the non-yunohost group that seems to be expected is "motion", while the app name is "motionEye" so they are not the same.
But following the keep it as simple makes me think maybe I should call the groups "motion" 🤔 So, I guess I'll try that
[20:59:03]
<lapineige> > the non-yunohost group that seems to be expected is "motion", while the app name is "motionEye" so they are not the same
Do you know why/where it is expected to be like this ?
Also I suppose the group could be the same name for all instances of the app motionEye (motionEye, motionEye__2, …). And in particular if there is no multi-instance support
[21:01:05]
<Solrac> > > the non-yunohost group that seems to be expected is "motion", while the app name is "motionEye" so they are not the same
>
> Do you know why/where it is expected to be like this ?
> Also I suppose the group could be the same name for all instances of the app motionEye (motionEye, motionEye__2, …). And in particular if there is no multi-instance support
Multi-instance seems to be a bit common in the docker setup. But usually, the idea is to use another instance's (in the home network) camera's in the main instance
[21:01:23]
<Yunohost Git/Infra notifications> [apps] @ericgaspar approved [pull request #1726](https://github.com/YunoHost/apps/pull/1726#pullrequestreview-1618263564) Searx is no longer maintained
[21:01:30]
<lapineige> You could also restrict it to single instance for now
[21:02:57]
<Yunohost Git/Infra notifications> [apps] @ericgaspar merged [pull request #1726](https://github.com/YunoHost/apps/pull/1726): Searx is no longer maintained
[21:02:57]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 2 commits to master ([b3ba5b3ba4b4...fcdaf0f0cd5a](https://github.com/YunoHost/apps/compare/b3ba5b3ba4b4...fcdaf0f0cd5a))
[21:02:57]
<Yunohost Git/Infra notifications> [apps/master] Searx is no longer maintained cf. https://github.com/searx/searx/commit/276ffd3f01cdd823f75676c51231fad4040059d3 - tituspijean
[21:02:57]
<Yunohost Git/Infra notifications> [apps] @ericgaspar deleted branch tituspijean-patch-1
[21:02:57]
<Yunohost Git/Infra notifications> [apps/master] Merge pull request #1726 from YunoHost/tituspijean-patch-1 Searx is no longer maintained - eric_G
[21:03:02]
<lapineige> In my view, anything that helps you finish a minimum viable package as soon as possible, to keep some motivation, is good to take. You'll have time to refine it later. Or not, and someone else will do it. Or not, and *some package* will be available instead of none 🙂
[21:13:03]
<Yunohost Git/Infra notifications> [test_apps] @kay0u pushed 1 commit to master: add 11p2 backups ([92d98f30](https://github.com/YunoHost/test_apps/commit/92d98f3097007cfdb1508f6c3e2494e4c231311b))
[21:24:39]
<lapineige> And trust me : it's a lot easier to refactor some tiny bits (even more if you documented the choices ;) ) than to make a while new package :)