There is an updated pull request by T0mstone against master on the void-packages repository

https://github.com/T0mstone/void-packages uxplay
https://github.com/void-linux/void-packages/pull/44875

New package: UxPlay-1.68.3
<!-- Uncomment relevant sections and delete options which are not applicable -->
Spiritual successor to #33191.

#### Testing the changes
- I tested the changes in this PR: **YES**

#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**

<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->

#### Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - x86_64-musl

#### OpenSSL
> UxPlay's GPLv3 license does not have an added "GPL exception" explicitly allowing it to be distributed in compiled form when linked to OpenSSL versions prior to v. 3.0.0 (older versions of OpenSSL have a license clause incompatible with the GPL unless OpenSSL can be regarded as a "System Library", which it is in *BSD). Many Linux distributions treat OpenSSL as a "System Library", but some (e.g. Debian) do not: in this case, the issue is solved by linking with OpenSSL-3.0.0 or later.

~~How does Void handle this? Can OpenSSL be considered a "System Library"? Once #37681 lands, this won't be a concern anymore, of course. Until then, I've made the package `restricted=yes` for now.~~

**Update**: Since OpenSSL is now on version 3, I have removed the restriction.

A patch file from https://github.com/void-linux/void-packages/pull/44875.patch is attached