[06:10:34]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly merged [pull request #399](https://github.com/YunoHost-Apps/searxng_ynh/pull/399): Upgrade to v2025.06.01
[06:10:37]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly deleted branch ci-auto-update-2025.06.01
[06:10:42]
<Yunohost Git/Infra notifications> [searxng_ynh] github-actions[bot] opened [pull request #400](https://github.com/YunoHost-Apps/searxng_ynh/pull/400): Upgrade master from testing
[06:10:57]
<Yunohost Git/Infra notifications> [searxng_ynh] ewilly merged [pull request #400](https://github.com/YunoHost-Apps/searxng_ynh/pull/400): Upgrade master from testing
[07:35:37]
<Yunohost Git/Infra notifications> [roundcube_ynh] ericgaspar merged [pull request #237](https://github.com/YunoHost-Apps/roundcube_ynh/pull/237): Upgrade to v1.6.11
[07:35:37]
<Yunohost Git/Infra notifications> [roundcube_ynh] ericgaspar pushed 1 commit to testing: Upgrade to v1.6.11 (#237) * Upgrade sources - main v1.6.11: https://github.com/roundcube/roundcubemail/releases/tag/1... ([666a4430](https://github.com/YunoHost-Apps/roundcube_ynh/commit/666a443088514a7ff0a4e17ef1230a599365c772))
[07:35:37]
<Yunohost Git/Infra notifications> [roundcube_ynh] ericgaspar deleted branch ci-auto-update-1.6.11
[07:35:58]
<Yunohost Git/Infra notifications> [roundcube_ynh] ericgaspar opened [pull request #238](https://github.com/YunoHost-Apps/roundcube_ynh/pull/238): Upgrade to v1.6.11 (#237)
[07:39:49]
<Yunohost Git/Infra notifications> [piped_ynh] ericgaspar merged [pull request #209](https://github.com/YunoHost-Apps/piped_ynh/pull/209): Upgrade sources
[07:39:51]
<Yunohost Git/Infra notifications> [piped_ynh] ericgaspar deleted branch ci-auto-update-sources-250602
[07:39:59]
<Yunohost Git/Infra notifications> [piped_ynh] ericgaspar opened [pull request #210](https://github.com/YunoHost-Apps/piped_ynh/pull/210): Testing
[09:18:51]
<florent[m]> Hello!
I am working in a Hackathon with other people on creating a package of Docs.
There is a white-labelled version, but we would like to propose a custom design for Yunohost. A designer is in our team to work on that.
Is there a design system or a colorset we could reuse?
[09:37:02]
<tituspijean[m]> Hi, good question! I think it's the first time we are asked about a graphic charter to enforce on an app. I do not think we have one either. If you would match the YunoHost webadmin, I would say monochrome and minimalist... which is already the case for Docs 😄
[09:38:55]
<tituspijean[m]> We have logos and badges in https://github.com/YunoHost/yunohost-artwork (though I see the one-line version of the logo is not there)
[10:03:09]
<florent[m]> Alright, thanks! :)
[12:13:09]
<m606> > <@miro5001:matrix.org> You can find that in the Ci.
> For example https://ci-apps-dev.yunohost.org/ci/job/9990
> ```
> Peak RAM usage during this test: 183MB
> RAM usage diff after test: 115MB
> Disk usage diff after test: 1365.5MB
> ```
thanks, yes I had in mind the time @Alekswag:matrix.org implemented that feature to the CI, hence my question here. CI could be the way actually, but I experimented with `time` in bash and at first sight it seems not too bad:
- code: https://github.com/oleole39/prebuild-app/blob/0d7a85d06f1b6a7d16b0adce3bd137504c26a1a9/.github/workflows/ynh-build-on-demand.yml#L21
- result: https://github.com/YunoHost-Apps/jsoncrack_ynh/releases/tag/v2025.05.23-6c5a4f4d (see build statistics)
- that I then report manually to https://github.com/YunoHost-Apps/jsoncrack_ynh/blob/f529e13fc8ad75347b2859e2ec66e728676f7416/scripts/build#L4
[12:19:08]
<m606> > <@Alekswag:matrix.org> (gotta check accross several tests to get somewhat consistent number because we measure the RAM of the entire host machin and there may be some funky result depending on if something else happens on other containers during the test)
When my solution is run with Github, I wonder whether we have the same issue.
I notice Github allocates a VM with 50GB disk space. and as per my test could have until 10-ish GB of RAM. Not sure how isolated from the rest it is in terms of resources. I would need to test more on the same package to see if the result are always the same.
[12:22:33]
<m606> > <@m606:matrix.org> Yes.
> Let me write the doc so it may save you time for understanding, but you can already see it in actions for 2 apps:
> - https://github.com/YunoHost-Apps/jsoncrack_ynh
> - https://github.com/YunoHost-Apps/it-tools_ynh
@tituspijean:matrix.org here is the doc FYI: https://github.com/oleole39/prebuild-app
and mentionned here as well: https://github.com/YunoHost/issues/issues/2281#issuecomment-2928087687
[12:26:47]
<m606> > <@m606:matrix.org> @tituspijean:matrix.org here is the doc FYI: https://github.com/oleole39/prebuild-app
> and mentionned here as well: https://github.com/YunoHost/issues/issues/2281#issuecomment-2928087687
sorry if it is spam - not sure how to interpret the "eyes" emoji whether it is expression of interest or of being dubious 😁
[12:28:57]
<tituspijean[m]> dubious would be "😕", 👀 are definitely interest :)
[12:29:25]
<Aleks (he/him/il/lui)> we need the "owo" neopossum emoji on github 😔
[13:48:15]
<maruey> Hiiiii 👋,
I am currently in a hackathon organized by French government around open-source tools of [La Suite](https://lasuite.numerique.gouv.fr/). My team is focusing on deployment of La Suite apps on Yunohost, starting with [Docs](https://docs.numerique.gouv.fr/) :)
Bad news is : we're kinda stuck 💔 because Garage's install is broken
Good news is : the fix is already done and we only need someone to merge this PR on Garage https://github.com/YunoHost-Apps/garage_ynh/pull/41
Can someone with the right permissions merge it, pliz ? 🙏
[13:54:48]
<Yunohost Git/Infra notifications> [synapse_ynh] Gredin67 [commented](https://github.com/YunoHost-Apps/synapse_ynh/pull/543#issuecomment-2930853261) on [issue #543](https://github.com/YunoHost-Apps/synapse_ynh/pull/543) Testing: I upgraded to synapse testing and then https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/pull/171 Both services are ...
[14:01:30]
<Aleks (he/him/il/lui)> merged 🎉
[14:02:19]
<Aleks (he/him/il/lui)> it's gonna take a few minutes / hours to propagate to the catalog but in the meantime you can install it using the explicit git url, either from the cli with `yunohost app install https://github.com/YunoHost-Apps/garage_ynh` or in the webadmin > Install an app > at the bottom you can enter a custom git url
[14:02:55]
<Aleks (he/him/il/lui)> (protip: it also works with branches so you could have installed the PR's branch `https://github.com/rosbeef/garage_ynh/tree/testing` )
[14:03:05]
<maruey> Thanks Aleks (he/him/il/lui) ! I'm wondering if this isn't a global admin front-end issue tho. Would that help if I opened an issue on the admin ?
[14:04:03]
<Aleks (he/him/il/lui)> hmmm not sure how that would be a front end issue ? my understanding is that the app's scripts expect something like `123G` (or `M` or whatev) instead of `123` ?
[14:04:26]
<Aleks (he/him/il/lui)> (not sure what the actual issue is i'm infering from the PR diff)
[14:06:31]
<maruey> Oh OK, might be. I thought for a second here that it was global to the helper but you might be right.
[14:07:06]
<maruey> (it wouldve been detected + fixed earlier otherwise)
[14:08:48]
<Aleks (he/him/il/lui)> anyway it's pretty cool to have people working on La Suite stuff 🥳 we'll be here if you have questions regarding packaging which definitely has some "eh" bits
[14:09:32]
<Aleks (he/him/il/lui)> also https://appgenerator.yunohost.org/ might be helpful to bootstrap an app draft with all the appropriate stuff depending on the technologies of the app and metadata etc
[14:18:22]
<Aleks (he/him/il/lui)> on a more serious note : it's pretty cool, i went through it diagonally and then my braind go lost trying to think bout what do we actually want / what are the constrains and UX/DX considerations etc ... though my main reaction was "urrrrrghhh whyyy baaash"
[14:25:04]
<maruey> and I realized only today that we could've invited you to the hackathon. Sorry for not thinking about it earlier, would've loved to have you
[14:25:34]
<maruey> Thanks ! Yep, happily i'm not alone, i have a duo of experts packagers with me, we might actually finish the package for Docs today/tomorrow
[14:26:40]
<Aleks (he/him/il/lui)> ah np idk if i would have had enough social energy atm 😅 you folks are in Paris ?
[14:27:15]
<Aleks (he/him/il/lui)> maybe we were both at JDLL tho
[14:29:40]
<maruey> Unfortunately, I could not attend the JDLL this year but I'm definitely going next year ! And yes, we are in Paris.
[14:45:05]
<Yunohost Git/Infra notifications> [apps] yunohost-bot opened [pull request #3008](https://github.com/YunoHost/apps/pull/3008): Add Gumroad to wishlist
[14:45:07]
<Yunohost Git/Infra notifications> [apps] yunohost-bot labeled Wishlist on [pull request #3008](https://github.com/YunoHost/apps/pull/3008): Add Gumroad to wishlist
[14:57:22]
<m606> > <@Alekswag:matrix.org> on a more serious note : it's pretty cool, i went through it diagonally and then my braind go lost trying to think bout what do we actually want / what are the constrains and UX/DX considerations etc ... though my main reaction was "urrrrrghhh whyyy baaash"
Regarding bash, it is mostly historical reasons I guess. I don't have much feelings PRO/AGAINST bash, so I don't mind this to be changed, but it just works for now.
[14:57:30]
<m606> > <@m606:matrix.org> Regarding bash, it is mostly historical reasons I guess. I don't have much feelings PRO/AGAINST bash, so I don't mind this to be changed, but it just works for now.
At first I wanted something to build a few of the packages I created because I couldn't build a nodeJS app on my server due to hardware limitations. Had a discussion here with @Josué who pointed me to its build script for Synapse (https://github.com/YunoHost-Apps/synapse_ynh/tree/master/auto_update) which is bash that he uses to build synapse on his machine and then upload it to Github release. From it I started to build something I could use via Github Actions for a specific app.
[14:57:36]
<m606> Also I had this discussion with you at a Yunocamp (IIRC) about a build script for app packaging V3 (which was not a WIP yet) integrated to the packagaing system. So I understood it as a script like install, upgrade, etc. we find in packaging V2, which are actually bash scripts.
[14:57:44]
<m606> Although ideally in the end only the "SECTION TO EDIT" of the build script would remain there, whereas all the remaining of the script (which is not meant for editing) could maybe be converted into Python and added to YNH core. However it would need an endpoint to which Github Actions could trigger it (so maybe it still needs to remain a portable script rather than a core function).
[14:59:42]
<m606> Regarding "what we want & constraints", yes this is maybe to be worked further.
[15:00:53]
<Aleks (he/him/il/lui)> yeah naively I was more thinking about a python script similar to the "autoupdate sources" script, that would obtain "declarative infos" from the manifest .... but then we also need some bash snippet somewhere for the app to describe build specificities when it's not straightforward (which could be a "build" or "prebuild" script in the `scripts/` folder in packaging v2, or a `build` / `prebuild` function in packaging v3)
(i'm just brainstorming out loud)
[15:01:58]
<Aleks (he/him/il/lui)> also there's a stake of possibly not relying on Github to host the built artifacts, both because ideally we want to get out of Github someday, and because Github doesnt support IPv6 and having the builds elsewhere would be a step toward effective ipv6-only support
[15:05:32]
<Aleks (he/him/il/lui)> recently we were also discussing the possiblity to use Nix tools / packaging stuff as a build system ... in particular because it allows reproducible (or almost-reproducible) builds but also because apparently it can build to AppImage stuff, which would allow for a better "containerization"-like, like having a single executable containing all the dependencies instead of having a gazillion files with different nature in /var/www/$app .... but that's me trying to paraphrase what I understood, that's R&D and could be done in a second time I suppose
[15:06:15]
<Aleks (he/him/il/lui)> (about this I'm not a huge fan of us becoming a sort of CDN / package build repository though ... like ideally the upstream projects should be the ones building their stuff meh)
[15:07:07]
<Aleks (he/him/il/lui)> (it can quickly require a lot of space if we keep archives of old builds for reasons)
[15:08:24]
<Aleks (he/him/il/lui)> or we provide an IPv6-only proxy but only for artifacts on the yunohost-apps org 🤓
[15:09:49]
<Aleks (he/him/il/lui)> also I wanted to discuss with Josue @ JDLL about how reliable it is to build venvs externally and savagely do a `sed` for the absolute path and if there was other stuff to be careful about, but i forgot about it
[15:09:57]
<Aleks (he/him/il/lui)> poke Josué
[15:09:59]
<Aleks (he/him/il/lui)> sorry that's a lot of text 😅
[15:18:14]
<m606> > <@Alekswag:matrix.org> yeah naively I was more thinking about a python script similar to the "autoupdate sources" script, that would obtain "declarative infos" from the manifest .... but then we also need some bash snippet somewhere for the app to describe build specificities when it's not straightforward (which could be a "build" or "prebuild" script in the `scripts/` folder in packaging v2, or a `build` / `prebuild` function in packaging v3)
>
> (i'm just brainstorming out loud)
Yes that could well be a python script playing the orchestrator instead of a Github workflows (run either on YNH infra, or via a Github workflow...). It's just that it was not convenient for me to develop (couldn't test it due to hardware constraints on my machines), so I developped the github workflows way so that the build would be made on Github infra.
As for getting out of Github-dependency yes [I had this in mind](https://github.com/oleole39/prebuild-app?tab=readme-ov-file#3-someday-cloud-build-using-yunohosts-own-infrastructure). But maybe that could involve moving to Gitea/Forjego for instance and those are more or less compatible with Github API/Actions workflows.
[15:26:26]
<m606> regarding parsing manifest and `build`/`prebuild` script, the current script does [parse the manifest a bit](https://github.com/oleole39/prebuild-app/blob/c81663e72f14ac52f343ef325b201670c7497d19/scripts/build#L78), but some of the info I needed is [not yet the in the manifest](https://github.com/oleole39/prebuild-app/blob/c81663e72f14ac52f343ef325b201670c7497d19/scripts/build#L14) although that would be easy and better in terms of UX to add them to manifest later on if it is decided so. (I am just thinking that `ynh_owner` and `ynh_repo` could be related to Local build section only given that for Github Actions builds they can probably be deduced from the Github workflow path).
[15:33:09]
<m606> for me in terms of UX, the `build` script should in the end have only [that content](https://github.com/oleole39/prebuild-app/blob/c81663e72f14ac52f343ef325b201670c7497d19/scripts/build#L14-L42):
- with variables added as much as possible to the manifest, but maybe there will be still remain a few ones related to local builds for those who would feel safer building themselves rather than downloading a prebuilt file).
- ideally without functions declaration (but what to do not to have 3 files in `/scripts` related to the build action?) but only with their content
[15:33:17]
<Aleks (he/him/il/lui)> i tried to brain dump my thoughts in a more structured fashion here : https://github.com/YunoHost/issues/issues/2281#issuecomment-2931277536
[15:39:17]
<m606> > <@Alekswag:matrix.org> recently we were also discussing the possiblity to use Nix tools / packaging stuff as a build system ... in particular because it allows reproducible (or almost-reproducible) builds but also because apparently it can build to AppImage stuff, which would allow for a better "containerization"-like, like having a single executable containing all the dependencies instead of having a gazillion files with different nature in /var/www/$app .... but that's me trying to paraphrase what I understood, that's R&D and could be done in a second time I suppose
A bit more of isolation could be nice indeed, but I generally think of Appimage to be shipped with many dependencies like a Flatpak package, inflating significantly the size of the file. Anyway that sounds like an interesting project though more complex indeed for the short term.
[15:41:39]
<m606> > <@Alekswag:matrix.org> (about this I'm not a huge fan of us becoming a sort of CDN / package build repository though ... like ideally the upstream projects should be the ones building their stuff meh)
yes but sometime you want to create a build [for reasons which are dependent of the Yunohost package](https://github.com/oleole39/prebuild-app?tab=readme-ov-file#why-using-a-prebuilt-archive-in-an-app-package-) and not to the fact upstream has not prebuild it.
[15:43:20]
<Aleks (he/him/il/lui)> https://aria.im/_bifrost/v1/media/download/AUCeQNcvjsJtPtoe91CXI4asdQe5VTSrc655TZmNquIVa-ey6Wnz1F9hEYLzcrsQGR4BKvS1-QTecOT3uXsDxWpCeXNnYfwQAG1hdHJpeC5vcmcvSEhyTlpGYmttQ0p3eXZvYW9NY0ttUXdV
[15:44:12]
<m606> > <@Alekswag:matrix.org> (it can quickly require a lot of space if we keep archives of old builds for reasons)
I don't know how big is Yunohost + Yunohost-Apps now, I guess it should be reasonable in terms of disk space compared to price/To, but on the principle I agree with you
[15:44:51]
<Aleks (he/him/il/lui)> oh computers my computers why are you computers
[15:48:39]
<Josué> yes we can discuss about this. Also the interest of the pre-built venv is that it make the venv reproductible. I mean by example if some dependency are upgraded we can sometime end with some different venv (the version of each package into the venv) depending of when the app was installed which could end with some not easy issue to reproduce because it happen "at some point". The advantage with the prebuilt venv is that for the app version x you will always have the same dependency.
[15:56:36]
<m606> > <@Alekswag:matrix.org> i tried to brain dump my thoughts in a more structured fashion here : https://github.com/YunoHost/issues/issues/2281#issuecomment-2931277536
an other stake is that it would significantly improve YNH project's ecological footprint - think of the electricity used by the billions of YNH instance admins building app locally instead of being able to use prebuilt files.
[15:56:57]
<Aleks (he/him/il/lui)> "billions" 😬
[15:57:42]
<m606> > <@Alekswag:matrix.org> "billions" 😬
more? haven't checked the solar system stats
[15:57:46]
<Aleks (he/him/il/lui)> There are dozens of Yunohost instances ! Dozens !
[15:58:47]
<Aleks (he/him/il/lui)> https://c.tenor.com/olnkZI1dcQQAAAAC/tenor.gif
[16:01:41]
<m606> > <@Alekswag:matrix.org> There are dozens of Yunohost instances ! Dozens !
You [dozenalist](https://fr.wikipedia.org/wiki/Syst%C3%A8me_duod%C3%A9cimal#Doz%C3%A9nalisme)!
[16:04:32]
<Aleks (he/him/il/lui)> >YAML
>
>In version 1.1[15] of the YAML data storage format, sexagesimals are supported for plain scalars, and formally specified both for integers[16] and floating point numbers.[17] This has led to confusion, as e.g. some MAC addresses would be recognised as sexagesimals and loaded as integers, where others were not and loaded as strings. In YAML 1.2 support for sexagesimals was dropped.[18]
yo wat
[17:03:12]
<rodinux> Triolets 12/8
[17:03:39]
<rodinux> ou 6/8 en musique
[18:55:02]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T pushed 1 commit to doc: Update doc for matrix v2 ([19f27656](https://github.com/YunoHost-Apps/synapse_ynh/commit/19f27656c1bfea0921bcab8ed60c6351b0f1b876))
[18:55:03]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T created new branch doc
[18:55:43]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T opened [pull request #546](https://github.com/YunoHost-Apps/synapse_ynh/pull/546): Update doc for matrix v2
[19:04:18]
<Salamandar> > <@Alekswag:matrix.org> >YAML
> >
> >In version 1.1[15] of the YAML data storage format, sexagesimals are supported for plain scalars, and formally specified both for integers[16] and floating point numbers.[17] This has led to confusion, as e.g. some MAC addresses would be recognised as sexagesimals and loaded as integers, where others were not and loaded as strings. In YAML 1.2 support for sexagesimals was dropped.[18]
>
> yo wat
Ah ah
[19:04:51]
<Salamandar> Oui yaml a tenté de couvrir toutes les représentations de type, et les str sans quotes... Pas bon ménage
[19:46:51]
<Aleks (he/him/il/lui)> Et booléens, el famoso 🙃
[20:22:05]
<Salamandar> Yeah... "yes" being transformed as true is cursed
[21:43:19]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T pushed 1 commit to testing: Update doc for matrix v2 ([19f27656](https://github.com/YunoHost-Apps/synapse_ynh/commit/19f27656c1bfea0921bcab8ed60c6351b0f1b876))
[21:43:19]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T merged [pull request #546](https://github.com/YunoHost-Apps/synapse_ynh/pull/546): Update doc for matrix v2
[21:43:44]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T pushed 76 commits to master ([835f0987256e...19f27656c1bf](https://github.com/YunoHost-Apps/synapse_ynh/compare/835f0987256e...19f27656c1bf))
[21:43:44]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T merged [pull request #543](https://github.com/YunoHost-Apps/synapse_ynh/pull/543): Testing
[21:43:45]
<Yunohost Git/Infra notifications> [synapse_ynh/master] Fix config panel - Josué Tille
[21:43:46]
<Yunohost Git/Infra notifications> [synapse_ynh/master] Add support for MSC 1929 - Josué Tille
[21:43:47]
<Yunohost Git/Infra notifications> [synapse_ynh/master] Update doc for matrix v2 - Josué Tille
[21:44:31]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T deleted branch doc
[22:07:24]
<Yunohost Git/Infra notifications> [freshrss_ynh] yunohost-bot opened [pull request #207](https://github.com/YunoHost-Apps/freshrss_ynh/pull/207): Upgrade to v1.26.3
[22:17:59]
<Yunohost Git/Infra notifications> [syncthing_ynh] yunohost-bot opened [pull request #209](https://github.com/YunoHost-Apps/syncthing_ynh/pull/209): Upgrade to v1.29.7
[22:19:28]
<@rosbeefandino:3cmr.fr> Hi all, Damn', i'm a casual 👻 git contrib/ynh mtrx room follower but real ynh hoster for my humble family.
I just wanted to make a decentralised backup service and garage is my dream since a year. I fall in the yunohost package yesterday and you needed it I' so impressed by the alignment of the planets🤣.
Please be careful of the patch, I just correct the install script not tested very well other case.
I just want to tell @room how great 🫶 is the job you 've made, make and will make.
You are awesome !!!😭
[22:21:12]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 29 pending update PRs
- 14 new apps PRs
- 3 failed apps updates: homebox, khatru-pyramid, swingmusic
See the full log here: https://paste.yunohost.org/raw/ulakosagil
Autoupdate dashboard: https://apps.yunohost.org/dash?filter=autoupdate
[22:23:52]
<Aleks (he/him/il/lui)> i suppose we could have a regex to validate the format
[22:24:18]
<@rosbeefandino:3cmr.fr> I was not table to set value in size field because of number type, field required a empty value ... I didn't understand. Don't know why.
I seted it to string. So use with caution.
[22:35:38]
<@rosbeefandino:3cmr.fr> > <@Alekswag:matrix.org> i suppose we could have a regex to validate the format
Yes just testing number. I did some regex for synapse some Years ago. This case should be simple, but time and my memory is the wall ;) ps : install script put the G after the value from the field.
[22:36:24]
<@rosbeefandino:3cmr.fr> On wensday I may have time ;);
[22:37:47]
<@rosbeefandino:3cmr.fr> Have Good night all.
[22:39:55]
<Aleks (he/him/il/lui)> ah so the "type = number" should have worked in fact ?
[22:39:56]
<Aleks (he/him/il/lui)> hmmmm
[22:40:12]
<Aleks (he/him/il/lui)> would need to dig in to understand what's the actual issue x_x
[22:41:40]
<@rosbeefandino:3cmr.fr> > <@Alekswag:matrix.org> ah so the "type = number" should have worked in fact ?
Yep