[00:21:02]
<Yunohost Git/Infra notifications> App qr goes down from level 8 to 6 in job [#18213](https://ci-apps.yunohost.org/ci/job/18213)
[06:38:37]
<lapineige> (I realized right after recording I forgot one thing, some values are not set 😂)
[06:40:28]
<lapineige> Project secret code name ( 😎 ): YoloGen. Yunohost app Generator but done in Yolo mode 😁
[07:14:26]
<lapineige> Heavy WIP, I still have to make the other scripts and to prepare a lot more options, and obviously a bunch of CSS has to be done, but it's happening :)
[12:41:53]
<lapineige> https://github.com/YunoHost-Apps/pixelfed_ynh/issues/223#issuecomment-1700965918
Does someone know why the new group parameter is not updated in php.conf file during upgrade ? (while the file is updated…)
[12:45:50]
<Yunohost Git/Infra notifications> [apps] @oleole39 [commented](https://github.com/YunoHost/apps/pull/1717#issuecomment-1700973022) on [issue #1717](https://github.com/YunoHost/apps/pull/1717) New app store: Additional ideas to continue the brainstorm: - Catalog news - Regarding listed feature "Sort by newest" => just to hav...
[12:53:46]
<orhtej2> > https://github.com/YunoHost-Apps/pixelfed_ynh/issues/223#issuecomment-1700965918
> Does someone know why the new group parameter is not updated in php.conf file during upgrade ? (while the file is updated…)
https://github.com/YunoHost/yunohost/blob/465f6da5cd4d716bbcb802dfd742114083034235/helpers/php#L88
Passing `usage` makes autogenerated config
[12:58:53]
<lapineige> Ok, so I'm confused about the way forward to fix our issue
[12:59:17]
<lapineige> I guess I can't just do a replace_string in the php file, as any automated regeneration will erase it ?
[12:59:40]
<lapineige> can we give an app php conf a setting for php group owner ?
[13:44:18]
<Aleks (he/him/il/lui)> I can add this this afternoon maybe
[14:07:41]
<lapineige> oh well that would be great ❤️
[14:08:08]
<lapineige> also the linter gives us a warning not to use `www-data` as group, but in Pixelfed case, this is mandatory. Could this be ignored in some way ?
[14:10:17]
<Aleks (he/him/il/lui)> yeah i'll have a look at what the linter says
[14:11:35]
<Aleks (he/him/il/lui)> > https://github.com/YunoHost/yunohost/blob/465f6da5cd4d716bbcb802dfd742114083034235/helpers/php#L88
>
> Passing `usage` makes autogenerated config
NB: `--usage` aint necessary anymore for autogenerated conf, just having an `extra-php.conf` ( i dont remember the exact name anymore) is enough
[14:13:31]
<Aleks (he/him/il/lui)> cf https://github.com/YunoHost/yunohost/pull/1684
[14:43:32]
<lapineige> > <@Alekswag:matrix.org> yeah i'll have a look at what the linter says
` ✘ DO NOT run the app PHP worker as root or www-data! Use a dedicated system user for this app!` (https://ci-apps-dev.yunohost.org/ci/job/9171)
[14:43:58]
<Aleks (he/him/il/lui)> yeah i'm confused because supposedly the linter only checks the User directive, not Group ?
[14:44:04]
<lapineige> > <@Alekswag:matrix.org> NB: `--usage` aint necessary anymore for autogenerated conf, just having an `extra-php.conf` ( i dont remember the exact name anymore) is enough
the extra file wasn't working to set the group, it added a new group line (it was a double) that did not have the priority on the default one
[14:44:27]
<lapineige> > <@Alekswag:matrix.org> yeah i'm confused because supposedly the linter only checks the User directive, not Group ?
apparently that's what it does ^^
[14:46:13]
<Aleks (he/him/il/lui)> hmyeah i reproduce the issue, investigating
[14:46:52]
<Aleks (he/him/il/lui)> ah nevermind i was looking at the wrong code
[14:50:55]
<Yunohost Git/Infra notifications> [package_linter] @alexAubin pushed 1 commit to master: phpconf: allow the usage of www-data for Group ([5d90885b](https://github.com/YunoHost/package_linter/commit/5d90885b49cbd472883046adcd73bd13fdc28314))
[14:51:31]
<Aleks (he/him/il/lui)> fixed, though anyway this check aint relevant once you'll be using the extra_php-fpm.conf (commit incoming for a new `--group` option)
[15:48:33]
<Aleks (he/him/il/lui)> incoming version 11.2.4 with this new option + support for `{% if stuff %}` syntax for app notifications (cf my_webapp's post install.md)
[15:49:45]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin opened [pull request #124](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124): Conditional block for POST_INSTALL.md
[15:50:59]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin pushed 1 commit to jinja-doc: Bump yunohost requirement ([18c71da0](https://github.com/YunoHost-Apps/my_webapp_ynh/commit/18c71da0445c898e467dde19d4e874b248991410))
[16:01:10]
<lapineige> You rocks !
[16:04:46]
<lapineige> how can I use it ?
*edit: found it https://github.com/YunoHost/yunohost/commit/65d25710725b06d281630644b80d8d01dfba1bde*
[16:05:28]
<Aleks (he/him/il/lui)> yeah `--group=www-data` on `ynh_add_fpm_config`
[16:11:00]
<lapineige> how fast is the CI updated ? Could I run it right now, or should I wait ?
[16:11:22]
<Aleks (he/him/il/lui)> i'm rebuilding the ci base images
[16:11:34]
<Aleks (he/him/il/lui)> should be done in a few minutes
[16:50:37]
<lapineige> wow I didn't expect it to be that fast 😂
[17:14:35]
<lapineige> By the way, do you have an idea of any (simple/mnimalistic) framework or way of doing thing to implement translations for this ?
_(My very genuine idea about this would be to replace each string by a call to a dictionnary containing all versions of that string, with the language used as a key to retrieve the string. The thing is, how do we manage external contributions to translate it ?)_
[17:24:51]
<Aleks (he/him/il/lui)> there are tools for this, the most common one is gettext
[17:25:05]
<Aleks (he/him/il/lui)> will try to find an example/tutorial, i also need this for the app store
[17:26:23]
<Aleks (he/him/il/lui)> but basically instead of writing `Lorem ipsum` in your jinja template, you'll write something like `{{ _('Lorem ipsum') }}` and then you can extract all strings into a standardized format such as a `.po`, and then manage the translation independently from the code (and even interface it with stuff like Weblate if needed and relevant) etc
[17:31:24]
<Aleks (he/him/il/lui)> yeah so :
- cf for example here : https://github.com/labriqueinternet/install/blob/master/templates/form.html#L11
- you can see in `requirements.txt` there's the Flask-Babel module
- there's also a `translations/fr/LC_MESSAGES` containing .po which was auto-generated then translations manually added inside it. The .po is generated by magically parsing all occurences of stuff like `_("Message"), either in templates or in the python code
- in `app.py` there is `from flask_babel import gettext as _`
[17:32:02]
<Aleks (he/him/il/lui)> - cf also the README for instructions about extracting / compiling translations : https://github.com/labriqueinternet/install/tree/master#translations
[17:34:38]
<Aleks (he/him/il/lui)> https://python-babel.github.io/flask-babel/
[17:41:54]
<lapineige> > <@Alekswag:matrix.org> but basically instead of writing `Lorem ipsum` in your jinja template, you'll write something like `{{ _('Lorem ipsum') }}` and then you can extract all strings into a standardized format such as a `.po`, and then manage the translation independently from the code (and even interface it with stuff like Weblate if needed and relevant) etc
yeah I was thinking about something like that, the most crucial missing part for me was the external tool for contributors
[17:42:34]
<lapineige> > in app.py there is from flask_babel import gettext as _
Oh, that's brillant !
[17:43:23]
<lapineige> Thanks a lot, I take note of this, I might implement it in the future (or let someone else do it 😇)
[17:43:59]
<Aleks (he/him/il/lui)> not 100% sure about all the bits of bureaucracy to get it working but that's essentially it yeah
[17:57:55]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @yunohost-bot [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124#issuecomment-1701514959) on [issue #124](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124) Conditional block for POST_INSTALL.md: Alrighty
[[Test Badge](https://img.shields.io/endpoint?url=https://ci-apps-dev.yunohost.org/ci/api/job/9222/badge)](ht...
[17:57:57]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124#issuecomment-1701514913) on [issue #124](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124) Conditional block for POST_INSTALL.md: testme
[18:11:57]
<Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to app-store: appstore: implement sort-by-newest on catalog ([eddaf494](https://github.com/YunoHost/apps/commit/eddaf494a4d4049a631dbb87d1bc9aea3a611cd6))
[18:46:58]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin pushed 5 commits to jinja-doc ([18c71da0445c...2e5a452b535f](https://github.com/YunoHost-Apps/my_webapp_ynh/compare/18c71da0445c...2e5a452b535f))
[18:47:02]
<Yunohost Git/Infra notifications> [my_webapp_ynh/jinja-doc] Fix tests.toml, again - tituspijean
[18:47:05]
<Yunohost Git/Infra notifications> [my_webapp_ynh/jinja-doc] Update manifest.toml - Éric Gaspar
[18:47:06]
<Yunohost Git/Infra notifications> [my_webapp_ynh/jinja-doc] Merge branch testing into jinja-doc - Alexandre Aubin
[18:48:25]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin edited [pull request #122](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/122): Testng | Improving databases: password fix and type selection
[20:18:21]
<lapineige> *(sorry for dumping the todo list here, but I believe it's important to document that more widely than just in my head/computer 🙂)*
[20:19:19]
<lapineige> I'll try to present something during the next YNH meeting (on sep 7th), if you wish to discuss it during it 😉
[20:20:57]
<lapineige> _(sorry for dumping the todo list here, but I believe it's important to document that more widely than just in my head/computer 🙂)_ <- those streched emojis are scary, aren't they ? 😅
[20:25:38]
<lapineige> Oh I think I forgot to clarify what the goal of that tool: I'm make a "_Yunohost App Generator_" to automate as much as possible app packaging. _Yunohosting Yunohost packaging, in some way 😁_
So know those lines that you need to adjust in 4 to 5 different files for each change (and always forget to) ? This in particular is the target.
And also to make it a bit more user friendly, with less technical stuff to do to prepare a basic, working version of one app. It could be as much of a (light) tutorial as an app builder.
That is my aim for now at least, but let me know of this could be integrated in a bigger picture in Yunohost project 🙂
[20:27:22]
<lapineige> Aleks (he/him/il/lui): in particular I'm wondering how could this interfere with packaging v3 and the goal to automate even more packaging steps by simply declaring necessary element (I mean it could be manifest lines as well as checkboxes to tick in a webform…)
[20:27:49]
<lapineige> Oh I think I forgot to clarify what the goal of that tool: I'm make a "_Yunohost App Generator_" to automate as much as possible app packaging. _Yunohosting Yunohost packaging, in some way 😁_
So know those lines that you need to adjust in 4 to 5 different files for each change (and always forget to) ? This in particular is the target.
And also to make it a bit more user friendly, with less technical stuff to do to prepare a basic, working version of one app. It could be as much of a (light) tutorial as an app builder.
That is my aim for now at least, but let me know of this could be integrated in a bigger picture in Yunohost project 🙂
Oh and it's going to be a webapp (that could run locally too, but that's not the main goal).
[20:28:49]
<Aleks (he/him/il/lui)> that doesn't interfere with packaging v3, it just means we'll need to adapt it later to package apps in v3 format rather than v2, which should be simpler
[20:47:42]
<lapineige> Alright, I'm getting close to have a first version that can generate a complete app (scripts and basic config files, not docs), one that I could put a demo online.
There is still plenty of work (non exhaustive list):
- add the dependencies part, with all the extra apt repository stuff and so on
- add some options to configure php
- add some options to configure nodeJS
- add some options to configure _whatever frequent tool is used by many apps_
- add all the documentations options and files
- add some code to generate and download a whole _.zip_ archive instead of getting the files one by one
- and a bunch of minor fixes a bit everywhere
- Rethink about how an app is (supposed to be) made and what options to implement, how to do it in the simplest way, maybe how to make it easier to understand… (example: how to configure php version and dependencies without conflicts nor doing it twice…
- Design how the form should be organised, to be (in no particular order) 1) fast & efficient 2) clear 3) able to teach people about how an app work and is packaged ? 4)
- Maybe rethink some of the hints that are gave in the comments, considering how this new packaging tool could change the way they are understood, and maybe add (migrate ?) some of them in the online interface)
- Do all the CSS stuff to make it look like a proper (ynh-ish) form.
- and some extra CSS to make it look good, later on ?
- \[later on\] doing the translation stuff. That could be started now, but I won't invest my time on it yet.
- \[later on\] I'd love to implement something that shows how a particular option will affect the final code. Like a preview screen, for any (relevant ?) option. Best way to learn about app packaging
- \[later on\] write some documentation (it needs to way for a proper, stable working version)
I did not publish the code yet as it's still very messy, full of dead tests and experiments, and not ready to generate a basic working app. I don't know yet when I will put it online (which would complicate stuff on my side if I'm working alone).
If anyone is willing to help me with this app generator and available in the comming days, please reach out 🙂.
They are task that do not require (much) developpement skills (but quite some knowledge about how apps are made, for most of them). And some that are out of my skills, such as the accessibility part. On all design tasks, this is not something I should decide alone, it would require at least some core members 🙂
[20:48:11]
<lapineige> Alright, I'm getting close to have a first version that can generate a complete app (scripts and basic config files, not docs), one that I could put a demo online.
There is still plenty of work (non exhaustive list):
- add the dependencies part, with all the extra apt repository stuff and so on
- add some options to configure php
- add some options to configure nodeJS
- add some options to configure _whatever frequent tool is used by many apps_
- add all the documentations options and files
- add some code to generate and download a whole _.zip_ archive instead of getting the files one by one
- and a bunch of minor fixes a bit everywhere
- Rethink about how an app is (supposed to be) made and what options to implement, how to do it in the simplest way, maybe how to make it easier to understand… (example: how to configure php version and dependencies without conflicts nor doing it twice…
- Design how the form should be organised, to be (in no particular order) 1) fast & efficient 2) clear 3) able to teach people about how an app work and is packaged ? 4)
- Maybe rethink some of the hints that are gave in the comments, considering how this new packaging tool could change the way they are understood, and maybe add (migrate ?) some of them in the online interface)
- Do all the CSS stuff to make it look like a proper (ynh-ish) form.
- and some extra CSS to make it look good, later on ?
- \[later on\] doing the translation stuff. That could be started now, but I won't invest my time on it yet.
- \[later on\] I'd love to implement something that shows how a particular option will affect the final code. Like a preview screen, for any (relevant ?) option. Best way to learn about app packaging
- \[later on\] write some documentation (it needs to way for a proper, stable working version)
I did not publish the code yet as it's still very messy, full of dead tests and experiments, and not ready to generate a basic working app. I don't know yet when I will put it online (which would complicate stuff on my side if I'm working alone).
If anyone is willing to help me with this app generator and available in the comming days, please reach out 🙂.
They are task that do not require (much) developpement skills (but quite some knowledge about how apps are made, for most of them). And some that are out of my skills, such as the accessibility part. On all design tasks, this is not something I should decide alone, it would require at least some core members 🙂
[21:25:19]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean [commented](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#discussion_r1312291316) on pull request #228 fix maintenance: suggestion ynh_print_info "Maintenance mode disabled"
[21:25:20]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean edited review [pull request #228](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#pullrequestreview-1605783323): fix maintenance
[21:25:21]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean [commented](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#discussion_r1312296916) on pull request #228 fix maintenance: suggestion ynh_exec_as "app" echo "Site under maintenance." > install_dir/.maintenance)
[21:25:25]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean [commented](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#discussion_r1312288855) on pull request #228 fix maintenance: suggestion ynh_print_info "Maintenance mode enabled"
[21:25:29]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean changes_requested [pull request #228](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#pullrequestreview-1605783323) fix maintenance: Additionally, somehow the __PHPVERSION__ in the FPM config file gets replaced by 7.4 instead of 8.2 while running ...
[21:25:43]
<Yunohost Git/Infra notifications> [wordpress_ynh] @tituspijean edited a [comment](https://github.com/YunoHost-Apps/wordpress_ynh/pull/228#discussion_r1312296916) on pull request #228 fix maintenance: suggestion ynh_exec_as "app" echo "Site under maintenance." > install_dir/.maintenance
[21:30:01]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin merged [pull request #124](https://github.com/YunoHost-Apps/my_webapp_ynh/pull/124): Conditional block for POST_INSTALL.md
[21:30:02]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin pushed 5 commits to testing ([f65d02d7d04b...a0a8d326d0d0](https://github.com/YunoHost-Apps/my_webapp_ynh/compare/f65d02d7d04b...a0a8d326d0d0))
[21:30:59]
<Yunohost Git/Infra notifications> [my_webapp_ynh] @alexAubin deleted branch jinja-doc
[21:30:59]
<Yunohost Git/Infra notifications> [my_webapp_ynh/testing] Merge pull request #124 from YunoHost-Apps/jinja-doc Conditional block for POST_INSTALL.md - Alexandre Aubin