@eyecreate I started over and added the IGDB info and restarted the app then proceeded with the initial account creation. IGDB's connection is valid. I uploaded a new set of NES roms that I got from Vimmdotnet (in case it was a rom issue). Ran a scan and I still don't see them. They are being detected though. What am I doing wrong? [image: image.jpeg] [image: image.jpeg] Edit: I downloaded the NES roms from the romM demo site to make sure it's not a rom issue so it must be a scan issue. I keep getting this error when manually triggering one regardless of which method I try (quick, complete, etc) Scan failed: Quick Scan is already queued

In this instance, I am referring to (say) build-essential on Debian. If I have a C compiler in my runtime image, and someone compromises the host, they can build further tooling in the host because I gave them a hammer and nails. We generally have to follow NIST guidelines, and therefore our containers: Are not writeable (generally) Contain only the packages necessary to execute the software in the container Require allow listing for egress (meaning nothing in the container can talk to the outside world); this implies an egress proxy Only allow specific connections in (ingress proxy) ... Cloudron does some of this already. (To be clear: the reason I only use the official packages, and stay up to date, is because I trust the core product. Kudos to y'all, always.) Hence, the story I'm weaving (which I think Tim is as well) is that there might be a large, common build image for Cloudron (containing all of the build tools), but the runtime image (which a multistage build would copy into) is light/tight and shouldn't contain (say) a C/C++ compiler. You generally can't avoid having your language runtime(s) (e.g. ruby), but that doesn't mean that the runtime image needs the capability to install new libraries: everything should already be there for the app to execute. Maybe that helps explain my thinking/comment.

@girish : SOLVED ! I traced it to (1) the backup in cloudron update failing, triggering update to fail, which was totally caused by (2) my ultra-minimal minibase not having sqlite3 in it and I forgot to add it manually as the packager responsibility when going ultra-minimal. Interestingly I did not discover this in testing, because I was always ticking 'skip backup'. So your approach in the other discussion is proven out ! Ultra-minimal can work but it seems not wise, because darned packagers cannot be trusted . A slightly fatter base is worth it to avoid such mistakes. You win ! Will fatten my minibase while waiting for yours. Sorry for taking up your time again.

@milohiss can you please try with the Cloudron CLI 9.0.3 ?

Thanks for packaging Bitwarden Lite. I am personally not particularly interested in it. However having an alternative to Vaulwarden on Cloudron would be appreciated. Possibly, something like Psono, AliasVault or Passbolt as a suggestion if you needed some But for now, thanks again.

TheMeerkat said: As a result of the first entry, the CloudronVersions.json link has changed: https://mirror.tangled.network/xrpc/sh.tangled.git.temp.getBlob?path=CloudronVersions.json&ref=main&repo=did%3Aplc%3Apomgtubhgnuew7wmpwgk7dzd I'll manually update the Codeberg one for a while, but you should change it at some point. actually, turns out I won't! good timing: 4.0.0 (and now 4.0.1) has breaking changes, so you should manually upgrade anyway. most notably: the secret key needs to be sent to the HeCAPTe server now, not just the public site key, bringing it in-line with other CAPTCHA services.

@IniBudi said: And my question is how to make the update process automatically from Cloudron dashboard? Do you mean you want Cloudron to track upstream releases and make new packages and have an update available? If so, there is no such feature. An idea is to automate this in your CI (Cloudron team uses renovate for it's packages).

The base image was recently updated too

@fbartels said: @joseph That is it (source: I just tried it myself and directly deleted the app again) Thank you, who would have thought ... I think some better error messages would be good to help the user understand what the issue is. @jdaviescoates said: @ekevu123 hasn't this just been added to the official app store? Not sure it needs to be in both? It apparently was added, I was never notified of that ... that's better then! Does that mean we don't need the cloudron versions file anymore, assuming any Cloudron user would prefer the app store install over the manual community package?

@NCKNE thanks for reporting, fixed . https://ca.cloudron.io/app/schuldialogplus

@loudlemur - awesome work putting it together as a community package! @james for me, and I assume others, not using the apex domain for XMPP is a non-starter. It would be like Cloudron only supporting user@mail.domain.com for e-mail addresses. Maybe some can live with it, maybe it makes it easier, but it's simply not the standard people expect. XMPP aside, there are other applications and protocols that expect to be able to validate against the Apex domain it's hosted at.

@timconsidine oh, because of open deep research and the discussion there.

Currently, proxyAuth can only protect a single path . I guess we will have to implement this feature . Most apps have however moved to real OIDC support though .

I have fixed the backupCommand to share the networking namespace with the app - https://git.cloudron.io/platform/box/-/commit/90a8ba1a4915dfbbb30f1073c4f75cd99635ae3d . This is consistent with how the scheduler/cron commands also run. Thanks for reporting!

@saikarthik sorry, i haven't found the time yet. I will take a look next week!