[01:43:35]
<Yunohost Git/Infra notifications> App internetarchive failed all tests in job [#16972](https://ci-apps.yunohost.org/ci/job/16972) :(
[02:15:56]
<Yunohost Git/Infra notifications> App jackett stays at level 1 in job [#16974](https://ci-apps.yunohost.org/ci/job/16974)
[05:25:09]
<Yunohost Git/Infra notifications> App radicale failed all tests in job [#16979](https://ci-apps.yunohost.org/ci/job/16979) :(
[06:01:21]
<Yunohost Git/Infra notifications> App wekan failed all tests in job [#16981](https://ci-apps.yunohost.org/ci/job/16981) :(
[10:39:49]
<orhtej2> Is patching as easy with packaging v1? A matter of supplying a .diff in `sources/whatever` folder?
[10:42:09]
<tituspijean> Something like this indeed, if you look for "patches" in our YunoHost-Apps org on github, you'll have plenty examples
[13:36:50]
<tituspijean> Aleks (he/him/il/lui) cf. https://github.com/YunoHost-Apps/directorylister_ynh/issues/2, I don't think a password is assigned to system users when adding them to the ssh.app and sftp.app groups, right? Do we need to set one ourselves? (relevant core code: https://github.com/YunoHost/yunohost/blob/19eb48b6e73267685e1417122ac47908c1cf2472/src/utils/resources.py#L732)
[13:37:07]
<tituspijean> (and ping eric_G too, since you packaged the app 😇)
[13:41:13]
<Aleks (he/him/il/lui)> ah yes probably
[13:41:20]
<Aleks (he/him/il/lui)> i mean similar to my_webapp probably ?
[13:41:43]
<Aleks (he/him/il/lui)> https://github.com/YunoHost-Apps/my_webapp_ynh/blob/master/scripts/install#L87
[13:42:50]
<Aleks (he/him/il/lui)> hmm it's weird that there's a call to `ynh_system_user_create` beforehand, that part should be handled by the manifest/resources ?
[13:43:22]
<Aleks (he/him/il/lui)> ah the group membership is like, conditional
[13:43:22]
<Aleks (he/him/il/lui)> hmpf
[13:52:46]
<tituspijean> yup 🙃
[14:49:34]
<Aleks (he/him/il/lui)> or we could always configure SFTP enabled but only advertise it when needed or idk
[14:50:01]
<Aleks (he/him/il/lui)> like why make it optional if there's no cost in enabling it 🤔
[15:15:05]
<tituspijean> I'd say limit the attack surface? 😲
[15:15:51]
<Aleks (he/him/il/lui)> yeah a bit, though it's not like bots are going to bruteforce the SFTP password etc i guess
[15:17:00]
<tituspijean> they will get caught by fail2ban eventually, but it does not help that the usernames are predictable (my_webapp, my_webapp__2, etc.)
[15:17:24]
<Aleks (he/him/il/lui)> yeah
[19:58:50]
<orhtej2> I created [the following action](https://gist.github.com/orhtej2/9b398451db2adada7112304a6db49b28) to automatically tag mainline commits. Useful? Submit it for example_ynh?
[20:18:16]
<Aleks (he/him/il/lui)> not sure i understand
[20:18:26]
<Aleks (he/him/il/lui)> you mean creating a tag automatically when the version in manifest.json changes ?
[20:19:01]
<orhtej2> > <@Alekswag:matrix.org> you mean creating a tag automatically when the version in manifest.json changes ?
More or less yes
[20:19:53]
<orhtej2> So if someone has problem upgrading from version x you should have tag vX-ynhY ready
[20:20:34]
<Aleks (he/him/il/lui)> 🤔
[20:21:01]
<Aleks (he/him/il/lui)> not sure to understand the flow ... why would a tag existing or not help somebody with a failing upgrade ?
[20:22:11]
<orhtej2> > <@Alekswag:matrix.org> not sure to understand the flow ... why would a tag existing or not help somebody with a failing upgrade ?
It helps me find version someone is running, it's meant for maintainers rather than users
[20:24:29]
<Aleks (he/him/il/lui)> you mean because otherwise you have to manually search in the commit history the code for which commit corresponds to version X~ynhY because it's only in the manifest and not an actual tag ?
[20:32:29]
<Aleks (he/him/il/lui)> in that case that makes perfect sense 😅 but i would more imagine a "global" / "centralized" webhook similar to the README-generator because otherwise adding a github flow to every 450+ repo is going to be a mess, and even more messy when we'll need to update it on every 450+ repo (which one day or another is going to happen)
[20:33:11]
<Aleks (he/him/il/lui)> so maybe something in https://github.com/YunoHost/apps/tree/master/tools/README-generator that would push the tag from yunohost-bot everytime some commit is pushed to master/main/whichever prod branch, and the tag doesn't already exist
[20:39:52]
<orhtej2> > <@Alekswag:matrix.org> you mean because otherwise you have to manually search in the commit history the code for which commit corresponds to version X~ynhY because it's only in the manifest and not an actual tag ?
Precisely
[20:40:37]
<orhtej2> > <@Alekswag:matrix.org> [so maybe somet](https://github.com/YunoHost/apps/tree/master/tools/README-generator)
Oooh, did not know this was a thing, will adjust accordingly
[20:43:11]
<Aleks (he/him/il/lui)> to be validated with the rest of the app team if this is really what we want tho 😛 But additionally that could also help to spot apps for which it was forgotten to update the version in manifest despite new important commit (because in turn this means the changes are not advertised as update for the actual admins because the version did not change)
[20:43:45]
<Aleks (he/him/il/lui)> though the hard part is distinguishing between not-so-important-commits (ie just fixing typos) and actually-important-stuff like fixing a bug in the scripts
[20:44:43]
<Aleks (he/him/il/lui)> (but maybe that's me seeing too far too fast again 😅)