[08:35:31]
<Salamandar> Hey, is anyone working on a "systemd service" resource ? I'm starting to brainstorm on it, but if work already startedd…
[09:21:01]
<Salamandar> Aleks (he/him/il/lui): What are you feeling about helpers retrieving info from the manifest ?
Like, if I add this in the manifest.toml:
```toml
[resources.service]
[resources.service.main]
log_path = "/var/log/__APP__/__APP__.log"
start.line_match = "Starting application"
start.timeout = 20
stop.line_match = "Application stopped"
[resources.service.secondary]
service = "myapp_secondary"
template = "myapp_secondary_template"
description = "Myapp secondary service for something"
add_to_yunohost = false
```
[09:21:24]
<Salamandar> then calls to `ynh_systemd_action_start`would use the start.line_match and timeout as default values
[09:22:58]
<Aleks (he/him/il/lui)> hmmm yes that could indeed be an intermediate step towards packaging v3
[09:23:39]
<Aleks (he/him/il/lui)> but if we do this ideally we should really try designing the syntax not just for systemd conf but also nginx, php, fail2ban, logrotate and other classic stuff i'm forgetting about
[09:23:54]
<Salamandar> > packaging v3
wait wat
[09:24:02]
<Salamandar> > <@Alekswag:matrix.org> but if we do this ideally we should really try designing the syntax not just for systemd conf but also nginx, php, fail2ban, logrotate and other classic stuff i'm forgetting about
Agreed !
[09:24:28]
<Aleks (he/him/il/lui)> and we could even have helpers like `ynh_add_all_system_configs` (just throwing a random name) and same stuff for backup and restore
[09:24:47]
<Salamandar> > <@Alekswag:matrix.org> and we could even have helpers like `ynh_add_all_system_configs` (just throwing a random name) and same stuff for backup and restore
o/
[09:25:39]
<Salamandar> TBH i really like the PKGBUILD format of Archlinux
[09:25:53]
<Salamandar> with their *functions* (build, install etc)
[09:26:02]
<Aleks (he/him/il/lui)> ah, do you have a link ?
[09:26:28]
<Salamandar> What I mean is that we usually do the same thing in install/upgrade/restore
[09:26:45]
<Salamandar> hmm
[09:26:57]
<Salamandar> https://man.archlinux.org/man/PKGBUILD.5#EXAMPLE
[09:27:28]
<Salamandar> > <@Salamandar:matrix.org> What I mean is that we usually do the same thing in install/upgrade/restore
And sometimes I think I should code the whole "smarty-customy-packaging-things" in the _common.sh and just call functions in the other scripts
[09:27:50]
<Aleks (he/him/il/lui)> looks like a bash script with bash arrays ? (the `foo=(bar)` syntax ? or am i mistaking ?
[09:28:09]
<Salamandar> And with this logic : yunohst packages could be just functions, and yunohost just decides to call function X at the proper time
[09:28:55]
<Salamandar> > <@Alekswag:matrix.org> looks like a bash script with bash arrays ? (the `foo=(bar)` syntax ? or am i mistaking ?
Yeah, the declarative part (up to the md5 line in the link I sent to you) is basically the manifest.toml part of a yunohost package
[09:29:19]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> What I mean is that we usually do the same thing in install/upgrade/restore
yes the point of packaging v3 will be to address this among other things and have `build` and `install` or `initialize-app` or `migrate` steps (still to be defined exactly) ideally not running as root, and possibly with hooks like `_before_build` or `_after_build` etc running as root for stuff that definitely need root
[09:29:35]
<Salamandar> > <@Alekswag:matrix.org> yes the point of packaging v3 will be to address this among other things and have `build` and `install` or `initialize-app` or `migrate` steps (still to be defined exactly) ideally not running as root, and possibly with hooks like `_before_build` or `_after_build` etc running as root for stuff that definitely need root
Oh yeah, that's probably something I'll like
[09:29:47]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> And with this logic : yunohst packages could be just functions, and yunohost just decides to call function X at the proper time
yup definitely heading this way
[09:30:55]
<orhtej2> Is packaging v3 meant to address redundancy between `install`, `upgrade` and partially `change_url` as well?
[09:31:19]
<Aleks (he/him/il/lui)> yes that's basically what we were discussing
[09:31:35]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/issues/issues/2136
[09:31:41]
<Aleks (he/him/il/lui)> >Handle system confs declaratively, similar to the work done on resources
[09:31:49]
<Aleks (he/him/il/lui)> >Rework the entire install/remove/upgrade/backup/restore paradigm, probably with a build/init/migrate?/?? paradigm where we limit the number of stuff ran as root
[09:32:36]
<orhtej2> > <@Alekswag:matrix.org> https://github.com/YunoHost/issues/issues/2136
Amazing stuff!
[09:34:31]
<Salamandar> Alright
[09:34:34]
<Salamandar> Thanks for the link
[09:34:39]
<Salamandar> thats looks perfect
[09:35:06]
<Aleks (he/him/il/lui)> and not really explicitly mentionned in the wishlist is being able to exploid the "build" step to pre-build stuff on our infra and ideally host the result on our infra to avoid end-users/admins having to build all the stuff locally (of course ideally that kind of stuff should be handled by the upstreams but zzzz of course not all of them do ship prebuild stuff)
[09:35:21]
<Salamandar> > Mandatory systemd hardening ?
Pliz no : some apps require to be non-secure (wetty for example)
[09:36:38]
<Aleks (he/him/il/lui)> hmmkay but it should be like the exception rather than the norm, we can find something like "privileged = true" or idk what kind of semantics
[09:38:38]
<orhtej2> > <@mrfloss:matrix.org> Hello, I may have a problem with upgrades in `yeswiki_ynh` : is the function `ynh_setup_source --dest_dir="$install_dir"` removing files of previous version before copying new files from source?
>
> After updating yeswiki, yunohost users still have files that were deleted from one version to another cf. https://github.com/YesWiki/yeswiki/issues/1097
it is not unless you specify `--full_replace=1`
[09:39:15]
<tituspijean> cf. https://yunohost.org/en/packaging_apps_helpers#ynh-setup-source ;)
[09:40:03]
<mrflos> and another small question about app upgrades in yunohost: will changes in manifest.toml (i'm adding a deb package) be handled while upgrading ?
[09:45:17]
<mrflos> > <@titus:pijean.ovh> cf. https://yunohost.org/en/packaging_apps_helpers#ynh-setup-source ;)
ok thanks, so i can combine --full-replace and --keep='wakka.config.php files/ custom/ themes/' ?
[09:46:04]
<orhtej2> > <@mrfloss:matrix.org> ok thanks, so i can combine --full-replace and --keep='wakka.config.php files/ custom/ themes/' ?
I vote yes: https://github.com/YunoHost/yunohost/blob/ec6bf12a7479871831eb78380a4c28e8347d5577/src/utils/resources.py#L1069C9-L1069C9
[09:46:32]
<orhtej2> aka it'll call `apt install new list of dependencies` and `apt` itself will figure out what's added and what's already in
[09:46:46]
<orhtej2> althought IDK what happens to orphaned dependencies
[09:47:15]
<orhtej2> or actually I do, it does not install anything, it merely creates phony package that gathers deps for app and `apt` will know something is installed but no longer referenced
[09:48:14]
<orhtej2> so `sudo apt --autoremove purge` will then pick these up and remove
[09:51:36]
<mrflos> > so `sudo apt --autoremove purge` will then pick these up and remove
ok thanks for those awesome precisions, i'm just adding a package so i think i can pass for cleaning
[09:52:43]
<orhtej2> > <@mrfloss:matrix.org> ok thanks, so i can combine --full-replace and --keep='wakka.config.php files/ custom/ themes/' ?
yes, you can combine `keep` with `full_replace`
[09:54:17]
<Yunohost Git/Infra notifications> [issues] @kay0u [commented](https://github.com/YunoHost/issues/issues/2050#issuecomment-1713558330) on [issue #2050](https://github.com/YunoHost/issues/issues/2050) Support Debian 12 "Bookworm": During the postinstall I get: > Warning: ls: cannot access /etc/php/*/fpm/pool.d/*.conf: No such file or directory War...
[10:02:27]
<orhtej2> > yes, you can combine `keep` with `full_replace`
(you can always back the app up and run such monstrosity on your own test instance before pushing to master in case doc =/= actual behaviour :P)
[10:02:38]
<Aleks (he/him/il/lui)> mrflos:
> and another small question about app upgrades in yunohost: will changes in manifest.toml (i'm adding a deb package) be handled while upgrading ?
Yes the idea of stuff declared in the manifest (in particular resources) is that YunoHost core should automagically provision/update/deprovision whatever is needed or not needed anymore
[10:03:51]
<mrflos> > (you can always back the app up and run such monstrosity on your own test instance before pushing to master in case doc =/= actual behaviour :P)
where is the fun in that? i will test on production, i like to live dangerously! (just kiddin' 😉 )
[10:04:18]
<orhtej2> https://aria.im/_matrix/media/v1/download/circledsquareroot.ovh/2289b504abbf564bef1b48f6ffea0312c23f59d3895f0bea06de3dcf5378c31e
[10:06:34]
<Aleks (he/him/il/lui)> https://i.imgflip.com/7yq4mq.jpg
[10:10:08]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> Aleks (he/him/il/lui): What are you feeling about helpers retrieving info from the manifest ?
> Like, if I add this in the manifest.toml:
>
> ```toml
> [resources.service]
> [resources.service.main]
> log_path = "/var/log/__APP__/__APP__.log"
> start.line_match = "Starting application"
> start.timeout = 20
> stop.line_match = "Application stopped"
>
> [resources.service.secondary]
> service = "myapp_secondary"
> template = "myapp_secondary_template"
> description = "Myapp secondary service for something"
> add_to_yunohost = false
> ```
so btw to conclude the discussion : i'd say feel free to work on a specification / POC and then we can iterate ... there are probably dozens of micro-design decisions .... like i don't know if we want to have all of these in `resources` or add a new `configurations` block etc
[10:10:19]
<tituspijean> https://aria.im/_matrix/media/v1/download/pijean.ovh/0b6cee7a3bd3ae8e2c8a3d204441b3434323b77625623111a75143921a9ff5a1
[10:10:43]
<Salamandar> By the way, one change I would really see in the manifest:
Lists everywhere !
Like, why is there only one data_dir possible ? I would love a simple "directory" resource, that could cover install_dir, data_dir, log_dir, config_dir,…
[10:11:17]
<Salamandar> > <@Alekswag:matrix.org> so btw to conclude the discussion : i'd say feel free to work on a specification / POC and then we can iterate ... there are probably dozens of micro-design decisions .... like i don't know if we want to have all of these in `resources` or add a new `configurations` block etc
Agreed. One thing I can't see how to do for now, is to systemctl start the service at the end of the install script, like nginx
[10:22:18]
<Aleks (he/him/il/lui)> but not sure why you'd want to start it at the end of the install script, imho this should be done inside the new `ynh_add_all_confs`
[10:22:18]
<Aleks (he/him/il/lui)> ah yes that part is a bit tricky, i don't know if we should do this automagically or not, it might be related to the way the app is configured at the end of install/upgrade idk
[10:22:19]
<Salamandar> > <@Alekswag:matrix.org> ah yes that part is a bit tricky, i don't know if we should do this automagically or not, it might be related to the way the app is configured at the end of install/upgrade idk
Ah yes, I could add a "autostart" key in the resource
[10:22:21]
<Salamandar> But in any case, I can't find where this is done for nginx
[10:23:10]
<Aleks (he/him/il/lui)> imho we should end up with something like this in e.g. the install script:
1. ynh_setup_source and whatever npm install / pip install / ... to "build" the app
2. ynh_add_all_confs
3. init/finalize the app configuration
4. ???
5. profit!
[10:23:17]
<Aleks (he/him/il/lui)> nginx is reloaded after `ynh_add_nginx_config`
[10:23:18]
<Salamandar> ok
[10:23:18]
<Salamandar> > <@Alekswag:matrix.org> i'm not sure there's an nginx reload after the install script is ran ... there's no reason to reload nginx, it's already reloaded after the conf is added
haaa
[10:23:18]
<Aleks (he/him/il/lui)> ah
[10:23:18]
<Salamandar> I thought some auto-reload at the end of the install script was added in the manifestv2 ?
[10:23:18]
<Aleks (he/him/il/lui)> there's no reason to reload nginx if the conf didnt change
[10:23:18]
<Salamandar> > <@Alekswag:matrix.org> https://github.com/YunoHost/yunohost/blob/dev/helpers/nginx#L33
Nah, I mean the auto-reload at the end of the install script
[10:23:18]
<Aleks (he/him/il/lui)> i'm not sure there's an nginx reload after the install script is ran ... there's no reason to reload nginx, it's already reloaded after the conf is added
[10:23:18]
<Aleks (he/him/il/lui)> https://github.com/YunoHost/yunohost/blob/dev/helpers/nginx#L33
[10:23:24]
<Salamandar> ah that might have been php
[10:23:53]
<Salamandar> Or did I just dream of something like that ?
[10:24:05]
<Aleks (he/him/il/lui)> i don't think so, it's just that for some reason many apps did have an hard-coded nginx reload at the very end of the script, but I never understood why so it got removed by the auto conversion script v1->v2
[10:24:36]
<Salamandar> > <@Alekswag:matrix.org> i don't think so, it's just that for some reason many apps did have an hard-coded nginx reload at the very end of the script, but I never understood why so it got removed by the auto conversion script v1->v2
ah ! OK, that's probably where my belief comes from
[10:24:42]
<Salamandar> thanks for the precision
[10:26:30]
<Aleks (he/him/il/lui)> also related to the discussion about having some sort of `ynh_add_all_configurations` : it would in fact be nice to have some sort of `yunohost app regen-conf $app`, because this can be practical in many other situations than just install / upgrade ... and it would also allow to implement the logic in python rather than shell (which is more convenient to handle all the toml parsing etc)
[10:27:06]
<Aleks (he/him/il/lui)> (even tho it may just call a bunch of bash helpers like we already do for resources)
[10:28:44]
<Salamandar> the resources.script would call the build_app function declared in, let's say, _common.sh
[10:28:56]
<Salamandar> and variables would be a list of variables defined in the build_app function ?
[10:29:13]
<Salamandar> I have something in mind too, but more "declarative":
```
[resources]
[resources.system_user]
[resources.install_dir]
[resources.data_dir]
[resources.permissions]
[resources.ports]
[resources.apt]
[resources.database]
[resources.sources]
...
[resources.script]
function = "build_app"
variables = ["app_static_dir", "secret_key"]
[resources.nginx]
# This file could have `__APP_STATIC_DIR__` in it!!!
[resources.systemd_service]
```
[10:29:41]
<Aleks (he/him/il/lui)> hmmm could be but you're going full-packaging-v3 haha
[10:29:49]
<Salamandar> I have something in mind too, but more "declarative":
```
[resources]
[resources.system_user]
[resources.install_dir]
[resources.data_dir]
[resources.permissions]
[resources.ports]
[resources.apt]
[resources.database]
[resources.sources]
...
[resources.script]
function = "build_app"
variables = ["app_static_dir", "secret_key"]
[resources.config]
# This file could have `__SECRET_KEY__` in it!
template = "myapp.ini"
[resources.nginx]
# This file could have `__APP_STATIC_DIR__` in it!!!
[resources.systemd_service]
```
[10:30:04]
<Salamandar> oh yes, that's not something I want to backport to packaging v2
[10:30:09]
<Aleks (he/him/il/lui)> also keep in mind that it's not just about building/installing the app, you want all the appropriate semantic to be able to know what to do during backup/restore/remove etc
[10:30:16]
<Aleks (he/him/il/lui)> ie you don't want to run the build script in that case
[10:30:22]
<Salamandar> > <@Salamandar:matrix.org> I have something in mind too, but more "declarative":
>
> ```
> [resources]
> [resources.system_user]
> [resources.install_dir]
> [resources.data_dir]
> [resources.permissions]
> [resources.ports]
> [resources.apt]
> [resources.database]
> [resources.sources]
> ...
> [resources.script]
> function = "build_app"
> variables = ["app_static_dir", "secret_key"]
> [resources.config]
> # This file could have `__SECRET_KEY__` in it!
> template = "myapp.ini"
> [resources.nginx]
> # This file could have `__APP_STATIC_DIR__` in it!!!
>
> [resources.systemd_service]
>
> ```
And of course, in this, order would be important
[10:30:49]
<Salamandar> > <@Alekswag:matrix.org> also keep in mind that it's not just about building/installing the app, you want all the appropriate semantic to be able to know what to do during backup/restore/remove etc
Yes ! resources.script could have a "on_backup", "on_restore" key
[10:31:15]
<Salamandar> (usually on restore you don't run scripts, but you might need some additional system config)
[10:31:30]
<Aleks (he/him/il/lui)> hmmmyeah but we're basically gonna have a "build" script for a majority of apps so we clearly want to have some sort of standardized semantic for the build script
[10:31:59]
<Salamandar> The problem I'm trying to "solve" here is that you often need to install files (systemd config) AFTER the script ran and defined a bunch of variable to replace in the config file
[10:32:10]
<Aleks (he/him/il/lui)> ugh
[10:32:30]
<Salamandar> And I don't know how you expect to solve that ?
[10:32:54]
<Salamandar> (that's a shitty problem ah ah)
[10:34:43]
<Aleks (he/him/il/lui)> not sure exactly what you mean but cf my previous stuff about having that kind of structure:
1. call ynh_setup_source, npm install / pip install whatever (and define a bunch of variables)
2. call ynh_add_all_configurations / yunohost app regen-conf $app (then at that step you have variables defined)
3. finalize the app configuration with curl and whatever
[10:34:44]
<Salamandar> (well maybe I should join your packaging v3 brainstorming sessions instead of trying to find solution to problems you're already working on 😄 )
[10:36:06]
<Aleks (he/him/il/lui)> and of course my previous message is still in the context of having an `install` script etc ... but for packaging v3 we shall define some sort of `build` function somewhere that will be called between the "provision resources" and "add configurations" steps
[10:37:03]
<Salamandar> > <@Alekswag:matrix.org> not sure exactly what you mean but cf my previous stuff about having that kind of structure:
> 1. call ynh_setup_source, npm install / pip install whatever (and define a bunch of variables)
> 2. call ynh_add_all_configurations / yunohost app regen-conf $app (then at that step you have variables defined)
> 3. finalize the app configuration with curl and whatever
hmmm alright, but configuration files might need variables that are "difficult" to set. Ihatemoney has a "hashed password" that needs a custom script. I saw another app (dunno which) that requires to **start the app**, retrieve a secret generated by the app via a curl command, and set the secret in another config file
[10:37:12]
<Aleks (he/him/il/lui)> also we should keep exploring what to do for "settings which are to be defined but ain't coming from an install question", cf. also the whole story with config panels ...
[10:37:31]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> hmmm alright, but configuration files might need variables that are "difficult" to set. Ihatemoney has a "hashed password" that needs a custom script. I saw another app (dunno which) that requires to **start the app**, retrieve a secret generated by the app via a curl command, and set the secret in another config file
ugh yeah ...
[10:37:51]
<Salamandar> A bit like matrix appservices in fact
[10:37:56]
<Aleks (he/him/il/lui)> that's when design is confronted to reality and the actual work begins ;P
[10:38:06]
<Salamandar> > <@Alekswag:matrix.org> that's when design is confronted to reality and the actual work begins ;P
haha 😄
[10:38:49]
<Aleks (he/him/il/lui)> maybe that's just for "app-specific configs" (compared to "system configs" like nginx / php / systemd) and we can handle them differently somehow idk
[10:39:51]
<Salamandar> A friend of mine's (you saw him at JDLL i think) has been trying to do "pretty" software, and by pretty I mean "technical beauty". And some time ago he kind of had a disillusion moment, when he decided technical beauty is incompatible with usefulness and efficiency
[10:40:33]
<Salamandar> so… yeah… beautiful software design ideas VS "reality sand grains" in the machine…
[10:41:00]
<Aleks (he/him/il/lui)> yup, reality is a mess
[10:42:51]
<Salamandar> Oh
[10:43:14]
<Salamandar> completely different subject but my file editor's syntax coloring found a syntax error in the utils helper file ?
[10:43:29]
<Salamandar> ```
local expression_with_comment="$((tail +$line_number ${file} | grep -i -o -P $var_part'\K.*$' || echo YNH_NULL) | head -n1)"
```
missing `$`before the second `(` ?
[10:56:05]
<Aleks (he/him/il/lui)> eeeh, i'm not sure `$((foo) | bar)` is an acceptable syntax
[10:56:16]
<Aleks (he/him/il/lui)> to me it should be `$((foo | bar))` ?
[10:56:29]
<Aleks (he/him/il/lui)> oor
[10:56:43]
<Aleks (he/him/il/lui)> or `$(foo | bar)` ?
[10:56:55]
<Aleks (he/him/il/lui)> `$(( ... ))` is for numeric operations
[10:59:50]
<Aleks (he/him/il/lui)> or like if you want to group commands imho you should use `$( { foo; bar; baz;} | head -n 1)`
[11:00:37]
<Aleks (he/him/il/lui)> (i never remember the syntax for `{ foo; bar;}` like you absolutely do need (or must not) put a space between the last `;` an `}`...
[11:03:46]
<Salamandar> I think it's supposed to be `$($(somethingn) | somethingelse)`
[11:06:21]
<Salamandar> after some testing : that's incredible, `$((foo) | bar)` works
[11:06:55]
<Salamandar> just… my text editor thinks it's the beginning of a math expression… so syntax coloring is broken 😄
[11:10:05]
<Aleks (he/him/il/lui)> > <@Salamandar:matrix.org> I think it's supposed to be `$($(somethingn) | somethingelse)`
eeeh im not sure because `$(foo) | bar` is equivalent to writing `"some stdout" | bar`, like, you can't pipe a string into a command
[11:16:17]
<Salamandar> Yeah but ( tail ) is just running tail in a subshell
[11:16:59]
<Salamandar> It's just useful for the || echo YNH_NULL
[11:17:47]
<Salamandar> Without the || it's equivalent to var=$( tail | grep | head)
[11:18:40]
<Salamandar> Oh sorry misread your message. Yeah it's not $( $(foo) | bar)
[11:25:41]
<Aleks (he/him/il/lui)> ah yeah my bad haha
[17:27:30]
<mrflos> > sent an image.
epilogue : the PR seems to work (CI is happy), but i noticed that the folders from https://github.com/YunoHost-Apps/yeswiki_ynh/pull/68/files#diff-57aeb84da86cb7420dfedd8e49bc644fb799d5413d01927a0417bde753e8922fR28 are restored inside the target folder : `files/` is not restored as `files/` but as `files/files`
[17:29:10]
<mrflos> i suppose that the trailing `/` is not a good idea in my declaration, but i just followed the example pointed by tituspijean (a wise man once said, you can rtfm only if the manual is right)
[17:29:41]
*tituspijean hides in the bush like Homer
[17:32:31]
<mrflos> should i test again without trailing / and try to update doc?
[17:40:22]
<mrflos> ok it works! without the trailing /
[17:50:17]
<mrflos> and https://github.com/YunoHost/doc/pull/2331
I have'nt read any contribution guide about the doc, this is a yolo PR in older to battle the iron while it is still hot
[18:49:23]
<orhtej2> > <@mrfloss:matrix.org> and https://github.com/YunoHost/doc/pull/2331
> I have'nt read any contribution guide about the doc, this is a yolo PR in older to battle the iron while it is still hot
That was the issue? Nice 👍
[18:51:15]
<mrflos> > That was the issue? Nice 👍
yes, first i made some typos in the parameter names, and the trailing slash was restoring files in the wrong place, now all is good!
[19:57:57]
<Yunohost Git/Infra notifications> [issues] @Tagadda [commented](https://github.com/YunoHost/issues/issues/2242#issuecomment-1714493797) on [issue #2242](https://github.com/YunoHost/issues/issues/2242) Wrong logrotate config perms: To intensify confusion, I can say that I have two apps installed between July 6th and July 28th that have similar permis...
[20:20:58]
<Yunohost Git/Infra notifications> [yunohost] @Tagadda approved [pull request #1696](https://github.com/YunoHost/yunohost/pull/1696#pullrequestreview-1620769178) trigger hooks when adding or removing user into group: Looks good
[21:27:10]
<Émy - OniriCorpe> > <@oniricorpe:im.emelyne.eu> the CI warns me
>
> > ! (Requires Yunohost 4.3) When using ynh\_exec\_\*, please don't wrap your command between quotes (typically DONT write ynh\_exec\_warn\_less 'foo --bar --baz')
>
> but i don't have quoted code after a `ynh_exec_*`, my line starts with a quote and ends with a quote, but isn't quoted:
> `ynh_exec_warn_less "$final_path"/gotosocial --config-path "$final_path/config.yaml" admin account promote --username "$admin"`
> my code is clean, so I shouldn't be warned
should I open an issue?
[22:48:53]
<Yunohost Git/Infra notifications> [yunohost] @yorffuoj opened [pull request #1713](https://github.com/YunoHost/yunohost/pull/1713): The p value of a DMARC record can take the values none, quarantine or reject
[22:54:50]
<Yunohost Git/Infra notifications> [yunohost] @yorffuoj edited [pull request #1713](https://github.com/YunoHost/yunohost/pull/1713): The p value of a DMARC record can take the values none, quarantine or reject