Built and tested with several games, works perfectly for me.

In D6882#108786, @JoshStrobl wrote:

You need to clone the libtas git repo and base your work on that.

Changed commit to not amend previous commit

In D6882#108755, @JoshStrobl wrote:

Please follow https://getsol.us/articles/packaging/updating-an-existing-package/en/

@DataDrake I just got home to test, and running spd-conf -d on the affected machine does produce audio with the same distortion.

Sure can, although I'm not sure if it's the cause, considering that the issue happens with any audio source in the voice channel (including bots and other users with microphones).

In D6763#107173, @JoshStrobl wrote:

Making actually looking at the breeze package history before commenting would provide some insight?

Why was this abandoned and reverted? Besides the package woes, it seemed like a positive change.

In D6763#107108, @alecbcs wrote:

After updating to the latest version in the unstable repository I can confirm that I now only have one breeze-cursor option and it works in Flatpak apps. However, after updating breeze my system reverted to Adwaita (after a reboot) and I had to reinstall the breeze-cursor theme through eopkg to get it to show up in budgie desktop settings.

Updated SPDX 3.0 license to match the project's license

Updated SPDX 3.0 license to match the project's license

Updated pspec to match package.yml

Updated pspec to match package.yml

Not yet, I realized I didn't update the pspec. Diff inbound.

Updated SPDX 3.0 license to match the project's license

Updated SPDX 3.0 license to match the project's license

Removed inappropriate license name and replaced with correct SPDX 3.0 license

What would you suggest then, @JoshStrobl? I personally believe a slow migration towards a preference for Python 3 is a good way forward, but it's not my decision to make.

Changed license to match SPDX spec

Changed license to match SPDX spec

Changed license to match SPDX spec

Update license to match SPDX spec

Change license to match SPDX spec

Changed license to match SPDX spec

Test results with building packages with OpenJDK 11 instead of OpenJDK 8:

Gradle 5.4.1

Built successfully

Maven 3.6.1

Built successfully after bootstrap

ipscan 3.5.5

Built successfully (now supports JDK 11 officially)

Currently doing testing with building the above packages with JDK 11, I believe JDK 11 is our best bet considering almost nothing supports being built with JDK 12 yet. Besides, rolling, not bleeding.

Removed unnecessary build and run dependencies. Tested with building kitty docs again to ensure stability.

Removed unnecessary dependencies

Removed unnecessary dependencies

Removed unnecessary dependencies

Removed unnecessary dependencies

Removed unnecessary dependencies

Removed unnecessary dependencies

Fixed incorrect release numbering

Note that this requires extra extensions that were split off from the main repository. These will be added as separate differentials, akin to python-sphinxcontrib-websupport, if this revision is received positively.

Removed manual installation of LICENSE

Made a working package.yml as well, built and tested.

I couldn't build Gradle with JDK 12.0.1-zulu, but I managed to do so with OpenJDK 11.0.1. I also managed to build one of my projects successfully using Gradle on the same OpenJDK 11.0.1 build.

Gradle version 5.4.1 (latest version) supports running builds with JDK 12. However, it appears to be impossible to build Gradle 5.4.1 itself using JDK 12, as the source and target compatibility is set to JDK 6, while JDK 12 appears to have dropped JDK 6 target support and only supports JDK 7 and up. In addition, Gradle 5.4.1 can no longer build using JDK 8, as it requires JDK 9 or newer. It seems to me that a move to JDK 11 may be our best option, considering these circumstances (at least temporarily).

Well, if anyone manages it, let me know. I'll be testing with a prebuilt JDK until then.

I’ll see about testing Gradle with JDK 12. I did give building the JDK from scratch a try, but writing a package.yml for the whole JDK is way above my skill level. If anyone else manages to make a working buildscript, I’ll gladly test with a fresh eopkg built from it, but I’ll have to use an existing binary until then.

We don’t necessarily need to use sdkman directly, but we could take inspiration from it for handling multiple JDKs, if that’s still on the table.

Not entirely true, it requires either a pre-built JDK 12 or a JDK 11.

As it turns out, you need to have JDK 11 installed to build JDK 12. Not sure how to handle that.

I'm not opposed to removing Kotlin (I was the one who contributed it in the first place). If anything, Gradle is more my focus now, since it's the tool that's most often used for Kotlin development.

I'll run some testing with JDK 12. I would like to note that at the moment, Kotlin requires both OpenJDK 8 and OpenJDK 9 at a minimum to build, so that's generally out of the question until either someone writes a patch or the requirement changes.

In fact, I just managed to build Gradle 5.4.1 with OpenJDK 11 only (using the JDK distributed by sdkman).

OpenJDK 9+ is now required to build newer Gradle versions. From my local testing, it would seem that OpenJDK 11 fills the requirement.

Why was this abandoned? D5611 was rejected when wayland 1.17 was still in beta. Some software like kitty is being held back by wayland still being on version 1.16.

Fork Plata-Theme into our own repo, re-introduce MATE Desktop support and merge in our metacity patch.

In D5367#93161, @DataDrake wrote:

Any word on this not that wayland-protocols was updated?

I sense an update coming... (got my hopes up 😛)

Added rundep on radeon-profile-daemon

Removed explicit rundep on xrandr

Cleaned up script, merged some builddeps, rebuilt to include descriptions