Currently OTPClient is packaged in the Solus repositories.

I already have this locally if Girt accepts

Well it still launches at least ^^
Unfortunately I don't have a NAS to really test the functionality. If some users can confirm to me that the version we have now is no longer functional for its purpose, then yes, I'd remove it from the Third Party Repo and guide user to the flatpak instead.

Please use the correct way for requesting packages https://getsol.us/articles/packaging/request-a-package/en/

@Staudey do suggest deprecating the existing thirdparty software in favour of the flatpak? Does it even still works?

This has already been requested. See T765.

If this is accepted, I would be willing to maintain it if nobody else is.

Could you mention @DataDrake what are the other VPN @JoshStrobl was referring to? The ones I wanted to use to connect Solus and Windows machines are Zerotier and Tailscaile,which are not in the repository. I would be curious in trying the other ones that are readily available in Solus, or at least compare them to try answering Josh's question above to support the request for Tailscale (or Zerotier).

Since this is technically a different piece of software (hence the changed name) and the Third Party Repository is deprecated, to be replaced with flatpak/snap, I guess the best solution is indeed to go for the flatpak.
Also the version of "Synology Cloud Station Drive" in Solus is actually 4.3.3-4469, which is the latest available for that discontinued software (https://www.synology.com/en-global/releaseNote/CloudStationDrive). Not 100% sure where you got that other version number from.

I know it isn't as good as a native package, but there is a flatpak package of the current version of Synology Drive Client. I've been using it without any problems for over a year.

The update was released literally two days ago, and I already pushed it to the Unstable repository a day after that: https://dev.getsol.us/R4442:f8fb77cb39d5b8560c44f9d76c70d060baeb3fc9

Still trying to figure out how to get (and verify) the bitmap fonts working, but I guess I can submit the TTF fonts for now.

Neither do gold or lld afair, ypkg will try to strip that flag out when building with clang. That logic could be extended to strip it if any other linker apart from ld.bfd is used. I do want to get rid of --copy-dt-needed-entries long-term but we'll basically have to rebuild the world to do it.

For future developers working on ypkg, note that mold doesn't yet support --copy-dt-needed-entries: https://github.com/rui314/mold/issues/530

I think waydroid needs wayland, and still depends on ashmem and binder kernel modules. I have tried to build waydroid on my system few months ago and gave up since solus doesn't support dkms. There are discussions on same issues involving anbox which also depends on ashmem and binder, to which joshua was strictly opposed to, with good reasons.

This project is under active development now (with recent releases). The next release of Budgie (10.7) will leverage switcheroo-control to launch applications with the correct GPU profile (though it is not required for Budgie to build or function; it will simply do nothing special if switcheroo-control is not present). I think this would have significant value-add for people with dual-GPU setups, since we can then switch to a dedicated GPU only when needed, helping to improve power usage and battery life.

In my opinion now the build is done, it should already be working with Vega, and is only waiting for LLVM 14 for full GPU support. I have tested it with new LLVM, it builds fine, so should be ready.
Edit: ypkg and solbuild pull requests allowing for renaming of sources need to be accepted too

Duplicate of T9796

I think the same. I had to compile it to use the network scanner.