@kyrios123 I'm aware, I sent a message there 18 hours ago and didn't get a response. Apologies for the impatience.

Udev rules are failing to apply on my desktop after the systemd upgrade, should I make a task about it?

This appears to be fixed. Closing.

Thanks @Jacalz for the kind words! It's still a work in progress, but it's *very* close to feature parity with the official Cooler Master Windows application (only the fan mirage setting and the ring's morse code mode are missing).

I'd also like to add that as a Kotlin developer myself, people are far more likely to use Gradle for Kotlin projects rather than the standalone Kotlin compiler. The standalone compiler is, in my opinion, more of a novelty.

@livingsilver94 We're not packaging JDK 9, as far as I'm aware, and Kotlin (bizarrely) requires JDKs 8 and 9 to build at the very least. Not enough people use the standard Kotlin compiler on Solus to warrant keeping it in the repo, especially not with requirements like that. If JetBrains decides to relax the JDK version requirements for building Kotlin, then I'll request its inclusion again, but I don't see that happening.

Add libcanberra as rundep, and fix dynamic loading of libcanberra via patch

System:

Host: serebit-desktop Kernel: 5.4.1-137.current x86_64 bits: 64 Desktop: Budgie 10.5.1 
Distro: Solus 4.0

Machine:

Type: Desktop System: Micro-Star product: MS-7B85 v: 1.0 serial: <filter> 
Mobo: Micro-Star model: B450 GAMING PRO CARBON AC (MS-7B85) v: 1.0 serial: <filter> 
UEFI: American Megatrends v: 1.B2 date: 10/28/2019

CPU:

Topology: 8-Core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP L2 cache: 4096 KiB 
Speed: 2199 MHz min/max: 2200/3600 MHz Core speeds (MHz): 1: 2199 2: 2197 3: 2199 4: 2200 
5: 2199 6: 2199 7: 2200 8: 2199 9: 2198 10: 2198 11: 2198 12: 2200 13: 2199 14: 2199 
15: 2199 16: 2200

Graphics:

Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] driver: amdgpu v: kernel 
Display: x11 server: X.Org 1.20.5 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa 
tty: N/A 
OpenGL: 
renderer: AMD Radeon RX 480 Graphics (POLARIS10 DRM 3.35.0 5.4.1-137.current LLVM 9.0.0) 
v: 4.5 Mesa 19.2.6

Audio:

Device-1: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] driver: snd_hda_intel 
Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel 
Device-3: Blue Microphones Yeti Stereo Microphone type: USB 
driver: hid-generic,snd-usb-audio,usbhid 
Sound Server: ALSA v: k5.4.1-137.current

Network:

Device-1: Intel Wireless-AC 9260 driver: iwlwifi 
IF: wlo1 state: down mac: <filter> 
Device-2: Intel I211 Gigabit Network driver: igb 
IF: enp34s0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
IF-ID-1: virbr0 state: down mac: <filter> 
IF-ID-2: virbr0-nic state: down mac: <filter>

Drives:

Local Storage: total: 5.23 TiB used: 2.32 TiB (44.4%) 
ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO 500GB size: 465.76 GiB 
ID-2: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
ID-3: /dev/sdb vendor: Western Digital model: WD10EZEX-08WN4A0 size: 931.51 GiB 
ID-4: /dev/sdc vendor: Western Digital model: WD40EZRZ-00GXCB0 size: 3.64 TiB

Partition:

ID-1: / size: 453.31 GiB used: 163.82 GiB (36.1%) fs: ext4 dev: /dev/dm-1

Sensors:

System Temperatures: cpu: 50.6 C mobo: 38.0 C gpu: amdgpu temp: 41 C 
Fan Speeds (RPM): fan-1: 0 fan-2: 922 fan-3: 846 fan-4: 938 fan-5: 0 fan-6: 0 gpu: amdgpu 
fan: 882

Info:

Processes: 358 Uptime: 1h 40m Memory: 15.65 GiB used: 3.71 GiB (23.7%) Shell: bash 
inxi: 3.0.37

In T8464#161850, @kccit wrote:

I'm wondering if it's an intel vs amd issue above. Does anyone that run AMD have this problem with R or is it intel only?

• 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) with TEO enabled, which I'm not necessarily sure is statistically significant. 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 T83.
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