Arch Linux User Repository

@teJECSke Please stop flagging this package as out of date unless a new version is available on the link marked as Upstream URL on this page !!!

Updated to 5.14.32.3

@mylux, yes, since I am depending on java-runtime=11, i think the webpage is not reflecting that. it just shows all versions. I could mandate jre11-openjdk but then users will have to install multiple java version if they also use a different version for some other program. I'll also have to update the omada-controller script to use java 11 instead of depending on the default -- as users could have a different default version of Java. I have Omada installed in a Proxmox Container which is only for Omada Controller, so I never have more than 1 service/programs in each container anyway.

@Inxsible, nevermind, I see that you have re-released fixing java version to 11. That is enough. I was tricked by the webpage that didn't update the java versions in the dependency

@Inxsible, that will work. I think I did basically the same to get it to work on my side. Thats why I suggested that we change the java version in the dependencies to 11, because if the end user selects another version for the runtime,such as jdk23, it will not work. Additionally, I don't imagine any good reason to allow the user to select a different java version if the functionality will be limited. Don't you think it's better?

@mylux, yes my previous backups were all made without using your PR. I have a nightly backup schedule to my nextcloud server from within Omada. I do see that something has changed since Sept 2024 -- previously all my backup cfgs were No Limit -- that is all data, but since Sept it is only backing up Settings. The cfg file sizes have reduced from ~300kb to ~13kb. So that's something I might have to look into again.

But I have switched to jre11-openjdk, but still using java-runtime as the dependency, instead of mandating jre11 package. Also Omada released a new version just yesterday, so I'll incorporate that as well.

Thanks for your PR. !

@Inxsible, Did your previous and non-working backups were made using a previous version of the Omada Controller? I remember having seen something regarding this no retro compatibility over those versions. Also, It's interesting to know that you had functional backups. I have never been able to make a restore working with Omada without the changes in the startup script, but I could generate the backup BTW. I don't remember testing if backups generated without the improvements in the startup script would be restored after fixing the script, though. I am glad that my PR helps and that you'll be re-releasing this package.

@mylux, I have been testing this out as well and I agree that java 11 is required for the backup to restore properly. Also, even after changing to java 11 and adding those options as in your PR, I still cannot restore successfully any of my previous backups. When I created a brand new backup, that was the only file that actually successfully restored. So it could be that all old backups might become obsolete once you change the java version and or the options. I'll merge your PR and re-release this version with jdk11

The dependencies of this application should be ONLY jdk11, because other versions don't work entirely. The restore backup function results in failure with exceptions related to java.reflection.

To make this function (and all the rest) working the user must be using jdk11 to boot the jsvc application and also apply changes in the startup script with some options added.

I also created a PR proposing the changes in the startup script here

@andrewSC, yeah I noticed that too. Not sure how the ownership changed, but I can add a chown -R omada:omada /opt/omada-controller in a post install when I update the PKGBUILD next time.