This project is to enable individuals to report issues or request features that are related to the integration of Solus into existing software and/or software integration into the Solus platform.
Fri, Jul 12
@EvolutionMod i think those x86 specific, thanks for the help. I'll update the documentation.
Tue, Jul 9
Updated patch for lldb
It also should be noted LLD has still many bugs and even with version 8 many libraries will be completly broken, even more libraries will seem ok but will segfault in specific conditions. Running testsuite is reliable way to detect it but there are many packages without check step.
Sun, Jul 7
Echoing @Staudey, Minecraft seems to work fine so far:
Just built openjdk-11 and vanilla Minecraft runs fine with this new version.
Just my 2 cents contribution to this huge thing.
Starting testing against OpenJDK 11, will test all the reverse deps in the coming days. Volunteers are welcome! YAML files are provided to build your own Java. Note that a lot of the applications will need some fixing up to build and run properly.
Thu, Jul 4
Thu, Jun 27
Sat, Jun 22
Thu, Jun 20
Jun 14 2019
Test results with building packages with OpenJDK 11 instead of OpenJDK 8:
Built successfully after bootstrap
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.
May 27 2019
May 20 2019
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.
We should just be able to step through: 8-9, 9-10, 10-11, 11-12. If we can skip any steps, even better. No rebootstrap necessary.
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.
So far, the best way I've come up with for handling multiple JDKs has been to hard code both JAVA_HOME and the path of the java executable in the .desktop files or scripts for user applications. However, that solution breaks down for command-line tools like gradle. Those would require us to tie them directly to a single JDK, something that may prove confusing to end-users.
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.
Unfortunately sdkman isn't designed to support the JDK builds that we ship. It expects to use theirs.
Not sure if this helps at all, probably not as this is a pretty different use-case, but I use sdkman to manage multiple versions of the JDK (and Gradle). Easy as a single command to switch to and setup whatever JDK you need.
May 14 2019
If we need to rebootstrap from binary, that's fine.
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.
If it requires both, I'm more inclined to nuke it from the repo tbh. It's proven to be something that we can't keep up-to-date on a monolithic java stack and still no one has presented me with a way to support two or more JDK that isn't awful.
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.
Why not 12 since it is the GA release?
Unless it can be used to build and run all of our Java software, I'm still not willing to upgrade it.
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.
May 12 2019
May 11 2019
electronic-wechat was removed from repo because it's not maintained. I tried several of its forks, and found the following two promising :
May 7 2019
It looks like the Clear Linux team is no longer interested in integrating this into clr-boot-manager. If all that needed, is to mount the /boot partition before running fwupd, maybe we could consider integrating this with eopkg for the time being, and then sol later on.