[00:02:18]
<Aleks (he/him/il/lui)> https://mstdn.social/@tofeo/110697325041681086 , YunoHost, ce complot illuminati pour déposseder les admins du contrôle de leur serveur avec des mails qui t'expliquent pas du tout comment remédier au problème ou ignorer le problème #onnenousditpastout
[00:06:41]
<Aleks (he/him/il/lui)> https://aria.im/_matrix/media/v1/download/matrix.org/EasAeoQIFqHrgnAYIwunuPhc
[00:13:45]
<florent> > je bidouille sans comprendre ce que je fais.
C’est littéralement dans sa biographie 🫠
[00:14:04]
<florent> https://mstdn.social/@tofeo
[07:35:11]
<Yunohost Git/Infra notifications> [yunohost] @Salamandar [commented](https://github.com/YunoHost/yunohost/pull/1674#issuecomment-1632000640) on [issue #1674](https://github.com/YunoHost/yunohost/pull/1674) Add logrotate resource: 👍
[09:20:08]
<lapineige> > <@Alekswag:matrix.org> https://mstdn.social/@tofeo/110697325041681086 , YunoHost, ce complot illuminati pour déposseder les admins du contrôle de leur serveur avec des mails qui t'expliquent pas du tout comment remédier au problème ou ignorer le problème #onnenousditpastout
Déconne pas, il serait du genre à le dire sérieusement :p
[12:01:00]
<Yunohost Git/Infra notifications> [yunohost] @autra [commented](https://github.com/YunoHost/yunohost/pull/941#issuecomment-1632401100) on [issue #941](https://github.com/YunoHost/yunohost/pull/941) Support all kind of systemd units: > Closing because its been 3 years and the topic is more complex than this 7-line change ... Feel free to open follow-u...
[12:02:38]
<autra[m]> > <@yunohostinfra:matrix.org> [yunohost] @autra [commented](https://github.com/YunoHost/yunohost/pull/941#issuecomment-1632401100) on [issue #941](https://github.com/YunoHost/yunohost/pull/941) Support all kind of systemd units: > Closing because its been 3 years and the topic is more complex than this 7-line change ... Feel free to open follow-u...
dispo pour en discuter Aleks (he/him/il/lui) 🙂 c'est toujours quelque chose qui m'intéresse et sur lequel je peux passer du temps
[12:03:31]
<autra[m]> après faut être clair avec moi sur ce qui a une chance ou non d'être mergé, sinon ça le fait pas!
[15:01:55]
<Aleks (he/him/il/lui)> beh du coup zblerg oui je sais pas, ça a une chance d'être mergé si c'est pertinent et fonctionnel ... mais là la conclusion des discussions c'était genre "c'est compliqué et il faut repenser le truc from scratch", et moi ça me rends juste fou à force les PR qui restent ouvertes pendant des années, du coup j'ai fait un ménage de printemps et j'ai close je-sais-pas-combien-de-vieux-trucs parce qu'il faut avancer ... maintenant sur le sujet, je sais meme plus bien de quoi il s'agit ... apriori y'aurai un intérêt à avoir des .target et des .timer dans l'interface, mais du coup il faut rester prudent avec ça car tout le truc de base a été pensé sous l'angle des services et par des autres machins systemd, donc genre "quel sens ça a de `restart` une target/timer" ? "quel sens ça a de regarder les logs d'une target/timer ?", etc ... Perso je mrends pas compte, je suis à moitié perdu dans les trucs avancés de systemd entre les mount, timer, target, slice, socket et tout le tralala ... Mais si pour toi c'est relativement clair qu'on peut gérer des .target/.timer un peu comme des services alors go ...
[15:05:45]
<Aleks (he/him/il/lui)> mais bon ce qui me laisse perplexe c'est de pas non plus trop capter qu'est-ce que y'a comme usecase pour les .target ... Encore les .timer j'ai en tête les backups automatiques (borg & co) et de manière génêrale les cron job qu'on pourrait repenser en timer systemd ce qui permettrait de les visibiliser dans l'interface, mais le .target je capte pas l'histoire a part que "ça permettrait de pas intégrer 3 services différents pour Diaspora mais juste un seul", ce qui imho semble moyennement suffisant pour se lancer dans du refacto + feature qui complexifie plein de truc, mais ptete je réalise pas les intérêt que ça peut avoir
[16:08:48]
<autra[m]> ok je vois, merci pour ton point de vue. Du coup, ça me donne un peu une direction. Je pense que je vais réouvrir une PR avec ce seul changement (pas trop dur, mais bon ça fait longtemps que j'ai pas regardé cette partie du code) en expliquant les motivations
[16:09:42]
<autra[m]> qui se résume d'ailleurs assez bien à ce que tu as dit ("réunir les services sous une seule ombrelle"), sauf que je pense que ça a une grande valeur ajoutée justement, d'un point de vue utilisateur
[16:10:15]
<autra[m]> après c'est vrai qu'on a un peu tout mélanger dans les discussions. Alors que si tu considères que les .target, c'est relativement simple (à mon avis).
[16:11:14]
<autra[m]> ça se restart et comporte globalement comme les .service, et si tu restart/stop/start/whatever la target, ça fait pareil sur tous les services sous-jacents. Systemd fait exactement ce que je veux en l'occurrence, ça mérite d'être noté !
[17:25:32]
<Aleks (he/him/il/lui)> > <@autra:trancart.eu> qui se résume d'ailleurs assez bien à ce que tu as dit ("réunir les services sous une seule ombrelle"), sauf que je pense que ça a une grande valeur ajoutée justement, d'un point de vue utilisateur
yes, bah clairement y'aurait des trucs à faire en terme de valeur ajoutée sur la gestion des services, mais ça se finit souvent par "Il faut coder ça dans le packaging v3" 😅 Genre avoir un lien beaucoup plus clair entre app et services pour pouvoir dire "Cette app corresponds à ce service ET/OU depends de ce service type nginx/mysql/php" etc
[17:26:11]
<Aleks (he/him/il/lui)> (mais c'est hors scope de ce qu'on discute là)