Monday, April 28, 2025
dev@conference.yunohost.org
April
Mon Tue Wed Thu Fri Sat Sun
  1
2
3
4
5
6
7
8 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
       
             

[07:27:31] <Salamandar> https://aria.im/_bifrost/v1/media/download/AcOYy9YTPtLhK0XqEzBSTWMsYbZwRM4Zo4UMVUF_HqINGvVOXR1-YQtdu4fTkIaqstCwbxlz9hwhjKknnbVER4RCeWgHGbzgAG1hdHJpeC5vcmcvbGFzUm1LZXVKT2lETkZ1U3VVcnNlU1JP
[07:28:05] <Salamandar> This is the GIMP 3 installer icon, looks kinda nice and i think there's a "animal peeking in a box" trend 😏
[07:28:06] <tituspijean[m]> *package all the things!*
[11:06:29] <Yunohost Git/Infra notifications> [yunohost] t​ituspijean edited [pull request #2098](https://github.com/YunoHost/yunohost/pull/2098): Increase DKIM key length
[11:51:55] <Tagada> Should we do a migration for existing 1024 bit keys ?
[11:56:30] <Salamandar> that'd be best ye
[11:57:10] <Salamandar> although i'm not sure it can be automatic : it requires DNS updates…
[11:58:17] <Tagada> That would be a two step migration ?
[12:00:35] <Tagada> Migration 1: produce a key, ask admin to add a new DNS record
Migration 2: check if the DNS is ok, change the signing key, ask admin to remove the old key from DNS
[12:22:16] <Yunohost Git/Infra notifications> [repo.yunohost.org] S​alamandar pushed 2 commits to main ([2e3c9a4d1fee...c236495824ef](https://github.com/YunoHost/repo.yunohost.org/compare/2e3c9a4d1fee...c236495824ef))
[12:22:17] <Yunohost Git/Infra notifications> [repo.yunohost.org/main] Rename home -> repositories in breadcrumbs remove useless function in scripts - Félix Piédallu
[12:22:17] <Yunohost Git/Infra notifications> [repo.yunohost.org/main] Replace tabs with spaces - Félix Piédallu
[13:53:43] <Yunohost Git/Infra notifications> [build.yunohost.org] S​alamandar pushed 2 commits to main ([c24a675b767e^...22fdd78a4a79](https://github.com/YunoHost/build.yunohost.org/compare/c24a675b767e^...22fdd78a4a79))
[13:54:07] <Yunohost Git/Infra notifications> [build.yunohost.org] S​alamandar created new branch main
[13:54:12] <Yunohost Git/Infra notifications> [build.yunohost.org/main] Fully rework fancyindex configuration. Add top-level index.html. - Félix Piédallu
[13:54:14] <Yunohost Git/Infra notifications> [build.yunohost.org/main] Add setup scripts - Félix Piédallu
[13:54:16] <Yunohost Git/Infra notifications> S​alamandar deleted repository repo.yunohost.org: Source code of repo.yunohost.org deployed via my_webapp https://github.com/YunoHost/repo.yunohost.org
[13:54:24] <Salamandar> (that's me, just to reuse the old build.yunohost.org repository instead of creating a new one)
[13:54:45] <Yunohost Git/Infra notifications> S​alamandar renamed repository repo.yunohost.org: The page with all YunoHost Images https://github.com/YunoHost/repo.yunohost.org
[13:54:47] <Yunohost Git/Infra notifications> S​alamandar edited repository repo.yunohost.org: Source code of repo.yunohost.org deployed via my_webapp https://github.com/YunoHost/repo.yunohost.org
[13:54:50] <Yunohost Git/Infra notifications> S​alamandar edited repository repo.yunohost.org: Source code of repo.yunohost.org deployed via my_webapp https://github.com/YunoHost/repo.yunohost.org
[13:54:59] <Yunohost Git/Infra notifications> [repo.yunohost.org] S​alamandar deleted branch master
[13:56:04] <Yunohost Git/Infra notifications> [repo.yunohost.org] S​alamandar pushed 1 commit to main: Ooops, fix breadcrumb name on index ([1c2e622e](https://github.com/YunoHost/repo.yunohost.org/commit/1c2e622ea6433f6321c1a7382e1a856ebb39b182))
[13:56:26] <Yunohost Git/Infra notifications> [repo.yunohost.org] S​alamandar pushed 1 commit to main: Ooops, fix breadcrumb name on index ([28cccce2](https://github.com/YunoHost/repo.yunohost.org/commit/28cccce264747d9b2a204632e95863eb4c7107ce))
[19:16:31] <Josué> Hello,
I would like your point of view about https://github.com/YunoHost/yunohost/pull/2099

For now I did a really simple implementation based on the `domain_add` method. But I'm not sure if it's the good choice. I mean, to me there are 2 possibility.
1. Use the `domain_add` method and use all thing provided by this, cert management, DNS, conflict management. So the app extra domains will be registered in LDAP. The advantage is that a lot of thing are already available but maybe it's a bit overkill in some cases. And we will need to also do some adaptation because we don't want from user point of view the app extra domains is same than the others domains.
2. Use some additional code, like we already do for metronome and cryptpad, but in the code, so we adapt the nginx config to handle the app extra domain. We also adapt the DNS and the certificate management. This could be lighter than the first solution and by default. And for the user point of view there will be a clear separation between the domain managed by the user and the app extra domains.

What do you think ?
[19:18:41] <Aleks (he/him/il/lui)> to me the design should be driven by which apps actually need this, are there any apps beyond metronome/prosody and cryptpad ?
[19:19:30] <Aleks (he/him/il/lui)> (i'm confused about the link to #676, it links to https://github.com/YunoHost/yunohost/pull/676 which is a super old PR, or https://github.com/YunoHost/issues/issues/676 which is about Yunohost as an identity provider ?...)
[19:21:54] <Yunohost Git/Infra notifications> [yunohost] J​osue-T edited [pull request #2099](https://github.com/YunoHost/yunohost/pull/2099): WIP: App domain resource
[19:22:11] <Josué> I think I put the completly wrong reference, fixed: https://github.com/YunoHost/issues/issues/2563
[19:23:22] <Josué> So currently, yes crpytpad, metronome need it. Synapse will also need it to separate some component.
[19:24:25] <Josué> From what I know generally the need is a nginx config with all stuff which come with (DNS, certificate)
[19:39:15] <Josué> To me the main reason of providing this feature are:
- Currently we can't declare the permission for the subdomain.
- There are some big custom nginx config which are mostly a copy from the core but still customisation. So some Yunohost core settings are just broken for theses domains.
- A lot of custom code between different apps to handle this.
- the way we manage this currently is not really user friendly. By example we have today a new user confused about the certificate for cryptpad: https://forum.yunohost.org/t/cryptpad-can-t-pass-the-welcome-screen-after-the-installation/36693
[19:39:51] <Yunohost Git/Infra notifications> [issues] J​osue-T edited [issue #2563](https://github.com/YunoHost/issues/issues/2563): Add possibility to declare subdomain requirement in app ressources
[21:33:44] <Josué> ? 😉
[21:39:21] <Tagada> I think a new ressource for domain is not the good way.
We could use the `permission` ressources to ask question about domains, path and stuff, during install and change_url...
[21:50:19] <Josué> the issue is that currently an app can be installed only on one domain. And for some app we need multiple domain for the same app. That's the idea of the extra domain resource.
[21:58:31] <Salamandar> Yeah i'm wondering if packaging v3 will solve this, i think so
[22:04:13] <Tagada> Maybe this would be called DomainsRessources and we would drop the install.domain question