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

[07:56:59] <Yunohost Git/Infra notifications> [package_linter] @selfhoster1312 [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1715196949) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: Personal opinion: its better to have one canonical way that is easier to lint/support. Theres already many ways to do ...
[11:20:00] <Yunohost Git/Infra notifications> [package_linter] @alexAubin [commented](https://github.com/YunoHost/package_linter/issues/123#issuecomment-1715533007) on [issue #123](https://github.com/YunoHost/package_linter/issues/123) bad_ynh_exec_syntax() false positive: Rough guess but thats probably because you have : ynh_exec_warn_less "final_path"/gotosocial [...] and I would in...
[12:32:39] <Yunohost Git/Infra notifications> [package_linter] @alexAubin [commented](https://github.com/YunoHost/package_linter/issues/119#issuecomment-1715636110) on [issue #119](https://github.com/YunoHost/package_linter/issues/119) manifest: packages processing should match yunohost: Really I can only reinstate that there are a gazillion more important things to do This specific issue is just the tree...
[13:16:39] <lejocelyn> yalh76: https://forum.yunohost.org/t/overleafs-features-currently-missing-or-not-functionning-in-yunohosts-package/21873
[13:18:25] <lejocelyn> yalh76: I'd pay for these features if the amount I can pay was not ridiculous regarding the salary of a dev/packager :/
[14:00:02] <Tag> flute de zut je ne comprends pas /o\
`./upgrade: line 60: service: unbound variable` but that's exactly what I want to check here https://github.com/YunoHost-Apps/mastodon_ynh/blob/v2/scripts/upgrade#L59-L63
[14:00:45] <Aleks (he/him/il/lui)> bash.jpg
[14:02:15] <Aleks (he/him/il/lui)> mon internet rame à mort mais à mon avis tu veux check genre `if [[ -z "${foobar:-}" ]]` et pas `if [[ -z "${foobar}" ]]` pour couvrir le cas où la variable existe pas
[14:02:24] <Aleks (he/him/il/lui)> ouai
[14:02:27] <Tag> ah yes, je vais tenter ça. actuellement j'ai `if [[ -z "$service" ]]; then`
[14:04:08] <Aleks (he/him/il/lui)> pareil pour les autres if avant d'ailleurs
[14:05:01] <Aleks (he/him/il/lui)> d'ailleurs on devrait mettre un truc dans le linter genre pour les apps v2 car on a sans doute oublié plein de fois de mettre la bonne syntax, ça coule pas du tout de source ...
[14:05:30] <Tag> Je vais les virer de toute façon, je pense que personne n'upgrade depuis une version si vieille (j'espère...)
[14:15:14] <Salamandar> looks like CI runners are broken
[14:15:17] <Salamandar> > Lock for worker 6 still exist ... trying to cleanup the old package check still running ...
[14:15:36] <Salamandar> Oh, it finally started, sorry for the noise 😄
[14:31:16] <eric_G> I think those warning in diagnosis about app being flagged as broken should be removed or displayed differently. -> https://forum.yunohost.org/t/peertube-broken-and-cannot-install-matomo/26250/5
[14:34:46] <Aleks (he/him/il/lui)> you mean like explicitly stating that the current install is probably still functionnal and the issue is only about a flag in the catalog ?
[14:39:03] <Aleks (he/him/il/lui)> idk what to say to that person in the thread ... the app is currently flagged as broken, therefore can't be installed, period, if it could be installed, it wouldnt be flagged as broken x_x
[15:54:40] <rodinux> I have a unresolved trick with the paheko app. I have pushed some future release candidate on the testing branch and do local tests on a virtual machine. But after discussion with the developer, some files are still on the $install_dir but should be removed after the upgrade process... the developer tolds me (in french): «c'est que ton process de mise à jour garde les fichiers des anciennes versions. Ce qui ne devrait pas être le cas bien sûr. Faire un unzip ne suffit pas. c'est documenté dans le process de mise à jour: "Décompresser la nouvelle version dans un nouveau répertoire"»
[15:57:03] <Tag> Ah! You probably need to add --full_replace=1 arg for ynh_setup_source !
[15:58:24] <Tag> That will remove everything inside the install\_dir and unzip the new sources.
You can keep some files and folders with --keep="somefile.db some/folder"
[15:58:38] <rodinux> So in thye upgrade process I think line `ynh_setup_source --dest_dir="$install_dir" --keep="association.sqlite squelettes/ data/ skel-dist/ config.local.user.php"` make a mistake
[15:59:12] <Tag> And I think you should remove the "/" at the end of folders
[15:59:58] <Tag> Something like this : ` ynh_setup_source --dest_dir="$install_dir" --keep="association.sqlite squelettes data skel-dist config.local.user.php" --full_replace=1`
[16:02:17] <rodinux> Thanks, I gonna try !
[16:13:36] <tituspijean> > <@lejocelyn:sans-nuage.fr> yalh76: https://forum.yunohost.org/t/overleafs-features-currently-missing-or-not-functionning-in-yunohosts-package/21873

I've reopened the thread.
[17:47:47] <rodinux> > <@tag:lostpod.me> Something like this : ` ynh_setup_source --dest_dir="$install_dir" --keep="association.sqlite squelettes data skel-dist config.local.user.php" --full_replace=1`

Is not not so easy, it seems broke a CRFS key added in the install script
[17:49:29] <Tag> Il manque peut être des trucs à rajouter dans le `keep` rodinux
[17:49:53] <Tag> euh..? What is the app ? (nvm it's paheko)
[18:01:01] <rodinux> well I found mistakes, sorry
[18:02:43] <Tag> what was it ? 👀
[18:06:51] <rodinux> errors when removing a line, `ynh_add_config --template="config.local.yunohost.php" --destination="$install_dir/config.local.yunohost.php"` I was confused and believe it was the file `config.local.user.php` we want to --keep, so I try remove it, and then I put it again but with the wrong name `config.local.user.php`... stupid
[18:08:20] <Tag> ah! that kind of stuff happen to me a lot 😁
[18:32:49] <rodinux> Ok, I think it should work, I have to do another test but fine, thanks Tag
[18:48:21] <rodinux> Well, it did not keep the files or folders with the next new release, the architecture changed but the worry is the only thing I have to keep is the database `association.squlite`. I think I will need keep on another folder before in /tmp for exemple and mv it later
[18:52:59] <lejocelyn> tituspijean: thanks, but I'm not sure it's useful, unless there is really some interest into those issues by the some people who could update the packet
[19:03:11] <Salamandar> Hmmm… I'm gonna bother people again about packaging v2
[19:03:23] <Salamandar> doc says

> Note that YunoHost will automatically move the old install dir to the new install_dir during the corresponding upgrade.

Alright, so no need to "cp" in the upgrade script.

… but it doesn't move 😢 the gitea data stays in /opt/gitea 😢
[19:08:11] <Salamandar> And indeed, when running the InstallDir provisionning step, i should see

> f"Moving {current_install_dir} to {self.dir}... (this may take a while)"


[19:08:20] <Salamandar> is there any known bug about this ?
[19:15:26] <Aleks (he/him/il/lui)> Not really, might be a bug, yet i thought i wrote a unit test specifically about this maybe
[19:26:30] <Salamandar> 😄
[19:33:37] <Salamandar> ooookay, not a bug. The packaging v1 app did not even define a final_path setting.
[19:33:55] <Salamandar> so obviously, the upgrade process doesn't even know there's a install_dir to move.
[19:34:10] <Salamandar> (i added some logger.debug() in resources.py to find out that)
[19:44:48] <Salamandar> Tag (to reply to your reaction) : yeah, it was a hard coded /opt/__APP__ in the scripts, nothing more
[19:47:54] <Tag> oh i see /o\
[21:28:23] <Yunohost Git/Infra notifications> [apps] @tituspijean commented [pull request #1728](https://github.com/YunoHost/apps/pull/1728#pullrequestreview-1623182305) Add Froxlor to catalog: I am a bit dubious about how this wont clash with our own features and how we handle them.