[08:09:12]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/pull/630#issuecomment-4966780074) on [issue #630](https://github.com/YunoHost-Apps/synapse_ynh/pull/630) [fix] Full disk when db down: I think what we need here is to ensure that synapse dont start or is running if postgresql is not running. But in my op...
[08:09:57]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T [commented](https://github.com/YunoHost-Apps/synapse_ynh/pull/630#issuecomment-4966780074) on [issue #630](https://github.com/YunoHost-Apps/synapse_ynh/pull/630) [fix] Full disk when db down: I think what we need here is to ensure that synapse dont start or is running if postgresql is not running. But in my op...
[08:17:23]
<Yunohost Git/Infra notifications> [synapse_ynh] Gredin67 [commented](https://github.com/YunoHost-Apps/synapse_ynh/pull/630#issuecomment-4966844974) on [issue #630](https://github.com/YunoHost-Apps/synapse_ynh/pull/630) [fix] Full disk when db down: OK so I think After=network.target Requires=postgresql.service would solve our issue on sans-nuage.fr : shut dow...
[12:29:33]
<orhtej2> Anyone has any idea on why diesel-rs out of the blue started re-running already applied migrations?
[12:29:35]
<orhtej2> only on bookworm, trixie is fine
[12:29:35]
<orhtej2> > Anyone has any idea on why diesel-rs out of the blue started re-running already applied migrations?
I'm more and more confused, even the version that used to work now insists the last migration was never run, even though it's there in `__diesel_schema_migrations`
[12:29:36]
<orhtej2> replicable outside of app scripts 🤷
[12:29:36]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T edited [pull request #632](https://github.com/YunoHost-Apps/synapse_ynh/pull/632) : Testing
[12:29:37]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T edited [pull request #632](https://github.com/YunoHost-Apps/synapse_ynh/pull/632) : Testing
[12:29:37]
<Yunohost Git/Infra notifications> [synapse_ynh] Josue-T merged [pull request #632](https://github.com/YunoHost-Apps/synapse_ynh/pull/632) : Testing
[13:06:59]
<m606> i have issues with setting puppeteer for an app and I wonder - is a YNH app allowed to access what is in `/usr/bin` for instance when setting the template systemd service file with env var `PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium` ?
[13:07:37]
<m606> or would there be some isolation preventing this?
[13:43:46]
<FbIN (vdbhb59)> The bentopdf one right?
[13:44:52]
<m606> it-tools
[13:46:53]
<Thomas> I guess it could work, if you didn’t restrict too much the systemd service with hardening?
[13:57:11]
<m606> i use the `example_ynh` service template
[14:02:53]
<Yunohost Git/Infra notifications> [apps] yunohost-bot opened [pull request #3550](https://github.com/YunoHost/apps/pull/3550) : Add iocaine to wishlist
[14:08:14]
<Thomas> > <@m606:matrix.org> i have issues with setting puppeteer for an app and I wonder - is a YNH app allowed to access what is in `/usr/bin` for instance when setting the template systemd service file with env var `PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium` ?
It seems to work for karakeep https://github.com/YunoHost-Apps/karakeep_ynh/blob/8751e906215b67055a18ffb4c64812101eff5df0/conf/karakeep-browser.service#L9
[14:25:24]
<otm33> Or installing chromium in install_dir ? https://github.com/YunoHost-Apps/linkwarden_ynh/pull/53/changes
With linkwarden, there was also an issue with archiving related to the @privileged syscallfilter (spent hours dissecting thaht group and forgot which filter was involved...)
[14:25:27]
<FbIN (vdbhb59)> > it-tools
The same issue seems to be with bentopdf, iirc
[14:43:15]
<m606> hmm but it doesn't use the hardened system service template, I will check whether that's the reason (even though I guess I'd rather have the service hardened)
[14:46:14]
<m606> i rely on apt debian package at the moment for chromium. in the case of linkwarden is this line installing the chromium dep inside the target directory: https://github.com/YunoHost-Apps/linkwarden_ynh/pull/53/files#diff-6233345de4867c7ccf72bac1fc1067988d2a4c8e1ab9a746956eafccf88cfed2R60
As for filter notice, thank you maybe i will try to copy your list of filters.
[14:47:50]
<FbIN (vdbhb59)> >> it-tools
>
> The same issue seems to be with bentopdf, iirc
My bad. I meant ittools itself
[16:16:10]
<m606> @thovi98:matrix.org @otm33:matrix.org so yes I can confirm that it is an issue with systemd hardening config.
[16:19:23]
<m606> trying to make it as restrictive as possible as in linkwarden example, it seems only adding `setfsuid setfsuid32` to the default list is enough for puppeteer + chromium to work. That's strange, because default list in `example_ynh` includes `@privileged` which is a filter set that includes the two mentioned filters... However I can't have it working with `@privileged`
[16:19:53]
<m606> anyway my issue seems to be solved, thanks for the tips
[16:51:48]
<m606> Can an API endpoint be given permission `all_users` (instead of `visitors`) and if so how should request be authenticated ?
[19:15:01]
<Yunohost Git/Infra notifications> [roundcube_ynh] A-Sverdrup [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973018110) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails: The issue persists.
2026-07-14 19:10:51,721: INFO - [#####++.............] > Installing roundcube with Composer...
...
[20:32:23]
<Yunohost Git/Infra notifications> [roundcube_ynh] orhtej2 [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973715737) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails: Can you try installing ca-certificates package and retrying?
[20:52:48]
<Yunohost Git/Infra notifications> [roundcube_ynh] A-Sverdrup [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973891116) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails:
root@yung ~# apt install ca-certificates
Reading package lists... Done
Building dependency tree... Done
Reading stat...
[21:01:30]
<Yunohost Git/Infra notifications> [roundcube_ynh] orhtej2 [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973958526) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails: And curl -L https://repo.packagist.org/packages.json works?
[21:01:48]
<Yunohost Git/Infra notifications> [roundcube_ynh] orhtej2 [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973958526) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails: And curl -L https://repo.packagist.org/packages.json works? (on the server of course)
[21:03:36]
<Yunohost Git/Infra notifications> [roundcube_ynh] A-Sverdrup [commented](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249#issuecomment-4973974200) on [issue #249](https://github.com/YunoHost-Apps/roundcube_ynh/issues/249) Installation fails: Surprisingly, yes.
root@yung ~# curl -L https://repo.packagist.org/packages.json
{"packages":[],"notify-batch":"htt...
[21:36:14]
<orhtej2> soooooooooooo I've added a bunch of prints to `diesel-rs` and it's clearly `libmariadb` that out of the blue claims the first row contains a string that's empty (it is not in `phpMyAdmin`). I'm seriously open to ideas, cf https://github.com/YunoHost-Apps/syncserver-rs_ynh/pull/158, it's not this PR's fault, `ci-apps` has some questionable result's in this regard
[21:36:14]
<Yunohost Git/Infra notifications> [nextcloud_ynh] A-Sverdrup opened [issue #895](https://github.com/YunoHost-Apps/nextcloud_ynh/issues/895) : Update to Nextcloud 34 fails with cryptic logs
[21:36:15]
<orhtej2> https://www.youtube.com/watch?v=jCgfaXgUb6Y
[21:36:25]
<Yunohost Git/Infra notifications> [nextcloud_ynh] A-Sverdrup [commented](https://github.com/YunoHost-Apps/nextcloud_ynh/issues/895#issuecomment-4974218997) on [issue #895](https://github.com/YunoHost-Apps/nextcloud_ynh/issues/895) Update to Nextcloud 34 fails with cryptic logs:
2026-07-14 21:23:04,968: DEBUG - ++ filter_boring_occ_warnings
2026-07-14 21:23:04,968: DEBUG - ++ sed -E s@\s*([0...
[21:41:40]
<m606> are those the migration steps ? https://github.com/YunoHost-Apps/syncserver-rs_ynh/pull/158/files#diff-6f67d3a8330a3c924847c4e3e44fa893ed4178fee92b9bfeba68fd6fdbaff5ecR23-R30
Would you have logs?
[21:50:49]
<orhtej2> > <@m606:matrix.org> are those the migration steps ? https://github.com/YunoHost-Apps/syncserver-rs_ynh/pull/158/files#diff-6f67d3a8330a3c924847c4e3e44fa893ed4178fee92b9bfeba68fd6fdbaff5ecR23-R30
> Would you have logs?
See CI
[21:50:49]
<orhtej2> > See CI
As in this is from job that only upgraded `uv`: https://ci-apps-dev.yunohost.org/ci/logs/22690.log
[21:50:50]
<orhtej2> The log from custom `diesel-rs` build with a bunch of logging
[21:50:51]
<m606> do you think about something suspicious the migration steps in the PR ? https://paste.yunohost.org/wamifeqigi.log
It doesn't look to bad there at first sight
[21:50:51]
<orhtej2> ```
$ RUST_LOG=debug ../diesel-2.3.11/target/debug/diesel --database-url mysql://syncserver_rs:5fcxxx@localhost/syncserver_rs migration --migration-dir syncstorage-mysql/migrations list
Query { sql: "CREATE TABLE IF NOT EXISTS __diesel_schema_migrations (\n version VARCHAR(50) PRIMARY KEY NOT NULL,\n run_on TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP\n);\n", binds: [] }
Query { sql: "SELECT `__diesel_schema_migrations`.`version` FROM `__diesel_schema_migrations` ORDER BY `__diesel_schema_migrations`.`version` DESC", binds: [] }
cp len:0. ll:0 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 0, capacity: 1, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 0 converted:
cp len:0. ll:0 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 0, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 14 converted: 20200612231034
cp len:14. ll:14 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 14, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 14 converted: 20200403102015
cp len:14. ll:14 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 14, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 14 converted: 20190925174347
cp len:14. ll:14 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 14, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 14 converted: 20190911164500
cp len:14. ll:14 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 14, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
(ref) len: 14 converted: 20180828010336
cp len:14. ll:14 tpe: BindData { tpe: MYSQL_TYPE_VAR_STRING, bytes: Some(0x564b897d4d00), length: 14, capacity: 14, flags: Flags(NOT_NULL_FLAG | PRI_KEY_FLAG | NO_DEFAULT_VALUE_FLAG | PART_KEY_FLAG), is_null: 0, is_truncated: Some(0) }
Applied:
20190925174347
20180828010336
20200403102015
20200612231034
20190911164500
2020-04-03-102015_change_userid: 20200403102015
2019-09-11-164500: 20190911164500
2019-09-25-174347_min_collection_id: 20190925174347
2018-08-28-010336_init: 20180828010336
2020-06-12-231034_new_batch: 20200612231034
2020-08-24-091401_add_quota: 20200824091401
Migrations:
[X] 2018-08-28-010336_init
[X] 2019-09-11-164500
[X] 2019-09-25-174347_min_collection_id
[X] 2020-04-03-102015_change_userid
[X] 2020-06-12-231034_new_batch
[ ] 2020-08-24-091401_add_quota
```
[21:51:48]
<orhtej2> where did you get it from?
[21:51:48]
<m606> how do you come to the one above ?
[21:51:48]
<orhtej2> > <@m606:matrix.org> do you think about something suspicious the migration steps in the PR ? https://paste.yunohost.org/wamifeqigi.log
> It doesn't look to bad there at first sight
This one is OK
[21:51:49]
<miro5001> can you "just" skip this migration
`Failed to run migrations: Failed to run 2020-08-24-091401_add_quota with: Duplicate column name 'total_bytes'`
[21:52:31]
<m606> there is the link of the full log at the top. It is from the last CI run in the PR
[21:52:31]
<orhtej2> > <@miro5001:matrix.org> can you "just" skip this migration
> `Failed to run migrations: Failed to run 2020-08-24-091401_add_quota with: Duplicate column name 'total_bytes'`
it is applied, it shouldn't be rerun
[22:01:50]
<orhtej2> technically schema is stable for 6 years now and I cąn skip it
[22:03:41]
<orhtej2> but it ised to work last month with initial 0.23.3 release and even reverting diesel no longer works
[22:03:57]
<orhtej2> like wtf
[22:04:02]
<orhtej2> > <@m606:matrix.org> there is the link of the full log at the top. It is from the last CI run in the PR
Last runcis on trixie, it always works on trixie ąnd always fails on bookworm
[22:04:22]
<orhtej2> (now)
[22:05:48]
<miro5001> 2020-08-24 that s very old
[22:06:46]
<miro5001> I mean anyway to mark it as applied manually?
[22:06:46]
<miro5001> show as not applied, where is the migration status saved
```
32808 INFO DEBUG - Migrations:
32808 INFO DEBUG - [X] 2018-08-28-010336_init
32808 INFO DEBUG - [X] 2019-09-11-164500
32808 INFO DEBUG - [X] 2019-09-25-174347_min_collection_id
32808 INFO DEBUG - [X] 2020-04-03-102015_change_userid
32808 INFO DEBUG - [X] 2020-06-12-231034_new_batch
32808 INFO DEBUG - [ ] 2020-08-24-091401_add_quota
```
[22:06:47]
<m606> Could the issue be MariaDB version?
Bookworm
```
+ mysql --version
mysql Ver 15.1 Distrib 10.11.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
+ ./diesel --version
Version: 2.3.11
```
Trixie
```
+ mysql --version
mysql from 11.8.6-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using EditLine wrapper
+ ./diesel --version
Version: 2.3.11
```
[22:15:35]
<m606> it might keeps installing the inititial schema and perform on the top of it all schema patches
[22:15:39]
<m606> could this be related ? https://github.com/mozilla-services/syncstorage-rs/issues/790
[22:33:15]
<m606> here is the migration step (so it's only one line) https://github.com/mozilla-services/syncstorage-rs/blob/master/syncstorage-mysql/migrations/2020-08-24-091401_add_quota/up.sql
a hack could be to patch this SQL command to run it only if `total_bytes` column doesn't exist
[22:33:32]
<orhtej2> > <@m606:matrix.org> could this be related ? https://github.com/mozilla-services/syncstorage-rs/issues/790
Shit worked no problem with initial 0.23.3 release 2 months ago
[22:33:35]
<m606> yes i have been checking log of 0.22.0 https://github.com/YunoHost-Apps/syncserver-rs_ynh/pull/121#issuecomment-4089120364
all migrations steps are successfully applied
[22:37:29]
<orhtej2> > <@m606:matrix.org> yes i have been checking log of 0.22.0 https://github.com/YunoHost-Apps/syncserver-rs_ynh/pull/121#issuecomment-4089120364
> all migrations steps are successfully applied
But that's my point, yesterday I realized diesel started talking crazy and idk why that is
[22:37:47]
<m606> yes, I was actually wondering whether all migrations whee rerun everytime, it seems that yes (at least the upgrade log of 0.22.0 show them all)
[22:39:48]
<orhtej2> > <@m606:matrix.org> yes, I was actually wondering whether all migration where rerun everytime, it seems that yes (at least the upgrade log of 0.22.0 show them all)
Yep, and diesel correctly understood they're there
[22:39:58]
<orhtej2> and they are, I checked with phpMyAdmin
[22:40:06]
<Yunohost Git/Infra notifications> Autoupdater just ran, here are the results:
- 78 pending update PRs
- 20 new apps PRs: atuin, diagramsnet, dokuwiki, fab-manager, jackett, jenkins, kresus, localai, matomo, may, mstream, n8n, node_exporter, ollama, opencloud, tooljet, wallos, wekan, whitebophir, x-prober
- 6 failed apps updates: automad, dmarcguard, loki, nocodb, pocket-id, youtarr
See the full log here: https://paste.yunohost.org/raw/otelecaziw
Autoupdate dashboard: https://apps.yunohost.org/dash?filter=autoupdate
[22:40:30]
<m606> so migrations steps are logged, but do we know whether their completion is tracked somehow? i.e. are all SQL migration scripts run at each upgrade ? or does Diesel remembers which one were already successfully run?
[22:41:23]
<m606> and if they are run at each upgrade, what changes in this release where mysql behaves different from before
[22:42:29]
<orhtej2> > <@m606:matrix.org> so migrations steps are logged, but do we know whether their completion is tracked somehow? i.e. are all SQL migration scripts run at each upgrade ? or does Diesel remembers which one were already successfully run?
The full log contains names of migrations ran
[22:42:40]
<orhtej2> so no output=no missing migrations
[22:42:41]
<m606> for instance in 0.22.0 log it says it is running the migration, but I don't see the detail of the SQL command being run
[22:42:52]
<orhtej2> > <@m606:matrix.org> and if they are run at each upgrade, what changes in this release where mysql behaves different from before
nothing, now it fails even with no upstream bump
[22:47:48]
<orhtej2> as in the problem doesn't seem to stem from neither syncstorage nor diesel