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

Fixed newlines in description.

Fixed description

I could just use preferences-desktop-gaming in lieu of an actual icon... Although there might be a more fitting system icon available.

@JoshStrobl I'm working on a package for this, is a lack of a desktop icon an issue?

In T7606#144687, @JoshStrobl wrote:

What specifically in our repository requires this? I don't see why we would add a library when it's not a dependency of something which isn't accepted yet. If you need it personally, compile it locally.

In D5367#85879, @JoshStrobl wrote:

I'd prefer we update wayland-protocols first. If you want to provide a patch for this, that'd work for me. Otherwise, I can look into updating it this weekend to unblock this patch. Would prefer we don't regress in Wayland support, even if Wayland support for Solus still remains pretty much non-existent.

Rebuilt against updated solbuild and fixed release number.

Apparently wayland-protocols >= 1.17 is required for Wayland support to be enabled, do we drop Wayland for now or update Wayland first?

You got it, @Girtablulu. Updating now.

@DataDrake That's not why it's been sitting dormant. It's been sitting dormant because there isn't a stable release yet.

Thanks guys! Appreciate the quick turnaround

Happens on my Intel HD 620 laptop, and I’ve gotten word from someone using Ubuntu with Gnome 3 on the prop Nvidia drivers that it happens to them as well. Seems to be a Firefox issue, with that in mind.

I have an Intel HD laptop I can test with. I haven’t noticed this issue on there yet, but I’ll take a closer look and see if I can reproduce it.

https://streamable.com/k5u4h Here's video of it, with a clearer background image of a rainbow. Turns out it's not just with fullscreen video, it also happens to me with Twitch streams and YouTube videos, even when they aren't in fullscreen.

Latest sync of Budgie, on an RX 480 using the latest Mesa (18.3.1). It’s been happening for a good couple months now, but I haven’t figured out if there are any specific circumstances to make it happen.

@kyrios123 The compression does it in a bit, but on the Firefox screenshot there’s a white window on the right side, taking up about half the image. In that white window there’s a small dark rectangle on the bottom. It’s much easier to see when the video is playing.

Well that was a quick turnaround. Thanks @JoshStrobl!

@Vistaus iirc they've deferred it to a later release, as noted in the In Full Sail blog post:

For Solus 4, our primary focus at this moment in time is the finalizing of Budgie 10.5 and deferring the Software Center to a later 4.x release.

@DataDrake Newer versions of Gradle also require Java 9 to build Gradle from source, apparently. Might want to reconsider blocking JDK9 from the repos with that in mind-- without it, you may be leaving the entire JVM build system behind.

With that in mind, I suppose the question is whether or not Solus will move to Tista's separate Adapta redesign project, or continue to use the 3.94 design.

Interesting development on this front. Tista has reverted to 3.94 source, and is likely going to move his redesign to a new project.

I overstepped my responsibilities, my mistake. I'll let you guys handle the triaging.

See T7002

@Vistaus What steps do you take to build it? I'm close, but I keep getting an error:

Gtk/TermBox.vala:258.19-258.21: error: Argument 1: Cannot convert from `unowned string?' to `unowned char[]?'
                term.feed_child(cmd, -1);  
                                ^^^

I'll see if I can build this from source.