@jdaviescoates that's the correct behavior. it's being rolled out in phases. are you expecting something else?

the alternate message here would be "This update is being rolled out." but given our small team size, we want something deterring people from all updating at once.

I think in @msbt 's case the Cloudron already updated to 9.1.x unexpectedly (from a previous post). So, this is expected. For those on 9.1.x already, it is correct to update 9.1.0 -> 9.1.1 -> 9.1.2 -> 9.1.3 . Basically, we can't and don't test all the possible code paths when we make new releases. 9.0.17 -> 9.1.3 was explicitly tested since most people are on 9.0.17.

I made an incorrect change when incorporating bugsink into our app store code. This is fixed now.

@timconsidine 9.1.3 is being rolled out . The upgrade path will be straight from 9.0.17 to 9.1.3

@robi great find! will give it a try.

@msbt yes, we have started the roll-out.

@robi yeah, both play fine! That is why I was wishing this was a text file, so I could easily spot which is the correct one.

I actually have my pre-COVID data/backups burnt in DVDs But I don't have a DVD reader anymore.

v8 is out but requires Cloudron 9.1

We released backup integrity computation in 9.0 . In 9.1, we have added the verifier. At a high level, it stores sizes and hashes of the files in a file called .backupinfo alongside the backup itself. The .backupinfo is further checksummed and stored in the database so that it's signature can be verified when it's put to use.

The main intention was to catch bugs in the backup logic and also to theoretically detect bitrot. While testing, we already found some bugs in the rsync logic. There was a situation where the code will not delete non-existent files and the backup will end up with superfluous files.

Generally, my approach has been to blame the code whenever I see an integrity check fail. Today, I noticed that my own backups are failing integrity checks. Debugging further, I found that exactly one video file fails the check. The size of the file matches but the hash is different. I found this (built-in) tool called cmp:

# cmp VID_20200712_143638936.mp4 '/home/yellowtent/appsdata/19709657-2cf0-4d3f-8b79-429429d95b17/data/libraries/photos/USA - Jul 2020/VID_20200712_143638936.mp4'
VID_20200712_143638936.mp4 /home/yellowtent/appsdata/19709657-2cf0-4d3f-8b79-429429d95b17/data/libraries/photos/USA - Jul 2020/VID_20200712_143638936.mp4 differ: byte 26595693, line 101836

OK, so it differs in byte 26595693 . I found that I can start checking other bytes from an offset using the -i arg.

# cmp -i 30000000 VID_20200712_143638936.mp4 '/home/yellowtent/appsdata/19709657-2cf0-4d3f-8b79-429429d95b17/data/libraries/photos/USA - Jul 2020/VID_20200712_143638936.mp4'
<nothing>

OK, so it is fine from offset 30000000 to EOF (which was 84666735).

Bisecting slowly.... mostly because I thought I was going to find the unthinkable.. and I did!

# cmp -i 26595693 VID_20200712_143638936.mp4 '/home/yellowtent/appsdata/19709657-2cf0-4d3f-8b79-429429d95b17/data/libraries/photos/USA - Jul 2020/VID_20200712_143638936.mp4'
<nothing>

Wow.. actual bitrot in offset 26595692 . Well , what's in that specific byte?

# xxd -b -l 1 -s 26595692 VID_20200712_143638936.mp4
0195d16c: 01010011                                               S
# xxd -b -l 1 -s 26595692 '/home/yellowtent/appsdata/19709657-2cf0-4d3f-8b79-429429d95b17/data/libraries/photos/USA - Jul 2020/VID_20200712_143638936.mp4'
0195d16c: 00010011                                               .

Wow, 1-bit flipped. I have never seen this in real life I wish this was a text file, because I don't know which is corrupt now - the backup or the original

This whole thing got me unreasonably excited, thanks for coming to my TED talk.

Funkwhale is a community-driven project that lets you listen and share music and audio within a decentralized, open network.

Forum category is at https://forum.cloudron.io/category/219/funkwhale
The docs will be at https://docs.cloudron.io/packages/funkwhale/
Package repo is at https://git.cloudron.io/packages/funkwhale-app

Thanks to @rmdes for the initial package!

hi yes, thanks @rmdes . Let's discuss any issues in the Funkwhale category.

App updates are already separate from Cloudron updates. But maybe you mean the separation of the automatic update flag , will get to that in the coming releases .

The .0 releases are always buggy. So, we skip those and wait for .1 . That also gives the nextcloud plugins some time to catch up with the latest release.

I guess this has to be added as an optional supervisor process - https://github.com/open-webui/open-terminal/

cc @vladimir.d

AI makes sense, will add.

We delisted this because upstream was increasingly out of date and has not seen a new release in 14 months - https://github.com/ArchiveBox/ArchiveBox/releases/tag/v0.7.3 .

Not sure what is the best approach here. Would people rather see old/out of date apps? No warning will stop people from installing probably obsolete/insecure code. Generally, we are not in position to judge the code quality other than release times and activity.

@msbt said:

Uhh what? One of my production Cloudrons already got updated automatically 3 days ago?!

that seems quite unlikely Can you check who was the initiator of the update in the eventlog? The 'source' field will be 'cron' or some real user .

9.1 is in unstable now. I have updated the docs around packaging - https://docs.cloudron.io/packaging/ is a good starting point. https://docs.cloudron.io/packaging/publishing is the community packages docs.

We are working on AI skills around packaging, publishing and CI use:

All skills

npx skills add https://git.cloudron.io/docs/skills.git

Individual skills

npx skills add https://git.cloudron.io/docs/skills.git --skill cloudron-app-packaging
npx skills add https://git.cloudron.io/docs/skills.git --skill cloudron-app-publishing
npx skills add https://git.cloudron.io/docs/skills.git --skill cloudron-server-ops

I have fixed this for the upcoming release

This is indeed a bug. If a volume is missing during restore, the app should simply error when restoring. Currently, it is restoring to the volume's mount path. Given that the volume is missing/somewhere else, it ends up in the root filesystem. Will get this fixed.