[00:56:40]
<m606> @otm33:matrix.org In case you are not already finished with this, whether specifying the `-u` arg or not calls the same function but it will work differently. Read quickly, but my guess is that `-u` forces redownloading the package from the repo in any case: https://github.com/YunoHost/yunohost/blob/265c4a4a4144260e601bb1dcc4d63ca524effd06/src/app.py#L818
whereas without, it will used cached version if there is no version change detected in the repo.
The issue you report may be due to the fact that the cache doesn't get refreshed because it doesn't see a new version number in the repo for now.
When pushing commits to master/main branch of a YNH app package for the same upstream version you are supposed to bump the package version (e.g. `~ynh2`) except these very commits don't bring anything to users having the app already installed (e.g. a change in the install script for instance), to basically avoid triggering an update for everyone for no actual use. I haven't checked `peertube_ynh`'s last commits to see if it indeed falls under this case, but maybe these few elements will help your investigation.
[00:59:59]
<m606> @otm33:matrix.org In case you are not already finished with this, whether specifying the `-u` arg or not calls the same function but it will work differently. Read quickly, but my guess is that `-u` forces redownloading the package from the repo in any case: https://github.com/YunoHost/yunohost/blob/265c4a4a4144260e601bb1dcc4d63ca524effd06/src/app.py#L818
whereas without, it will used cached version if there is no version change detected in the repo.
The issue you report may be due to the fact that the cache doesn't get refreshed because it doesn't see a new version number in the repo for now.
When pushing commits to master/main branch of a YNH app package for the same upstream version you are supposed to bump the package version (e.g. `~ynh2`) except if these very commits do not bring anything to users having the app already installed (e.g. a change in the install script for instance), to basically avoid triggering an update for everyone for no actual use. I haven't checked `peertube_ynh`'s last commits to see if it indeed falls under this case, but maybe these few elements will help your investigation.
[11:40:58]
<Chatpitaine Caverne> Thank you for the explanation.
In this case an uograde of manifest with 8.0.1-ynh2 could be convinient cause it correct an attended fail upgrade.
Anyway, malesh.
[12:23:05]
<otm33> m606: Thank you for your help and your interest in this issue. Actually, I think the cached data depends on the version of the catalog available on the server (`/var/cache/yunohost/repo/default.json`) This file seems to have been updated this morning around 7 AM. Yesterday `yunohost app manifest peertube` returned `revision: 773a86d944883017ebad05c7a02faf38e2a3f6bf` and today `revision: 4d4d2f116a7d29310452b1b9e27be72cbed7659f`. I’m currently looking for a command to force repo/default.json updating. At this time if I try to install/upgrade jitsi, I only can fetch `revision: df0a2f2df97a20fc9ec64a9071caa511eda766bb` whereas `https://apps.yunohost.org/default/v3/apps.json` shows a new revision: 50e42f37f032003651096ca443ed1b085beff927 with latest's @eric_g chnages
[12:23:23]
<otm33> m606: Thank you for your help and your interest in this issue. Actually, I think the cached data depends on the version of the catalog available on the server (`/var/cache/yunohost/repo/default.json`) This file seems to have been updated this morning around 7 AM. Yesterday `yunohost app manifest peertube` returned `revision: 773a86d944883017ebad05c7a02faf38e2a3f6bf` and today `revision: 4d4d2f116a7d29310452b1b9e27be72cbed7659f`. I’m currently looking for a command to force repo/default.json updating. At this time if I try to install/upgrade jitsi, I only can fetch `revision: df0a2f2df97a20fc9ec64a9071caa511eda766bb` whereas `https://apps.yunohost.org/default/v3/apps.json` shows a new revision: 50e42f37f032003651096ca443ed1b085beff927 with latest's @ericg chnages
[12:24:13]
<otm33> m606: Thank you for your help and your interest in this issue. Actually, I think the cached data depends on the version of the catalog available on the server (`/var/cache/yunohost/repo/default.json`) This file seems to have been updated this morning around 7 AM. Yesterday `yunohost app manifest peertube` returned `revision: 773a86d944883017ebad05c7a02faf38e2a3f6bf` and today `revision: 4d4d2f116a7d29310452b1b9e27be72cbed7659f`. I’m currently looking for a command to force repo/default.json updating. At this time if I try to install/upgrade jitsi, I only can fetch `revision: df0a2f2df97a20fc9ec64a9071caa511eda766bb` whereas `https://apps.yunohost.org/default/v3/apps.json` shows a new revision: 50e42f37f032003651096ca443ed1b085beff927 with latest's @eric_G chnages
[12:24:19]
<otm33> m606: Thank you for your help and your interest in this issue. Actually, I think the cached data depends on the version of the catalog available on the server (`/var/cache/yunohost/repo/default.json`) This file seems to have been updated this morning around 7 AM. Yesterday `yunohost app manifest peertube` returned `revision: 773a86d944883017ebad05c7a02faf38e2a3f6bf` and today `revision: 4d4d2f116a7d29310452b1b9e27be72cbed7659f`. I’m currently looking for a command to force repo/default.json updating. At this time if I try to install/upgrade jitsi, I only can fetch `revision: df0a2f2df97a20fc9ec64a9071caa511eda766bb` whereas `https://apps.yunohost.org/default/v3/apps.json` shows a new revision: 50e42f37f032003651096ca443ed1b085beff927 with latest's eric\_G chnages
[12:39:52]
<otm33> So, now update from 7.3.0 to 8.0.1 with `yunohost app upgrade peertube` works... once. Running a 2nd upgrade... fails :D
[12:44:15]
<otm33> First upgrade changes
```
{
"packageManager": "yarn@1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e",
"dependencies": {
"peertube-plugin-auth-ldap": "0.0.14",
"peertube-plugin-livechat": "14.0.2"
}
}
```
to
````
{
"dependencies": {
"peertube-plugin-auth-ldap": "0.0.14",
"peertube-plugin-livechat": "14.0.2"
},
"packageManager": "pnpm@10.28.0+sha512.05df71d1421f21399e053fde567cea34d446fa02c76571441bfc1c7956e98e363088982d940465fd34480d4d90a0668bc12362f8aa88000a64e83d0b0e47be48"
}
```
````
Info : DEBUG - {
Info : DEBUG - err: Error: Command failed: pnpm add peertube-plugin-auth-ldap@0.0.14
Info : DEBUG - Invalid package.json in package.json
Info : DEBUG -
Info : DEBUG - at genericNodeError (node:internal/errors:983:15)
Info : DEBUG - at wrappedFn (node:internal/errors:537:14)
Info : DEBUG - at ChildProcess.exithandler (node:child\_process:417:12)
Info : DEBUG - at ChildProcess.emit (node:events:519:28)
Info : DEBUG - at maybeClose (node:internal/child\_process:1101:16)
Info : DEBUG - at ChildProcess.\_handle.onexit (node:internal/child\_process:304:5) {
Info : DEBUG - code: 1,
Info : DEBUG - killed: false,
Info : DEBUG - signal: null,
Info : DEBUG - cmd: 'pnpm add peertube-plugin-auth-ldap@0.0.14'
Info : DEBUG - },
Info : DEBUG - stdout: '',
Info : DEBUG - stderr: 'Invalid package.json in package.json\\n'
Info : DEBUG - }
Info : DEBUG - ELIFECYCLE Command failed with exit code 255.
Info : DEBUG - + ynh\_exit\_properly
[12:45:07]
<otm33> First upgrade changes
```
{
"packageManager": "yarn@1.22.22+sha512.a6b2f7906b721bba3d67d4aff083df04dad64c399707841b7acf00f6b133b7ac24255f2652fa22ae3534329dc6180534e98d17432037ff6fd140556e2bb3137e",
"dependencies": {
"peertube-plugin-auth-ldap": "0.0.14",
"peertube-plugin-livechat": "14.0.2"
}
}
```
to
````
{
"dependencies": {
"peertube-plugin-auth-ldap": "0.0.14",
"peertube-plugin-livechat": "14.0.2"
},
"packageManager": "pnpm@10.28.0+sha512.05df71d1421f21399e053fde567cea34d446fa02c76571441bfc1c7956e98e363088982d940465fd34480d4d90a0668bc12362f8aa88000a64e83d0b0e47be48"
}
```
[12:46:46]
<otm33> And 2nd upgrade says :
```
Info : DEBUG - {
Info : DEBUG - err: Error: Command failed: pnpm add peertube-plugin-auth-ldap@0.0.14
Info : DEBUG - Invalid package.json in package.json
Info : DEBUG -
Info : DEBUG - at genericNodeError (node:internal/errors:983:15)
Info : DEBUG - at wrappedFn (node:internal/errors:537:14)
Info : DEBUG - at ChildProcess.exithandler (node:child_process:417:12)
Info : DEBUG - at ChildProcess.emit (node:events:519:28)
Info : DEBUG - at maybeClose (node:internal/child_process:1101:16)
Info : DEBUG - at ChildProcess._handle.onexit (node:internal/child_process:304:5) {
Info : DEBUG - code: 1,
Info : DEBUG - killed: false,
Info : DEBUG - signal: null,
Info : DEBUG - cmd: 'pnpm add peertube-plugin-auth-ldap@0.0.14'
Info : DEBUG - },
Info : DEBUG - stdout: '',
Info : DEBUG - stderr: 'Invalid package.json in package.json\n'
Info : DEBUG - }
Info : DEBUG - ELIFECYCLE Command failed with exit code 255.
Info : DEBUG - + ynh_exit_properly
```
[12:47:09]
<otm33> because default.json was changed to ...
[12:47:30]
<otm33> ```
{
"dependencies": {
"peertube-plugin-auth-ldap": "0.0.14",
"peertube-plugin-livechat": "14.0.2"
},
}
```
[12:49:13]
<otm33> with remaining comma... Might be related with https://github.com/Chocobozzz/PeerTube/blob/26441990729f81d9355b0cda72cf66e82a4e2d70/server/core/lib/plugins/package-manager.ts#L78
[14:40:15]
<otm33> m606: Thank you for your help and your interest in this issue. Actually, I think the cached data depends on the version of the catalog available on the server (`/var/cache/yunohost/repo/default.json`) This file seems to have been updated this morning around 7 AM. Yesterday `yunohost app manifest peertube` returned `revision: 773a86d944883017ebad05c7a02faf38e2a3f6bf` and today `revision: 4d4d2f116a7d29310452b1b9e27be72cbed7659f`. I’m currently looking for a command to force repo/default.json updating. At this time if I try to install/upgrade jitsi, I only can fetch `revision: df0a2f2df97a20fc9ec64a9071caa511eda766bb` whereas `https://apps.yunohost.org/default/v3/apps.json` shows a new revision: 50e42f37f032003651096ca443ed1b085beff927 with latest eric\_G's chnages
[15:28:40]
<m606> Do I get you right (I am not familiar with this package):
- you run `yunohost app upgrade peertube` a first time on your instance (upgrade from 7.3.0 to 8.0.1), and it gets completed as expected ?
- the `package.json` you mention is this file https://github.com/Chocobozzz/PeerTube/blob/release/v8.0.x/package.json located on your instance in `/var/www/peertube/package.json` ?
- I guess you cannot run the exact same command a second time because it won't find available upgrade, but you can maybe use `yunohost app upgrade peertube -F` (forced upgrade from 8.0.1 to 8.0.1), and there you've got the error mentioned (it is not shown in the log extract, but probably related to https://github.com/YunoHost-Apps/peertube_ynh/blob/017310aa17922bcab32516cb0af2fc0e1092b24e/scripts/upgrade#L116) ? This error is specific to 8.0.1 or it also happens when upgrading from 7.3.0 to 7.3.0 for instance?
[15:46:22]
<otm33> odd upgrades work, even upgrades fail 😁
[15:47:39]
<otm33> m606: No, this is the package.json generated for plugin installations, in `/home/yunohost.app/peertube/plugins/`. My guess is that pnpm _appends_ this file and then `packageJSONContent = packageJSONContent.replace(/\s*"packageManager".*/g, '')` removes the line except the comma separator. Removing that comma, the upgrade does work again and so on...
[17:13:33]
<m606> i lack context elements (point 1 & 3 of my previous message, and more probably) and can't test myself, but the regex in the `replace()` statement simply remove all the line containing the string `packageManager` as in ` "packageManager": "pnpm@10.28.0+sha512.05df71d1421f21399e053fde567cea34d446fa02c76571441bfc1c7956e98e363088982d940465fd34480d4d90a0668bc12362f8aa88000a64e83d0b0e47be48"` (including a trailing comma separator if there were one).
[17:22:00]
<otm33> m606: Sorry, I should have clarified that it doesn't remove the preceding comma separator when it exists. At first installation, "packageManager" is set at the beginning of the json, so removing this line doesn't cause any problem. The thing is that the upgrade appends this line at the end of the file. So removing it leaves a trailing comma separator.
[17:30:29]
<m606> ah indeed that makes invalid json, this regex would work better `/,?\s*"packageManager".*/g`
[17:34:47]
<otm33> m606: let's patch ?
[17:37:42]
<m606> sure, do you have a github account ?
[17:44:04]
<otm33> m606: https://github.com/otm33GH/peertube\_ynh/tree/patch\_PM
I will test it later. Let me know.
[17:46:31]
<Chatpitaine Caverne> In case you do it and merge it to master. Can you modify the manifest.toml file too, in order to have a -ynh2 cause I'm sure a lot of people are waiting to see that appear, telling them that the upgrade failure could be solved.
[17:48:58]
<artlog> i get a problem with a yunhost-api that fails with MemoryError on my raspberry Pi3+with 1G of RAM . I actualy don't know why now it requires so much memory...
[17:51:06]
<artlog> i wonder if my filesystem was not corrupted at some point. still this is a prototype thing for demo, it has no swap and it on a sdcard only but such thing did work in the past...
[17:56:32]
<artlog> well might be sdcard only system are not supported anymore for yunohost ?
[17:57:40]
<Chatpitaine Caverne> They (SD cards) still are supported. I did test recently on a Pi5 for preparing a migration to it.
[17:57:45]
<artlog> i see a smartmontool dependency on yunohost , and smartctl is failing since there no smart device on my device
[17:58:54]
<Chatpitaine Caverne> Well I had one smart device connected too. So. Don't know.
[18:04:36]
<m606> ok, I am not familiar either with diff patches via YNH (I thought of updating YNH upgrade script in the first place with `ynh_replace`command to package.json directly). Will this work for all required versions? and stop being applied if fixed upstream?
[18:07:37]
<otm33> It will fail miserably if an upstream change is made, but the patch simply won’t be applied. AFAIK...
[18:12:12]
<artlog> Clearlypython3 requesting 4G of RAM is not that cool : '[ 25.034789] __vm_enough_memory: pid: 833, comm: python3, bytes: 4295249920 not enough memory for the allocation'
[18:13:32]
<artlog> there might be something wrong in my configuration having a bad side effect. i tried to install borg lciet and borg server , might be colateral effect even after removal
[18:14:42]
<m606> and will work if some upgrade from 5.0.2 or 7.0.3 indifferently?
[18:21:40]
<artlog> or it is just that python3 requires a swap. On my other system there is a 4G swap ... but it has a ssd.
[18:22:07]
<artlog> tried zram, but with 1G of RAM i can't get to 4G ...
[18:26:04]
<artlog> id did used image given in official documentation https://doc.yunohost.org/en/admin/get_started/install_on/raspberry_pi/ and that's it.
[18:27:16]
<artlog> but it was indicated taht install was a 'bit broken' , not sure where ... at least it did work last week ...
[18:31:34]
<lautre> Do you know if `bonfire` need `meilisearch-bonfire` working to works?
[18:34:19]
<lautre> In the log, I have : `meilisearch[2736779]: Error: Your database version (1.28.1) is incompatible with your current engine version (1.32.1)`
I don't know if it's because I have Peertube (that install a meilisearch too) that made a problem
[22:27:21]
<otm33> lautre: sources were updated and version 1.32.1 installed but I guess that `/home/yunohost.app/bonfire/meilisearch/VERSION` is still 1.28.1 ? It can be manually modified.
[22:28:13]
<otm33> I don't know...
[23:10:45]
<lautre> I asked to someone to install bonfire.
Did it on fresh empty Yunohost.
Bonfire worked fine.
So, the problem should be on my Yunohost.
And, meilisearch-bonfire isn't needed to make bonfire service working (web page wasn't tested, but Bonfire service looks working fine without meilisearch)
[23:52:53]
<Craig van Beek> Everytime with this domain it won't renew certificates https://paste.yunohost.org/raw/ovedayoluh