Friday, July 28, 2023
apps@conference.yunohost.org
July
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
31
           

[01:56:08] <Yunohost Git/Infra notifications> App wekan failed all tests in job [#17398](https://ci-apps.yunohost.org/ci/job/17398) :(
[03:24:58] <Yunohost Git/Infra notifications> [wordpress_ynh] @bishopgodsey opened [issue #222](https://github.com/YunoHost-Apps/wordpress_ynh/issues/222): Upgrade redirects to Yunohost user panel. Uninstall and try to reinstall fails
[06:56:03] <Yunohost Git/Infra notifications> [apps] @ericgaspar created new branch ericgaspar-patch-1
[06:56:04] <Yunohost Git/Infra notifications> [apps] @ericgaspar opened [pull request #1700](https://github.com/YunoHost/apps/pull/1700): Add More ro catalog
[06:56:04] <Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 1 commit to ericgaspar-patch-1: Add More ro catalog ([3d768a84](https://github.com/YunoHost/apps/commit/3d768a84e499050b46915e0e21311a9f6cd0cd5e))
[06:58:21] <lapineige> It is right that this is a PR, I did not realise it first, I thought it was a branch without any information for us (which would have been an issue 😅) and that's not the case, cool 🙂 .
But we had an open issue (here https://github.com/YunoHost-Apps/calckey\_ynh/issues/36) to discuss how to handle the migration, it would have been better to discuss it here.
It's no big deal anyway, I'm mainly asking for more caution next time, please 🙂
[07:07:37] <Yunohost Git/Infra notifications> [apps] @ericgaspar edited [pull request #1700](https://github.com/YunoHost/apps/pull/1700): Add Vore to catalog
[09:27:02] <Yunohost Git/Infra notifications> [apps] @Tagadda approved [pull request #1700](https://github.com/YunoHost/apps/pull/1700#pullrequestreview-1551716375) Add Vore to catalog
[09:58:06] <autra> Tag: still for ruby app, when removing the LD_PRELOAD thing, I have "696128 INFO DEBUG - free(): invalid pointer"
[09:58:22] <autra> For instance here: https://ci-apps-bookworm-dev.yunohost.org/ci/job/14
[09:58:57] <autra> Jemalloc in LD_PRELOAD fixes this, but I don't know if it is the right fix
[10:03:14] <Dante> hey 🙂

So I have a doubt regarding psql, on the mautrix_whatsapp package there are this lines included in the remove script:
```
ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP OWNED BY \"$app\";"
ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP USER \"$app\";"
```
and they throw and error, but I saw that when you actually run `ynh_psql_remove_db --db_user=mautrix_whatsapp --db_name=mautrix_whatsapp` (which should be run by the deprovision step in packaging v2) it runs the same commands as I see in the logs of it, is it the case? would that be enough so I can remove those lines?

[10:23:12] <oufmilo[m]> Hi, I'm still trying to migrate from calckey to firefish,

However, all the scripts I see for the migration don't integrate the v2 packaging and I can't get the app ID.

the command is this one for V1 with the manifest.json

Get the new app id in the manifest

`local new_app_id=$(grep \"id\": ../manifest.toml | cut -d\" -f4)`
I'd like to know how to retrieve the app id with the manifest.toml

Just changing the extension doesn't work.
[10:23:37] <oufmilo[m]> Hi, I'm still trying to migrate from calckey to firefish,

However, all the scripts I see for the migration don't integrate the v2 packaging and I can't get the app ID.
The command is this one for V1 with the manifest.json

Get the new app id in the manifest
`local new_app_id=$(grep \"id\": ../manifest.toml | cut -d\" -f4)`
I'd like to know how to retrieve the app id with the manifest.toml

Just changing the extension doesn't work.
[10:23:51] <oufmilo[m]> Hi, I'm still trying to migrate from calckey to firefish,

However, all the scripts I see for the migration don't integrate the v2 packaging and I can't get the app ID.
The command is this one for V1 with the manifest.json

Get the new app id in the manifest
`local new_app_id=$(grep \"id\": ../manifest.toml | cut -d\" -f4)`

I'd like to know how to retrieve the app id with the manifest.toml
Just changing the extension doesn't work.
[10:24:15] <oufmilo[m]> Hi, I'm still trying to migrate from calckey to firefish,

However, all the scripts I see for the migration don't integrate the v2 packaging and I can't get the app ID.
The command is this one for V1 with the manifest.json

Get the new app id in the manifest
`local new_app_id=$(grep \"id\": ../manifest.json | cut -d\" -f4)`

I'd like to know how to retrieve the app id with the manifest.toml
Just changing the extension doesn't work.
[10:24:40] <oufmilo[m]> Hi, I'm still trying to migrate from calckey to firefish,

However, all the scripts I see for the migration don't integrate the v2 packaging and I can't get the app ID.
The command is this one for V1 with the manifest.json

Get the new app id in the manifest
`local new_app_id=$(grep \"id\": ../manifest.json | cut -d\" -f4)`

I'd like to know how to retrieve the app id with the manifest.toml
Just changing the extension doesn't work.

Thanks for you help 🙏
[10:42:30] <Yunohost Git/Infra notifications> [apps/master] Add More ro catalog - Éric Gaspar
[10:42:30] <Yunohost Git/Infra notifications> [apps/master] Merge pull request #1700 from YunoHost/ericgaspar-patch-1 - Éric Gaspar
[10:42:30] <Yunohost Git/Infra notifications> [apps] @ericgaspar deleted branch ericgaspar-patch-1
[10:42:30] <Yunohost Git/Infra notifications> [apps] @ericgaspar merged [pull request #1700](https://github.com/YunoHost/apps/pull/1700): Add Vore to catalog
[10:42:30] <Yunohost Git/Infra notifications> [apps] @ericgaspar pushed 2 commits to master ([11c3cb3b82a0...9ba4ca34dd52](https://github.com/YunoHost/apps/compare/11c3cb3b82a0...9ba4ca34dd52))
[10:56:05] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur created new branch oldstable
[10:56:05] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur pushed 1 commit to oldstable: Upgrade to 26.0.4 ([3d75fa3f](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/3d75fa3f856a3d00e5f7d59339f3c78aa18a32fb))
[10:56:05] <Yunohost Git/Infra notifications> [nextcloud_ynh] @yunohost-bot pushed 1 commit to oldstable: Auto-update README ([c31d5fe6](https://github.com/YunoHost-Apps/nextcloud_ynh/commit/c31d5fe6880bb95ee0a7faaa00e449c388ef1f8f))
[10:57:59] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur opened [pull request #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592): Oldstable
[10:58:25] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur edited [pull request #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592): 26.0.4 (Oldstable)
[10:58:25] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592#issuecomment-1655491325) on [issue #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592) Oldstable: testme
[10:58:25] <Yunohost Git/Infra notifications> [nextcloud_ynh] @yunohost-bot [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592#issuecomment-1655491363) on [issue #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592) 26.0.4 (Oldstable): :carousel_horse:
[[Test Badge](https://img.shields.io/endpoint?url=https://ci-apps-dev.yunohost.org/ci/api/job/8466/bad...
[10:58:58] <Yunohost Git/Infra notifications> [nextcloud_ynh] @zamentur edited [pull request #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592): 26.0.4 (Oldstable)
[11:15:21] <Yunohost Git/Infra notifications> App peertube goes down from level 8 to 6 in job [#17409](https://ci-apps.yunohost.org/ci/job/17409)
[11:33:45] <orhtej2> Adjusted for TOML, check paths yourself ;)

```
local new\_app\_id=\$(grep "id =" ../manifest.toml | cut -d" -f2)
```
[11:34:00] <orhtej2> Adjusted for TOML, check paths yourself ;)

```sh
local new_app_id=\$(grep "id =" ../manifest.toml | cut -d" -f2)
```
[11:34:11] <orhtej2> ffs cinny
[11:34:20] <orhtej2> Adjusted for TOML, check paths yourself ;)

```sh
local new_app_id=$(grep "id =" ../manifest.toml | cut -d" -f2)
```
[11:34:40] <oufmilo[m]> Yes thank you 🙏 orhtej2
[11:36:32] <orhtej2> > <@thardev:matrix.org> hey 🙂
>
> So I have a doubt regarding psql, on the mautrix_whatsapp package there are this lines included in the remove script:
> ```
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP OWNED BY \"$app\";"
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP USER \"$app\";"
> ```
> and they throw and error, but I saw that when you actually run `ynh_psql_remove_db --db_user=mautrix_whatsapp --db_name=mautrix_whatsapp` (which should be run by the deprovision step in packaging v2) it runs the same commands as I see in the logs of it, is it the case? would that be enough so I can remove those lines?
>

these actually drop entries in Synapse DB itself, not integration-specific DB. These are meant to de-op bridge user and all archived messages if I understand correctly. So no, removing them will remove some functionality IMO
[11:40:03] <orhtej2> > <@thardev:matrix.org> hey 🙂
>
> So I have a doubt regarding psql, on the mautrix_whatsapp package there are this lines included in the remove script:
> ```
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP OWNED BY \"$app\";"
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP USER \"$app\";"
> ```
> and they throw and error, but I saw that when you actually run `ynh_psql_remove_db --db_user=mautrix_whatsapp --db_name=mautrix_whatsapp` (which should be run by the deprovision step in packaging v2) it runs the same commands as I see in the logs of it, is it the case? would that be enough so I can remove those lines?
>

Also, it seems there's a dedicated support room for bridges, perhaps people know more there? #matrix_yunohost:sans-nuage.fr
[11:42:01] <Dante> Yes, thank you, I'll ask there as well and also I'll check manually if removing those is leaving some data or not 🙂
[11:56:25] <orhtej2> > <@thardev:matrix.org> hey 🙂
>
> So I have a doubt regarding psql, on the mautrix_whatsapp package there are this lines included in the remove script:
> ```
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP OWNED BY \"$app\";"
> ynh_psql_execute_as_root --database="$synapse_db_name" --sql="DROP USER \"$app\";"
> ```
> and they throw and error, but I saw that when you actually run `ynh_psql_remove_db --db_user=mautrix_whatsapp --db_name=mautrix_whatsapp` (which should be run by the deprovision step in packaging v2) it runs the same commands as I see in the logs of it, is it the case? would that be enough so I can remove those lines?
>

actually what error is that? There were reports recently that `root` can no longer modify arbitrary databases, perhaps you need to `sudo` as Synapse's user?
[12:11:15] <Aleks (he/him/il/lui)> (NB : depends if you mean "UNIX" root or Mysql root ;P)
[12:15:29] <orhtej2> > <@Alekswag:matrix.org> (NB : depends if you mean "UNIX" root or Mysql root ;P)

Fair point, I assumed it was Unix root here
[12:24:34] <Yunohost Git/Infra notifications> App rocketchat failed all tests in job [#17412](https://ci-apps.yunohost.org/ci/job/17412) :(
[12:38:33] <orhtej2> > <@yunohostinfra:matrix.org> App rocketchat failed all tests in job [#17412](https://ci-apps.yunohost.org/ci/job/17412) :(

another victim of MongoDB :/
[12:42:52] <Aleks (he/him/il/lui)> > another victim of MongoDB :/

hmpf yeah
[12:43:10] <Aleks (he/him/il/lui)> zbgrlmbl i was kind of putting my head under the rug but i'll try having a look @_@
[12:43:48] <Aleks (he/him/il/lui)> > I'm having another problem with the migration from calckey to firefish.
>
> In the migration script, I'm trying to modify this command to adapt it to PSQL
>
> Check if a database exists before trying to move it
> ` if [ -n "$old_db_name" ] && psqlshow | grep -q "^| $old_db_name" `
>
> Thanks for your help 🙏

not sure what you mean the problem is x_x
[12:45:00] <oufmilo[m]> I'm having another problem with the migration from calckey to firefish.

In the migration script, I'm trying to modify this command to adapt it to PSQL

Check if a database exists before trying to move it
`if [ -n "$old_db_name" ] && mysqlshow | grep -q "^| $old_db_name"`

Thanks for your help 🙏
[12:46:12] <Aleks (he/him/il/lui)> what's worrying with the mongodb / mongosh / avx instruction story is also that it impacts users, like i've seen at least one person on the support room or forum with a failing install because of the same issue we have on the CI é_è
[12:46:22] <oufmilo[m]> sorry i've edit the post psqlshow does'nt exist and i don't know how can i replace it
[12:47:10] <Aleks (he/him/il/lui)> do you have a test in mind with the full log displaying the issue you're talking about ? x_x
[12:48:18] <Aleks (he/him/il/lui)> ah so you want the equivalent for Postgresql of "mysqlshow"
[12:48:27] <Aleks (he/him/il/lui)> or rather you want to test if a db exist I suspect ...
[12:48:59] <Aleks (he/him/il/lui)> There's a helper called `ynh_psql_database_exists`
[12:49:57] <Aleks (he/him/il/lui)> eg you should be able to write something like:

```bash
if ynh_psql_database_exists --database=pikachu
then
# do some stuff
fi
```
[12:50:26] <Aleks (he/him/il/lui)> or `if ! ynh_psql_database_exists --database=pikachu` to test if it doesnt exist
[12:53:34] <orhtej2> > <@Alekswag:matrix.org> what's worrying with the mongodb / mongosh / avx instruction story is also that it impacts users, like i've seen at least one person on the support room or forum with a failing install because of the same issue we have on the CI é_è

we could ship no-avx PPA 😈
https://github.com/GermanAizek/mongodb-without-avx
[12:53:50] <Aleks (he/him/il/lui)> ogod
[12:54:43] <orhtej2> there's already YNH PPA, right?
[12:55:02] <Aleks (he/him/il/lui)> a debian repo, yes
[12:55:43] <Aleks (he/him/il/lui)> confusion intensifies ... rocketchat already uses a helper that checks if avx is available and takes supposedly appropriate actions : https://github.com/YunoHost-Apps/rocketchat_ynh/blob/master/scripts/_common.sh#L322
[12:56:14] <Aleks (he/him/il/lui)> (and display warnings ... except that the function is called with `ynh_exec_warn_less` which dumps stderr to trash ...)
[12:57:04] <Aleks (he/him/il/lui)> *packaging v3 intensifies*
[12:57:15] <orhtej2> > <@Alekswag:matrix.org> (and display warnings ... except that the function is called with `ynh_exec_warn_less` which dumps stderr to trash ...)

do you have shell access to runners? or perhaps patch that dumps `/proc/cpuid` to stdout is in order?
[12:57:46] <orhtej2> also that 'mongo without avx' is trivial change to build scripts: https://github.com/GermanAizek/mongodb-without-avx/blob/main/o2_patch.diff
[12:58:30] <Aleks (he/him/il/lui)> @_@
[12:59:42] <Aleks (he/him/il/lui)> (not sure what you want to check with /proc/cpuid, there's already a dump of /proc/cpuinfo in https://ci-apps.yunohost.org/ci/logs/17412.log ... imho the real question is why are we encountering the issue despite that the helper is supposed to take care of it ... though as you(?) mentionned a few days ago, it's also a bit funky to install stuff meant for buster on bullseye)
[13:00:15] <orhtej2> > <@Alekswag:matrix.org> (not sure what you want to check with /proc/cpuid, there's already a dump of /proc/cpuinfo in https://ci-apps.yunohost.org/ci/logs/17412.log ... imho the real question is why are we encountering the issue despite that the helper is supposed to take care of it ... though as you(?) mentionned a few days ago, it's also a bit funky to install stuff meant for buster on bullseye)

I think it was @Gcco
[13:00:29] <Aleks (he/him/il/lui)> > also that 'mongo without avx' is trivial change to build scripts: https://github.com/GermanAizek/mongodb-without-avx/blob/main/o2_patch.diff

i guess we can consider it then @_@ ... what would be cool would be if there's a single .deb we can include in our repositories withtout breaking everything
[13:02:38] <Aleks (he/him/il/lui)> to me it just looks like version 4.4.x of mongodb/mongosh got upgraded by the upstream and now requires awx as well ...
[13:03:58] <orhtej2> > ```
> orhtej2@circledsquareroot:~/usr/bin$ objdump -d mongosh > mongosh.asm
> orhtej2@circledsquareroot:~/usr/bin$ awk '/[ \t](mpsadbw|phminposuw|pmulld|pmuldq|dpps|dppd|blendps|blendpd|blendvps|blendvpd|pblendvb|pblenddw|pminsb|pmaxsb|pminuw|pmaxuw|pminud|pmaxud|pminsd|pmaxsd|roundps|roundss|roundpd|roundsd|insertps|pinsrb|pinsrd|pinsrq|extractps|pextrb|pextrd|pextrw|pextrq|pmovsxbw|pmovzxbw|pmovsxbd|pmovzxbd|pmovsxbq|pmovzxbq|pmovsxwd|pmovzxwd|pmovsxwq|pmovzxwq|pmovsxdq|pmovzxdq|ptest|pcmpeqq|pcmpgtq|packusdw|pcmpestri|pcmpestrm|pcmpistri|pcmpistrm|crc32|popcnt|movntdqa|extrq|insertq|movntsd|movntss|lzcnt)[ \t]/' mongosh.asm
> 15b3371: 66 0f 3a 16 c0 01 pextrd $0x1,%xmm0,%eax
> 15b3451: 66 48 0f 3a 22 6d d8 pinsrq $0x1,-0x28(%rbp),%xmm5
> 15b397d: 66 0f 3a 16 c0 02 pextrd $0x2,%xmm0,%eax
> 18c4543: 66 0f 3a 22 d8 03 pinsrd $0x3,%eax,%xmm3
> 18c4553: 66 0f 3a 22 e2 03 pinsrd $0x3,%edx,%xmm4
> 18c456d: 66 0f 3a 22 e8 03 pinsrd $0x3,%eax,%xmm5
> orhtej2@circledsquareroot:~/usr/bin$
> ```
> OK, `mongosh` 1.10.1 shipped from 4.4 PPA **IS** using AVX, at least according [to my lack of knowledge](https://stackoverflow.com/a/50056059/7034621)

as mentioned here it's `mongosh` not mongo server itself that's failing
[13:05:49] <Aleks (he/him/il/lui)> yeah, hmmm
[13:06:13] <orhtej2> > <@gcco:matrix.org> Mongo Vs Ci-Server episode 10 ! 😀
>
> Summary of the last episodes:
> - Mongodb starting with version 5 requires avx CPU instructions set
> - Mongodb 4.4 is only supported in Debian Buster.
> - Yunohost Ci-Server is running Debian Bullseye in a VM without avx instructions.
>
> So far, installing mongo 4.4 Buster in Ci-Server worked ok.
>
> Since several weeks however, the mongoshell crashes, making Dont-code app, and now Wekan as well, not installable in the Ci-Server.
>
> Trying to install an alternative package (mongodb-mongo-shell-openssl1.1) shows the same behaviour.
>
> So the only solution I see is to bypass installation steps when running on Ci-Server or systems without avx instructions sets.
>
> That defeats a bit the purpose of the Ci-Server as only partial installation will be done here.
>
> What do you guys think?

that's not the package I mentioned actually, I wanted `mongodb-mongosh-shared-openssl3` because this seems to be the package that supplies `mongosh`
[13:06:18] <Aleks (he/him/il/lui)> still feels like it was working before and somehow it spontaneously broke so i'm guessing the upstream pushed a new version of mongo-something
[13:06:26] <Aleks (he/him/il/lui)> ah ?
[13:07:21] <orhtej2> > <@Alekswag:matrix.org> still feels like it was working before and somehow it spontaneously broke so i'm guessing the upstream pushed a new version of mongo-something

or they pulled the rug from under the VM as it's reporting `QEMU Virtual CPU version 2.5+` rather than actual CPU underneath :p
[13:08:08] <orhtej2> > that's not the package I mentioned actually, I wanted `mongodb-mongosh-shared-openssl3` because this seems to be the package that supplies `mongosh`

also given `shared` in the name one would assume this needs to pull shared libraries as well but let's assume the `deb` is doing it already
[13:08:26] <orhtej2> unless it's buster vs bullseye incompatibility x_x
[13:10:53] <Aleks (he/him/il/lui)> Soooo as Ta g was pointing out in the reply to G cco, last month's test for Rockerchat was working with :

```
Get:2 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-mongosh amd64 1.9.1 [42.0 MB]
Get:3 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-org-shell amd64 4.4.22 [13.4 MB]
Get:4 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-org-server amd64 4.4.22 [20.8 MB]
```

versus today:

```
Get:2 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-mongosh amd64 1.10.1 [42.0 MB]
Get:3 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-org-shell amd64 4.4.23 [13.4 MB]
Get:4 http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 mongodb-org-server amd64 4.4.23 [20.8 MB]
```
[13:11:01] <Aleks (he/him/il/lui)> could be that new version 1.10.1 vs 1.9.1 idk
[13:11:51] <orhtej2> > <@Alekswag:matrix.org> could be that new version 1.10.1 vs 1.9.1 idk

I remember checking the older versions and I'm fairly sure it was not the case but I'm not going to bet on that
[13:12:13] <orhtej2> the `!testme` runner is not the one doing periodic checks, right?
[13:13:49] <Aleks (he/him/il/lui)> `!testme` triggers job on ci-apps-dev where job are only triggered manually (or by the bot for auto-updates), versus `ci-apps` is the "official" CI, on a different machine, with periodic checks
[13:18:11] <orhtej2> no way of manually running there with arbitrary branch?
[13:18:33] <orhtej2> because we could set up simple dependency update PR and see if it helps
[13:19:46] <Aleks (he/him/il/lui)> not sure what you mean ... what would you run where ?
[13:20:05] <Aleks (he/him/il/lui)> ah you want to test a PR on `ci-apps`
[13:20:06] <Aleks (he/him/il/lui)> meh
[13:21:31] <Aleks (he/him/il/lui)> what's your idea about "dependency update", which dependency would you use that would be compatible with lack-of-avx ?
[13:23:39] <orhtej2> > <@Alekswag:matrix.org> what's your idea about "dependency update", which dependency would you use that would be compatible with lack-of-avx ?

`mongodb-mongosh-shared-openssl11` instead of plain `mongodb-mongosh`
[13:24:26] <orhtej2> or I tested with `openssl3` actually, not sure which is 'newer'
[13:25:46] <orhtej2> you got to be kidding me: https://packages.debian.org/search?searchon=names&keywords=openssl
[13:25:53] <orhtej2> will break on bookworm
[13:26:01] <Aleks (he/him/il/lui)> on bullseye we're running openssl 1.1, but bookworm will be 3.x
[13:26:18] <Aleks (he/him/il/lui)> well if it's "just that" we can do some `if` on the current debian version, not a huge deal
[13:26:44] <orhtej2> > <@Alekswag:matrix.org> well if it's "just that" we can do some `if` on the current debian version, not a huge deal

that's a theory we cannot test without merging to `master`, not a huge fan :/
[13:27:03] <orhtej2> perhaps I'll just install on my garbage server with no avx support and see what happens
[13:27:05] <Aleks (he/him/il/lui)> i'd say : let's go to try that PR on some app on ci-apps-dev, and if it passes, let's merge and run on ci-apps, because the app is broken currently anyway
[13:28:19] <Aleks (he/him/il/lui)> (and yes if needed i can try manually triggering a job on a specific PR on ci-apps, just for this specific case but not super confident about this because there are other implications in doing so, like `ci-apps` is supposed to be "the truth source" for levels etc)
[13:29:04] <orhtej2> should we ignore bullseye vs bookworm incompatibility for now?
[13:29:14] <Aleks (he/him/il/lui)> as long as we don't bump the app's version number, people won't have an upgrade advertised in their admin panel
[13:29:14] <Aleks (he/him/il/lui)> yes
[13:29:15] <orhtej2> or it's an easy check?
[13:29:54] <Aleks (he/him/il/lui)> i'm not worried about handling bullseye vs bookworm package name changes, there's always this kind of story for a bunch of apps for major debian upgrades
[13:30:26] <Aleks (he/him/il/lui)> (eg pretty sure we have spotted one for the `java-jdk-whatever-11` or something)
[13:31:28] <Aleks (he/him/il/lui)> (and we have apps depending on `libssl1.1` which doesnt exists anymore, same story, "just an if" to add somewhere, though of couse that adds complexity but it's not like we're gonna fix the mess that computers are just the few of us ;P)
[13:31:55] <orhtej2> https://github.com/YunoHost-Apps/rocketchat_ynh/pull/182 fingers crossed
[13:32:04] <Aleks (he/him/il/lui)> cheers ❤️
[13:32:45] <Aleks (he/him/il/lui)> where did you learn about that `mongodb-mongosh-shared-openssl11` package tho ?
[13:33:41] <orhtej2> https://repo.mongodb.org/apt/debian/dists/bullseye/mongodb-org/5.0/main/binary-amd64/
[13:33:46] <orhtej2> sry here: https://repo.mongodb.org/apt/debian/dists/buster/mongodb-org/4.4/main/binary-amd64/
[13:33:56] <orhtej2> running locally....
[13:34:47] <Aleks (he/him/il/lui)> ah wtf you're not even in the yunohost-apps org /o\
[13:34:50] <Aleks (he/him/il/lui)> shame 🔔
[13:35:10] <Yunohost Git/Infra notifications> [nextcloud_ynh] @lapineige [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592#issuecomment-1655693309) on [issue #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592) 26.0.4 (Oldstable): It might be very important for the people locked on 32-bits architecture.
[13:35:36] <orhtej2> > <@Alekswag:matrix.org> ah wtf you're not even in the yunohost-apps org /o\

does not make me qualified? :( (for running `!testme` sure, but for helping)
[13:36:21] <orhtej2> Install took me straight to logs, sounds promising
[13:36:22] <orhtej2> not
[13:36:50] <Yunohost Git/Infra notifications> [nextcloud_ynh] @alexAubin [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592#issuecomment-1655695520) on [issue #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592) 26.0.4 (Oldstable): (Do you mean 26.x is the last supported version for 32 bit arch ? I thought Nextcloud somehow reconsidered their decisio...
[13:37:40] <Aleks (he/him/il/lui)> > does not make me qualified? :( (for running `!testme` sure, but for helping)

no i mean you are very qualified, that's why you should be part of the yunohost-apps team haha
[13:37:43] <Aleks (he/him/il/lui)> sent an invitation
[13:38:20] <orhtej2> > <@Alekswag:matrix.org> no i mean you are very qualified, that's why you should be part of the yunohost-apps team haha

never really asked for it haha :)
[13:38:32] <orhtej2> > Install took me straight to logs, sounds promising

you what? https://paste.yunohost.org/raw/emepunizik
[13:38:55] <orhtej2> ```
Expected sha256 checksum:
Downloaded sha256 checksum: f10db86c790f26fbeb01a3aa6e5462d81cf98868896d70264258d44712a2343a
```
[13:39:40] <Aleks (he/him/il/lui)> 🤔
[13:40:21] <orhtej2> wtf, that's even legal? https://github.com/orhtej2/rocketchat_ynh/blob/49f0ddc0c7a11e6d2615f81c19987a0de7f1bffe/manifest.toml#L53C9-L55C20
[13:42:09] <orhtej2> attempt #2 🤞
[13:42:27] <orhtej2> seriously, Cinny keeps crashing Firefox renderer, WTF
[13:51:56] <orhtej2> > https://github.com/YunoHost-Apps/rocketchat_ynh/pull/182 fingers crossed

nope

```
_common.sh: line 40: 394142 Illegal instruction mongosh --quiet --username $user --password $password --authenticationDatabase $authenticationdatabase --host $host --port $port <
```
[13:53:00] <Aleks (he/him/il/lui)> 😐️
[13:53:26] <orhtej2> will have a look later again
[13:58:49] <Yunohost Git/Infra notifications> [nextcloud_ynh] @lapineige [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592#issuecomment-1655739485) on [issue #592](https://github.com/YunoHost-Apps/nextcloud_ynh/pull/592) 26.0.4 (Oldstable): That is right : they announced they will try to continue to support 32 bit. But we dont know for how long, and in v26 (...
[14:41:56] <Aleks (he/him/il/lui)> goodnewseveryone.jpg : isAAAc enabled `avx` on ci-apps \o/
[14:45:55] <Aleks (he/him/il/lui)> (now we just need to make LXC/LXD working again 😅)
[14:52:01] <Aleks (he/him/il/lui)> alrighty I've restarted rocketchat job
[15:48:27] <Salamandar> > seriously, Cinny keeps crashing Firefox renderer, WTF

o.O I don’t have any issue
[15:49:11] <orhtej2> > <@Salamandar:matrix.org> o.O I don’t have any issue

click on emoji selector next to text input and select something
[15:49:33] <orhtej2> https://aria.im/_matrix/media/v1/download/circledsquareroot.ovh/1ec8b595094d829e3b9ff714a26ceb3d1520ede0791a693b74a81e8a32f7c38d
[15:49:58] <orhtej2> and when you close this dialog my Firefox window turns white for a second indicating renderer/GPU process crash
[15:50:07] <Salamandar> yeah ?
[15:50:31] <Salamandar> funny i have the shortcut on the top, not on the left
[15:50:44] <Salamandar> https://aria.im/_matrix/media/v1/download/matrix.org/JIeMIYiQzWVtjLeisBTwpvjp
[15:50:55] <orhtej2> 2.2.6
[15:50:57] <orhtej2> ?
[15:51:24] <Salamandar> ah sorry i’m on element on this PC
[15:51:45] <Salamandar> yep, works fine on cinny
[15:51:59] <Salamandar> 😈
[15:52:12] <orhtej2> welp then it's my PC :/
[17:00:36] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to update_app_levels: Update app levels according to CI results ([c59d9ade](https://github.com/YunoHost/apps/commit/c59d9ade59a9bbc8c8a8af4117e40d63ad6f786a))
[17:10:38] <Yunohost Git/Infra notifications> [apps] @alexAubin closed [pull request #1697](https://github.com/YunoHost/apps/pull/1697): Update app levels according to CI results
[17:10:39] <Yunohost Git/Infra notifications> [apps] @alexAubin [commented](https://github.com/YunoHost/apps/pull/1697#issuecomment-1656029780) on [issue #1697](https://github.com/YunoHost/apps/pull/1697) Update app levels according to CI results: (Closing to recreate)
[17:10:39] <Yunohost Git/Infra notifications> [apps] @alexAubin deleted branch update_app_levels
[17:10:46] <Yunohost Git/Infra notifications> [apps] @yunohost-bot pushed 1 commit to update_app_levels: Update app levels according to CI results ([2064e58f](https://github.com/YunoHost/apps/commit/2064e58fb14d9a000306160a8ae8c287b3783725))
[17:10:46] <Yunohost Git/Infra notifications> [apps] @yunohost-bot created new branch update_app_levels
[17:10:46] <Yunohost Git/Infra notifications> [apps] @yunohost-bot opened [pull request #1701](https://github.com/YunoHost/apps/pull/1701): Update app levels according to CI results
[17:27:47] <orhtej2> > I'm having another problem with the migration from calckey to firefish.
>
> In the migration script, I'm trying to modify this command to adapt it to PSQL
>
> Check if a database exists before trying to move it
> `if [ -n "$old_db_name" ] && mysqlshow | grep -q "^| $old_db_name"`
>
> Thanks for your help 🙏

what worked for me:

```sh
if [ -n "$old_db_name" ] && ynh_psql_execute_as_root --sql="SELECT datname FROM pg_database;" | grep -q "^ $old_db_name"
```
full(ish) test:

```sh
#!/bin/bash

source /usr/share/yunohost/helpers

old_db_name=dendritea

if [ -n "$old_db_name" ] && ynh_psql_execute_as_root --sql="SELECT datname FROM pg_database;" | grep -q "^ $old_db_name"
then
echo a
else
echo b
fi
```
[17:29:02] <Aleks (he/him/il/lui)> https://ci-apps.yunohost.org/ci/job/17412 rocket chat job seems to be working /o/
[17:29:35] <oufmilo[m]> > what worked for me:
>
> ```sh
> if [ -n "$old_db_name" ] && ynh_psql_execute_as_root --sql="SELECT datname FROM pg_database;" | grep -q "^ $old_db_name"
> ```
> full(ish) test:
>
> ```sh
> #!/bin/bash
>
> source /usr/share/yunohost/helpers
>
> old_db_name=dendritea
>
> if [ -n "$old_db_name" ] && ynh_psql_execute_as_root --sql="SELECT datname FROM pg_database;" | grep -q "^ $old_db_name"
> then
> echo a
> else
> echo b
> fi
> ```

thank you i've resolved this now i have another error ^^
[17:32:43] <Bram[m]> hey everyone, I have Émy - OniriCorpe who've reached me to contribute to the AdGuardHome application https://github.com/YunoHost-Apps/adguardhome_ynh/, is it ok if I give her access to it for that? She has my total trust in general and she is already contributing to other applications
[17:33:07] <Bram[m]> there haven't been a lot of contribution on this app since some time apparently
[17:33:09] <Bram[m]> https://aria.im/_matrix/media/v1/download/matrix.org/IEqgWaJZTLrgxcqsRmrVmGZl
[17:33:21] <Bram[m]> and there are security PR waiting
[17:35:32] <Aleks (he/him/il/lui)> sure o/
[17:44:21] <orhtej2> > thank you i've resolved this now i have another error ^^

took me a moment to understand what you were asking about, sorry :/
[17:44:57] <oufmilo[m]> https://paste.yunohost.org/odayezonig.sql
[17:45:30] <oufmilo[m]> `177866 WARNING chown: invalid user: ‘firefish:www-data’`
[17:46:10] <orhtej2> > `177866 WARNING chown: invalid user: ‘firefish:www-data’`

are you running before provisioning user or smth?
[17:46:17] <oufmilo[m]> My update file --> https://paste.yunohost.org/osimiwavay.bash
[17:47:35] <oufmilo[m]> The script migrate file --> https://paste.yunohost.org/aqibomoday.bash
[17:49:45] <Tag> eric_G: Hey o/ I'm looking at invidious package and it's downloading the sources with `git`. I think I could modify this to use the `ressources.sources` so we can benefits from autoupdates. What do you think about that ?
[17:55:16] <Yunohost Git/Infra notifications> App rocketchat rises from level 0 to 8 in job [#17412](https://ci-apps.yunohost.org/ci/job/17412) !
[19:42:59] <Dante> > actually what error is that? There were reports recently that `root` can no longer modify arbitrary databases, perhaps you need to `sudo` as Synapse's user?

The error looks like this:
```
ERROR: role "mautrix_whatsapp" cannot be dropped because some objects depend on it
DETAIL: owner of database mautrix_whatsapp
22 objects in database mautrix_whatsapp
```

[20:09:39] <orhtej2> > <@thardev:matrix.org> The error looks like this:
> ```
> ERROR: role "mautrix_whatsapp" cannot be dropped because some objects depend on it
> DETAIL: owner of database mautrix_whatsapp
> 22 objects in database mautrix_whatsapp
> ```
>

and no error for the command prior (`DROP OWNED BY `etc)?
[20:17:48] <Dante> https://aria.im/_matrix/media/v1/download/matrix.org/WTMbHdKAIvRPRlLxGDFtVAmb
[20:17:54] <Dante> nope, it looks like this usually in the remove logs
[20:19:06] <orhtej2> > <@thardev:matrix.org> Screenshot 2023-07-28 at 21.17.38.png

if you go to admin panel under tools->logs there should be full debug log you can share, can you do that?
[20:19:40] <orhtej2> > `177866 WARNING chown: invalid user: ‘firefish:www-data’`

can you share full log and current state of this app?
[20:19:47] <orhtej2> namely `manifest.toml`
[20:20:56] <orhtej2> > namely `manifest.toml`

because I may be mistaken but by default `example_ynh` does not provision system user:

```toml
[resources.system_user]
# This will provision/deprovision a unix system user
```
[20:21:20] <orhtej2> and so is not firefish at this point: https://github.com/YunoHost-Apps/firefish_ynh/blob/93186bc06b50f6386600279cd53faf87373d505e/manifest.toml#L93C3-L95C1
[20:25:36] <Dante> > if you go to admin panel under tools->logs there should be full debug log you can share, can you do that?

yes, let me reinstall clean and I'll provide logs
[20:25:43] <orhtej2> > <@thardev:matrix.org> Screenshot 2023-07-28 at 21.17.38.png

Unless that's from Ci?
[20:26:14] <orhtej2> > <@thardev:matrix.org> yes, let me reinstall clean and I'll provide logs

You should have a number of logs still available
[20:26:26] <orhtej2> Perhaps no need to reinstall
[20:30:03] <Dante> yes, that's from command line, I can run `yunohost --debug` and screenshot the step that is related to PSQL?
[20:35:12] <orhtej2> > <@thardev:matrix.org> yes, that's from command line, I can run `yunohost --debug` and screenshot the step that is related to PSQL?

Or just share logs with built in functionality, already at debug verbosity?
[20:35:22] <orhtej2> I mean whatever works
[20:36:37] <Dante> yes, here you go 🙂
[20:36:38] <Dante> https://paste.yunohost.org/umeyujeway.bash
[20:38:58] <orhtej2> > <@thardev:matrix.org> https://paste.yunohost.org/umeyujeway.bash

For future reference please use built in functionality, your log contains plaintext passwords 😔
[20:39:18] <orhtej2> And share logs thing removes them
[20:39:25] <orhtej2> And other sensitive data
[20:40:16] <Dante> yeah, I know, no worries, this is a dev box 🙂 👍️
[20:40:42] <Dante> is not even exposed to the Internet
[20:45:27] <orhtej2> Ok so I have quick hacks to fix this but I think better approach is to actually read Synapse and bridge sources
[20:45:37] <orhtej2> Are you the maintainer?
[20:46:06] <Dante> like go the API way?
[20:46:23] <Dante> that could be a solution maybe 🤔
[20:46:30] <Dante> > Are you the maintainer?

yup 🙂
[20:49:03] <orhtej2> Wtf are the requirements on this bridge, is it ffmpeg pulling wayland and mesa?
[20:50:22] <Dante> yes, ffmpeg is a dependency for manipulating images on messages
[20:50:58] <Dante> but didn't notice that it requires wayland... WTF as well haha
[20:52:01] <orhtej2> * ffplay: a simple media player based on SDL and the FFmpeg libraries
[20:52:04] <orhtej2> that would do it :/
[20:52:11] <orhtej2> https://packages.debian.org/bullseye/ffmpeg
[20:53:28] <Dante> could be, I'm not involved on the bridge development so cannot say much...
[20:54:00] <orhtej2> > <@thardev:matrix.org> could be, I'm not involved on the bridge development so cannot say much...

no no sure, I get it, just checking if there's a slimmer deb alternative
[20:54:07] <orhtej2> but given ffmpeg is not a metapackage - no
[20:56:30] <Dante> well, it could be great to speed up the app installation but not sure how to handle that
[21:00:39] <orhtej2> > <@thardev:matrix.org> well, it could be great to speed up the app installation but not sure how to handle that

soooo there is a slim version available: https://www.deb-multimedia.org/dists/oldstable/main/binary-amd64/package/ffmpeg
[21:00:52] <orhtej2> but that does not answer your question
[21:06:49] <orhtej2> > <@thardev:matrix.org> https://paste.yunohost.org/umeyujeway.bash

are you running some custom version? I see no entry that corresponds to this line: https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/53f02f8d80cf3c9491420a0f612afbbae86e8ff0/scripts/remove#L64
[21:07:15] <Dante> > soooo there is a slim version available: https://www.deb-multimedia.org/dists/oldstable/main/binary-amd64/package/ffmpeg

still interesting, maybe I'll experiment with it to keep the app lighter and probably faster installation 🤔
[21:07:23] <Tag> looks like packaging v2 branch orhtej2
[21:07:34] <Dante> > are you running some custom version? I see no entry that corresponds to this line: https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/53f02f8d80cf3c9491420a0f612afbbae86e8ff0/scripts/remove#L64

yes, sorry, it is packaging v2
[21:07:40] <Tag> nvm
[21:08:30] <orhtej2> > https://github.com/YunoHost-Apps/rocketchat_ynh/pull/182 fingers crossed

update nobody's been waiting for: I was over eager trimming the dependencies but core functionality works (?) by replacing `mongosh` with `mongo`. I was able to install, service keeps dying with signal 4/ILL, no clue why or how but my server is potato-grade so it may be that
[21:08:49] <Tag> Ah, so you don't to remove the database in the remove script, it's handled by packaging v2
[21:09:23] <orhtej2> > <@tag:lostpod.me> Ah, so you don't need this line in the remove script, it's handled by packaging v2

and you don't need to deprovision DB user? is it automatically evicted from other databases as well?
[21:10:41] <orhtej2> > <@tag:lostpod.me> looks like packaging v2 branch orhtej2

right, that makes sense
[21:10:46] <Dante> > <@tag:lostpod.me> Ah, so you don't to remove the database in the remove script, it's handled by packaging v2

hmmm at first I thought the same but I think those lines try to "unregister" the appservice from Synapse, that why I mentioned the API earlier, maybe there is a way to unregister using Synapse's API in a cleaner way?
[21:10:51] <Tag> Yep, everything provisionned by the core during install/upgrade should be deprovisionned
[21:11:28] <Tag> AH
[21:14:42] <Tag> Mmh I'd remove at least this line https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh/blob/packaging-v2/scripts/remove#L59
[21:21:52] <Tag> bot_synapse_db_user and botname are actually used in postgres in this app ? 🤔
[21:31:22] <Yunohost Git/Infra notifications> [apps] @alexAubin pushed 1 commit to update_app_levels: reset level to 7 and 8 for mediawiki and wekan, temporary issues that should now be fixed ([65af585e](https://github.com/YunoHost/apps/commit/65af585e9446b33b82bd3176d2a0793d35aa72cb))
[21:31:43] <Yunohost Git/Infra notifications> [apps] @alexAubin edited [pull request #1701](https://github.com/YunoHost/apps/pull/1701): Update app levels according to CI results
[21:36:45] <Dante> > <@tag:lostpod.me> bot_synapse_db_user and botname are actually used in postgres in this app ? 🤔

If I'm not mistaken when you register an appservice in Synapse (so this app actually) it is saved in the postgres Synapse db that you select on install, so they are stored somewhere inside that table, IIRC there is a table called appservices
[21:36:54] <orhtej2> I feel like this cleanup is ill-formed, what's the intention? I doubt any of bridge users is able to modify Synapse DB directly
[21:37:21] <orhtej2> > <@thardev:matrix.org> If I'm not mistaken when you register an appservice in Synapse (so this app actually) it is saved in the postgres Synapse db that you select on install, so they are stored somewhere inside that table, IIRC there is a table called appservices

it's actually just (?) in config file
[21:39:23] <orhtej2> > it's actually just (?) in config file

I was wrong: https://github.com/matrix-org/synapse/blob/develop/synapse/storage/databases/main/appservice.py
[22:17:52] <Yunohost Git/Infra notifications> [apps] @Tagadda pushed 1 commit to update_app_levels: reset level 8 for mastodon, temporary network issue on the CI ([2cda504f](https://github.com/YunoHost/apps/commit/2cda504f6e874c85d7c80dfd729ddfa10e9dc1b2))
[22:18:07] <Yunohost Git/Infra notifications> [apps] @Tagadda edited [pull request #1701](https://github.com/YunoHost/apps/pull/1701): Update app levels according to CI results
[22:20:08] <Dante> I think I'll try to investigate a bit the API if there is a way to do it clean otherwise I'll see if removing that line changes anything or not during the removal of the app 🙂
[22:20:15] <Dante> thanks a lot to both of you!
[22:24:38] <orhtej2> I feel like this stanza is copied between bridges but nobody remembers the original intent https://github.com/YunoHost-Apps/mautrix_signal_ynh/blob/76a4622e4a2226953d9811ec6b9d2a77bf71cd34/scripts/remove#L67
[23:56:43] <oufmilo[m]> > can you share full log and current state of this app?

https://paste.yunohost.org/raw/tesutemivo