• Replace icon with preferences-desktop-gaming

• Use reconfigure macro

• Install bash completion to correct directory

In T8507#161485, @DataDrake wrote:

I'm averse to adding any new modules if they aren't going to be used. The more modules there are the slower the boot process, the more memory the kernel uses, etc. They don't even have to be loaded to have an impact. Just the kernel knowing they exist is enough.

In T8507#161481, @DataDrake wrote:

It absolutely was designed for Intel chips. Rafael works for Intel and is being paid by them to work on the power management and ACPI subsystems of the kernel. So if it's slower performance and higher power consumption on Intel, this obviously isn't ready for prime-time.

The results on my desktop were interesting. At complete idle, the system was drawing about a watt less with TEO enabled. With some things running, the system would jump up to a higher power usage every so often, and then go back down. The duration of the higher power usage seemed to be lessened with TEO enabled.

@DataDrake Battery discharge on my i5-7200U laptop at complete idle went up by 50 mW (from 2.90 W to 2.95 W), although I don't think TEO was designed with Intel chips in mind. I'll look into results with my Ryzen 3700X, and I'll also see if I can get results from someone with a Ryzen laptop.

I can test idle battery usage on my laptop and wall power on my desktop. Laptop will be more granular.

I've built the kernel with CONFIG_CPU_IDLE_GOV_TEO=y and set the cpuidle governor to teo in boot params. Performance seems to be about the same, will test with openbenchmarking soon.

Just to be clear, I'm not suggesting this be the default necessarily, but I do think it's worth including in the kernel build for those who wish to use it.

In T6658#161250, @DataDrake wrote:

Pretty simple really. Each JDK should have its own directory in /usr/lib64. None of the JDKs should have symlinks in /usr/bin. Everything that uses Java will need to be patched so that they don't call /usr/bin/java, but instead call JAVA_HOME/java. This might be as simple as changing a shell script from /usr/bin/java to /usr/lib64/openjdk-<num>/bin/java or setting JAVA_HOME in a .desktop file.

The unfortunate truth, though, is that some software (like Gradle) now *requires* building with JDK 9+, so if we're not bundling multiple JDKs at a time, we need to make a decision. Do we shed software like Kotlin and upgrade to a newer JDK, or do we stay on JDK 8 and allow commonly used Java packages like Gradle to rot?

Not everything here builds with 11 either. Read the original post, it shows which packages have been tested and either fail/succeed building with 11.

Because (and I'm estimating here) *none* of the packages on this list build with, or fully support, JDK 13. That's the problem here.

Maybe we should create a new package called openjdk and start with JDK 9 for now, since most (if not all) things that we package support it. As more packages add support for higher JDK versions, we can update the openjdk package to newer major versions.

Rebuilt against Gradle

Added bash completion from gradle-completion as per T8483

Actually, scratch that, I'll just update D7512, since it hasn't landed yet.

@JoshStrobl Fine with me. I'll add it to the Gradle package and submit a differential.

@DataDrake Should I add a MAINTAINERS.md file to this package when I update it to 1.3.60?

Does appear to be NVMe related, yes. My 970 Evo NVMe has the SMART data option greyed out, but my 850 Evo SATA has the option available.

Yeah, I did. Edited. Thought I remembered the task lol

First, T80.
Second, Solus does support the RPM package manager, although it's not recommended for most cases. If support for that printer really is a dealbreaker, you can install rpm from the software center, and use the automatic driver installer that Brother provides to install the drivers via rpm instead of eopkg. I do it for one of my machines.

Remove whitespace that bothers me

Fix incorrect hashes, now builds successfully

In D7514#121398, @DataDrake wrote:

lol guess we are both having a day. You used the langtools hash for nashorn and have the wrong hash for both in langtools.

Fixed hash for jdk8u232-ga.tar.bz2 and changed source URLs

In D7514#121386, @DataDrake wrote:

9958a19a9064a18e4cf249734ff1c03ad30444bff277d560027d02b8be5c3a68 corba-u232-ga.tar.bz2
ed88a5db0e9d1f81ff966e18940e1d7d9a3256aa324b396eb0e097893291d537 hotspot-u232-ga.tar.bz2
4b402bc08e642acb2b42833996e70b284a1a02c70d4cc96ac4ece1802daeb892 jaxp-u232-ga.tar.bz2
70276b4e04ec0d3f0d936f541ff27ee4e28602f28dfab7208b44a95ffa2f1a24 jaxws-u232-ga.tar.bz2
23abb7e548611b19fc24802165d27d217657d6648b4688573a0430168e86ea77 jdk8u232-ga.tar.bz2
4c51f8063382065ea4440c4ed37695408401a0aead314a1d185d4fc4b2c36b6f jdk-u232-ga.tar.bz2
bb8b55208e72ee59dd27ca033563f312ba5608685845efdf2882ce3eafcde1c3 langtools-u232-ga.tar.bz2
65401a6f11f67c198b54846fd8e28d452ffcb95939943c432f27e01d01fde29a nashorn-u232-ga.tar.bz2
Should do ya. The next version of ypkg will support multiple sources. Sorry for the current inconvenience.

Woke up just in time! I'm attempting to build with the updated sources after changing the hash, and I'm getting an error in solbuild that I'm not sure how to solve.

mount: /var/cache/solbuild/unstable-x86_64/openjdk-8/union/home/build/YPKG/sources/corba-8u232-ga.tar.bz2: mount point does not exist.
ERRO[12:08:23] Failed to bind mount source                   error="exit status 32" target="/var/cache/solbuild/unstable-x86_64/openjdk-8/union/home/build/YPKG/sources/corba-8u232-ga.tar.bz2"
ERRO[12:08:23] Cannot continue without sources              
ERRO[12:08:24] Failed to build packages

The tag path for the previous version appeared to be invalid, so I used the GitHub mirror's tag instead. I would have used the tags from https://kernel.ubuntu.com, but I couldn't find a tarball download link.

Thank you :)

Still not fixed in stable, as of the update to 5.3.7.

This was built with a slightly different package.yml due to my inability to upload sources to dev.getsol.us, but the resulting pspec should be the same if I didn't make any mistakes in converting it back.

This is the newest version I could upgrade to without build errors due to various factors. Gradle versions past 4.9 either fail to compile without JDK 9+, or outright refuse to compile without JDK 9+. This Gradle update was necessary to upgrade OpenJFX 8.

Of note:

• The buildscript uses the project's provided Gradle wrapper, and thus does not depend on the repository's version of Gradle. The current version of Gradle in the repository doesn't work correctly with this project, since it's so far behind (3.5.0 -> 5.5.0). If Solus's version of Gradle is updated to a more recent version, this requirement can be lifted.
• Networking is required to allow Gradle to retrieve the wrapper and the project's JVM dependencies.
• The compiler produces standalone executables, but requires a JDK to work correctly. It only requires JDK 8 or above, no specific versions.
• There are additional experimental targets that I left disabled.

Sure, I can maintain it. I've managed to build locally already and I closely follow Kotlin development anyway. I'll get a differential pushed soon.

Actually, do you have radeon-profile-daemon enabled? Try running

sudo systemctl enable radeon-profile-daemon
sudo systemctl start radeon-profile-daemon

and see if that fixes it. I can reproduce your issue if the service isn't running.

In T8360#159583, @JoshStrobl wrote:

Considering this resolved since we've since reverted to 5.2.x

In T8392#159605, @JoshStrobl wrote:

Prodding @serebit since he's been the one updating it.

Fix incorrect placement of ckb-next-daemon service

Might want to patch T8360 before 5.3.1 hits stable

On my system, the example dav1d decode was over 4.5x the speed of the aom-av1 decode (Ryzen 7 3700X).

Rebuilt to fix pspec

The pspec file isn't updated. Fixing now.

This appears to be fixed after upgrading to kernel 5.2.9.

@joebonrichie You absolute madman. Godspeed.

Kitty is now at 0.14.3. This diff can be closed.

¯\_(ツ)_/¯ I saw the same thing. Not a very helpful error message, admittedly.

I have a working buildscript for the HL L2390DW, @Girtablulu. Should I submit a differential?

Could be related to https://www.phoronix.com/scan.php?page=news_item&px=Linux-AMD-Analog-Input-Audio-WA.

Issue still exists, and I have had multiple people with new Ryzen CPUs come to me with the same issue, also on Solus.

Got this error again on Unstable. Disabling LSI allowed Steam to update, but it still will not launch.

Wow, my bad! Thanks @EbonJaeger.

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