[03:01:45]
<Yunohost Git/Infra notifications> App simple-file-manager goes down from level 8 to 7 in job [#20610](https://ci-apps.yunohost.org/ci/job/20610)
[09:09:09]
<Yunohost Git/Infra notifications> [nextcloud_ynh] @ericgaspar pushed 1 commit to testing: cleaning ([d386d90f](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/d386d90ff0848b7e76160de400c78b5c31b43c70))
[13:28:54]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-cloudlog
[13:28:55]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-cloudlog: Add Cloudlog to wishlist ([5b255982](https://github.com/YunoHost/apps/commit/5b255982fb041583bc2ab038babea867e1f0cd15))
[13:28:56]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1868](https://github.com/YunoHost/apps/pull/1868): Add Cloudlog to wishlist
[13:36:27]
<Yunohost Git/Infra notifications> [apps] @ericgaspar closed [pull request #1868](https://github.com/YunoHost/apps/pull/1868): Add Cloudlog to wishlist
[13:36:27]
<Yunohost Git/Infra notifications> [apps] @ericgaspar [commented](https://github.com/YunoHost/apps/pull/1868#issuecomment-1816446052) on [issue #1868](https://github.com/YunoHost/apps/pull/1868) Add Cloudlog to wishlist: Please, a little search before submitting apps wouldnt hurt https://github.com/YunoHost-Apps/cloudlog_ynh
[13:36:37]
<Yunohost Git/Infra notifications> [apps] @ericgaspar deleted branch add-to-wishlist-cloudlog
[13:37:19]
<eric_G> https://community.gladysassistant.com/t/gladys-sur-yunohost-aidez-nous-en-votant/8489 😅
[13:48:20]
<eric_G> Gladys-sans-Docker-aidez-nous-en-votant 😬
[13:53:15]
<Mateusz Szymański> looks like simple `npm ci && npm run whatever` combo? https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx
[13:56:11]
<Yunohost Git/Infra notifications> @fflorent forked apps to [fflorent/yunohost-apps](https://github.com/fflorent/yunohost-apps)
[13:56:50]
<Yunohost Git/Infra notifications> [apps] @fflorent opened [pull request #1869](https://github.com/YunoHost/apps/pull/1869): Add grist to catalog
[14:02:24]
<lapineige> > <@ericg:matrix.org> https://community.gladysassistant.com/t/gladys-sur-yunohost-aidez-nous-en-votant/8489 😅
Users believing that the whishlist is actually a to-do list...
[14:03:06]
<eric_G> https://github.com/ericgaspar/gladys-assistant_ynh
[14:03:17]
<eric_G> I had a go: https://ci-apps-dev.yunohost.org/ci/job/11132
[14:04:43]
<tituspijean> *oh you*
[14:05:22]
<tituspijean> I posted a message thanking them for their work and interest, and "defending" our position on Docker 😅
[14:06:51]
<tituspijean> I really need to understand how to fix the emails sent by the forum 😕
[14:21:57]
<Yunohost Git/Infra notifications> [apps] @ericgaspar approved [pull request #1869](https://github.com/YunoHost/apps/pull/1869#pullrequestreview-1737114511) Add grist to catalog
[14:22:00]
<Yunohost Git/Infra notifications> [apps] @ericgaspar merged [pull request #1869](https://github.com/YunoHost/apps/pull/1869): Add grist to catalog
[14:22:04]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 2 commits to master ([769e9307f047...1f6106aef566](https://github.com/YunoHost/apps/compare/769e9307f047...1f6106aef566))
[14:22:06]
<Yunohost Git/Infra notifications> [apps/master] Add grist to catalog - Florent FAYOLLE
[14:25:31]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to master: add Grist Logo ([4653d54a](https://github.com/YunoHost/apps/commit/4653d54a021baf584bc41e8c0e7873f8232d2510))
[15:20:46]
<tituspijean> eric_G: you have deleted your repo? 🤔
[15:22:13]
<lapineige> > <@titus:pijean.ovh> I posted a message thanking them for their work and interest, and "defending" our position on Docker 😅
I was going to remind them about the difference between a wishlist and a todo list, but I don't have my credentials 😂
Thanks :)
[15:22:22]
<lapineige> > <@titus:pijean.ovh> I really need to understand how to fix the emails sent by the forum 😕
What do you mean ?
[15:23:32]
<tituspijean> > What do you mean ?
the forum is not sending emails anymore, blocking new registrations
[15:23:54]
<lapineige> Ah that's why I couldn't login with an email link
[15:24:17]
<lapineige> Good luck with that... 🤗
[17:00:33]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch update_app_levels
[17:00:35]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to update_app_levels: Update app levels according to CI results ([0f8169e4](https://github.com/YunoHost/apps/commit/0f8169e42d347124c0c82087763522c9e65f7ac9))
[17:00:36]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[17:41:39]
<m606> Interesting for me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys example](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
1. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
2. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I guess I would need to go through Docker grammar to better understand something like the ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx port config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:41:49]
<m606> Interesting for me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys example](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I guess I would need to go through Docker grammar to better understand something like the ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx port config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:42:06]
<m606> Interesting for me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys example](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I guess I would need to go through Docker grammar to better understand something like the ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx ports config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:42:22]
<m606> Interesting to me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys example](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I guess I would need to go through Docker grammar to better understand something like the ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx ports config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:43:03]
<m606> Interesting to me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys case](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I guess I would need to go through Docker grammar to better understand something like the ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx ports config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:44:44]
<m606> Interesting to me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys case](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I would need to go through a Docker grammar book to better understand those instructions) ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx ports config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database (this I have an idea how to setup with YNH),
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance Reverse Proxy, or other app - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:48:55]
<m606> Interesting to me as well, in particular the hint you give on **how to create a YNH package for open source apps which are only released as Docker images** ... always wondered about and never dug into it so far. That could be an idea for a documentation page I could work on.
1. Can it be generalized that the first move would be to check the Dockerfile.buildx file (more than Dockerfile or docker-compose.yml? or all of them are to consider?)
1. I guess the idea is to translate the various instructions for YNH stack, so for instance if I take the [Gladys case](https://github.com/GladysAssistant/Gladys/blob/master/docker/Dockerfile.buildx)) you pointed at:
a. use NodeJS stack and install project's node packages dependencies (referring to YNH helpers and examples in YNH apps catalog)
b. find Debian packages replacements for those indicated for Alpine Linux Package Keeper.
c. perform indicated file operations: copy, move, delete
and replicate the steps in there (I would need to go through a Docker grammar book to better understand those instructions) ?
d. Set config. Not sure how this should be understood though `ENV LD_LIBRARY_PATH /lib` for YNH, could creating such environment variable (not isolated anymore in YNH compared to Docker) impact other apps ?
e. Nginx ports config
f. Follow other usual YNH app packaging steps (manifest, scripts, etc.)
3. But I see in Dockerfile a mention for qemu, not sure if this is related to app or to the Docker layer. Would it make sense to use qemu in YNH? Could it be ignored?
3. docker-compose.yml file mentions:
a. a SQL Lite database - not exactly sure how generate it but I would have to look for it. I guess that it would link to the app if the path is respected.
b. an other image "watchtower". As it relates to docker image updates, I guess it could be ignored in a YNH package. But sometimes I have seen various images called which are for instance a Reverse Proxy, a MySQL DB, etc. - it means that those other apps or an equivalent needs to be installed as a requirement on the YNH server (a bit like Nextcloud & Collabora packages) ? For the MySQL DB example, when login/pwd is handled in one of the Docker config files, how this should be translated in a YNH package?
5. When can we consider that instructions in a Docker files are not enough so that a package for YNH can be made ? I mean how comes they are enough to make the app work, but not to let YNH packager understand enough of how the install works?
And another question if anyone knows - **which data Docker company can specifically get about users of Docker images ?** Does docker app communicate all the time with Docker's severs, or only at install/update (i.e. they at least know which sever installed/updated which image) ?
[17:59:25]
<Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[18:28:28]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([f899c505](https://github.com/YunoHost/apps/commit/f899c50510706849ab4dfdacb12525278a4b32af))
[18:28:51]
<Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[18:29:10]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([fc30e03c](https://github.com/YunoHost/apps/commit/fc30e03cb642b0e578de6bb292460738b2f70651))
[18:36:55]
<Yunohost Git/Infra notifications> App fittrackee failed all tests in job [#20131](https://ci-apps.yunohost.org/ci/job/20131) :(
[18:44:01]
<orhtej2> > <@yunohostinfra:matrix.org> App fittrackee failed all tests in job [#20131](https://ci-apps.yunohost.org/ci/job/20131) :(
New lxd images when?
[18:44:41]
<eric_G> The future is nooow
[18:46:48]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([f6d3428c](https://github.com/YunoHost/apps/commit/f6d3428c1efef4c6880e1a5676e5cb98bd3a42fd))
[18:47:46]
<Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[18:52:09]
<Yunohost Git/Infra notifications> App weblate failed all tests in job [#20443](https://ci-apps.yunohost.org/ci/job/20443) :(
[19:51:11]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([e49b7e7f](https://github.com/YunoHost/apps/commit/e49b7e7f2df9a3af619c17946466d5bc4be1bf7c))
[19:54:43]
<Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[19:55:16]
<Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to update_app_levels: Update apps.toml ([6cac9e64](https://github.com/YunoHost/apps/commit/6cac9e6437c7b0f0047387bc50becd2f64705e5e))
[20:14:26]
<Yunohost Git/Infra notifications> [apps] @ericgaspar approved [pull request #1870](https://github.com/YunoHost/apps/pull/1870#pullrequestreview-1737847499) Update app levels according to CI results
[20:18:45]
<Yunohost Git/Infra notifications> [apps] @alexAubin [commented](https://github.com/YunoHost/apps/pull/1870#issuecomment-1817047440) on [issue #1870](https://github.com/YunoHost/apps/pull/1870) Update app levels according to CI results: Thanks for all the checks P
[20:18:53]
<Yunohost Git/Infra notifications> [apps] @alexAubin merged [pull request #1870](https://github.com/YunoHost/apps/pull/1870): Update app levels according to CI results
[20:18:56]
<Yunohost Git/Infra notifications> [apps] @alexAubin deleted branch update_app_levels
[20:36:33]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to add-to-wishlist-kutt-it: Add Kutt.it to wishlist ([fa3a6803](https://github.com/YunoHost/apps/commit/fa3a6803800a3ff484cde2ea1b0e95f24fd40f6d))
[20:36:33]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch add-to-wishlist-kutt-it
[20:36:35]
<Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1871](https://github.com/YunoHost/apps/pull/1871): Add Kutt.it to wishlist