I also think option #1 would be better as immediate fix but let me explain something.

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.

@TheVivaldi that's Rust version 1.32.0 which internally uses Cargo 0.33.0 (note 0 at the beginning). Rust and Cargo versions are misaligned so the developers started to print Rust version instead (to make it less confusing).
It's "cosmetical" change but to follow packaging pattern the version should be 0.33.0.

Long time ago rust wasn't tied so much to cargo and they were downloaded separately so it made sense.

It actually updated cargo to version 0.33.0 (it's rust_version + 1).

Has been fine up till now, and then in a minor glitch, I got some patchy squares to appear around my screen (they went away after I clicked a window).

One does not simply rebuild package without its source code.

I'm wondering if it's not aa-lsm-hook issue because snapd works fine with Apparmor on Arch Linux.

Shame on me.
Thanks for the fix.

I haven't worded it properly. There is no need to switch to Clang ASAP it's good to prepare ground for it regarding their statement:

The build system will soon choose clang by default on all builds, but won’t enable PGO/LTO.

IMHO Firefox 63 sounds like a good target to build it with Clang and invite more people to test it for regressions.

Basically the Speedometer2.0 and ARES-6 results are slightly better with the GCC build, MotionMark runs faster with the Clang.

For ARES-6 less is more and for Speedometer2.0 more points is better. That means Clang was faster/neutral in every case (on your machine).

Looks similar to https://dev.solus-project.com/T6499.
Run this command and see if it helps:

sudo usysconf run -f

Possibly related to https://dev.solus-project.com/T6499

Gnome-keyring is being replaced by libsecret as "less evil" solution. Opened https://dev.solus-project.com/D3532

Seems fine now:

$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/snap/bin

Thanks, I didn't know Phabricator supports markdown.
In the past the changelog was tweaked post release but those changes weren't big so yeah the tag should be fine.

Fix zsh completion location

In T6499#124711, @sunnyflunk wrote:

In T6499#124708, @mati865 wrote:

It doesn't seem like issue with specific snaps but rather snap daemon. Any snap that you install without --classic argument can cause the issue.

Just needed one example :P

Snaps you mentioned should expose problems if something goes wrong. Yesterday helm and postman snaps weren't working for me unless I reloaded AppArmor rules.

but today everything (installing, running, etc) works fine.

So it's not an issue anymore then?

In D3488#55742, @joebonrichie wrote:

Do we need openmp for emul32 here? It seems to me it can be disabled like lld and lldb for emul32.

Addressing review comments

It doesn't seem like issue with specific snaps but rather snap daemon. Any snap that you install without --classic argument can cause the issue.
Yesterday I had to run sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/* every time after installing snaps but today everything (installing, running, etc) works fine.

I originally didn't use void and strdup, but at some point in having nfi what I was doing they worked around [courtesy of Google search] whatever issue I was having (I guess one of the returns wasn't a proper char variable). I guess once I tidied everything up, it was actually doing what I had originally intended.

I haven't been using pure C for quite some time but:

I'm almost done, differential should be ready today evening CEST.

FYI Netbeans 9.0 has been released just today: https://netbeans.apache.org/download/nb90/nb90.html

The project has been abandoned, if somebody wants motherboard with nice Linux support AsRock seems the only way.

@DataDrake it was moved to Apache Incubator and it seems version 9.0 should be coming soon: https://netbeans.apache.org/download/index.html
Git repo: https://github.com/apache/incubator-netbeans

I had the same issue on Arch Linux after update recently. I was able to fix it by disabling then enabling anti-aliasing and rebooting.

@sunnyflunk I only have some experience with docker.
containerd? I think I've heard this name before.
runc? Didn't know something like that exists.

Ping, I guess.

So it looks like Nvidia forums is the last hope.

There should be line nvidia-persistenced:x:143: in /etc/group.
If it's not there then something went terribly bad and other issues can be harder to fix.

Doesn't look good:

Apr 16 11:06:30 a nvidia-persistenced[599]: Failed to query NVIDIA devices. Please ensure that the NVIDIA device files (/dev/nvidia*) exist, and that user 143 has read and write permissions for those files.
...
Apr 16 11:07:38 a kernel: nvidia-modeset: Allocated GPU:0 (GPU-370ccae8-0775-8452-4bee-a9b6b7f874e9) @ PCI:0000:01:00.0
Apr 16 11:07:38 a kernel: nvidia-modeset: Freed GPU:0 (GPU-370ccae8-0775-8452-4bee-a9b6b7f874e9) @ PCI:0000:01:00.0

Could you check if you have anything like nvidia inside /dev/?

Your latest logs contain clue:
dmesg:

[    2.746003] NVRM: API mismatch: the client has the version 390.48, but
               NVRM: this kernel module has the version 390.25.  Please
               NVRM: make sure that this kernel module and all NVIDIA driver
               NVRM: components have the same version.

Somebody using laptop with working nvidia drivers could compare (or post) their Xorg.log, journal and dmesg with nvidia-bug-report.log.gz posted earlier in this thread. I cannot help any further.

So most nvidia drivers are not usable.

Builtin smoketest works fine for 60 Hz and 75 Hz screens:

$ smoketest 
300 presents in 5.0106 seconds (FPS: 59.8731)
301 presents in 5.01666 seconds (FPS: 60.0001)
300 presents in 5.01651 seconds (FPS: 59.8026)
$ smoketest 
376 presents in 5.01259 seconds (FPS: 75.0111)
375 presents in 5.00172 seconds (FPS: 74.9742)
375 presents in 5.00192 seconds (FPS: 74.9712)

I'm not against john in any way, it's a good tool that I had used before.
However statement about requirement of Ryzen is misleading as it works fine on Intel CPUs.

AMD users need a Ryzen CPU with an RX card in order to utilize it as it uses AMD's new Rocm OpenCL

only needed for an older kernel

I'm using linux-current but created this task before 4.15 hit repos.
Now when 4.15 doesn't cause problems anymore lts users could switch.

In D2427#38551, @DataDrake wrote:

Were there no abi_ files? Those need to be included too.

@pandinusimp you linked outdated mirror, here is updated: https://github.com/mirror/jdownloader

Installing/Updating packages shouldn't modify config files inside $HOME at all.

@JoshStrobl I assumed using upstream changelog as-is is fine.
Removed irrevelant points and fixed Budgie note.

You can also override gtk-theme-name for Guake 3 in dconf.

KDE with proprietary Nvidia drivers tends to set too low DPI so font appear too small.

0.9.52 builds and works fine with updated patch

If we get this built from source, how would that block updating LLVM? I feel like it’d mean we couldn’t upgrade .NET Core until it supported clang 6.

Regarding compiz with Budgie: https://solus-project.com/forums/viewtopic.php?p=15044&sid=692b9b863d8452ff3d40a88e1a02b8eb#p15044

Clang/LLVM 6 is going to be released early March and upgrading to Clang 5 took them over 5 months.
Maybe it would be better to repack prebuilt packages like Arch does to avoid blocking LLVM upgrade for next half year?

Should I upgrade package to latest stable or edge release altogether?
https://docs.docker.com/release-notes/docker-ce/

Upstream released Dracut 047 yesterday and it contains mentioned commit.
Maybe someone affected by this bug could upgrade package and check if it helps?

Most of system directories are created with 0755 so they are read-only for non-root users.
Solus doesn't ship /usr/local so it must have been created either by you or installer (like sudo make install). Actually sudo mkdir would create directory with correct 0755 permissions so
buggy install script is the suspect here.

Whenever I tried to install Solus in /dev/sda5 as my second OS, the BIOS entry never showed up.

Arch package is working great, it can be used as base.

There is something weird going on with Nvidia dGPU recently: https://dev.solus-project.com/T5701

Possibly related https://dev.solus-project.com/T5727

I don't know how to open Steam crash dumps (probably one would need their specialized software).

Could you provide output of inxi -G?

Installing Nvidia drivers manually does huge mess in the system.
To uninstall it run installer (the same version as one used to install) with --uninstall argument and reinstall mesalib, libglvnd, xorg-server via eopkg. Then install drivers with Linux Driver Manager.

Libglvnd hasn't hit stable repo yet, are you using unstable repo?

My bad about nvidia-glx-driver, https://dev.solus-project.com/R2210:fca60614a17a5adbc40f9674c425c39748a4abdb wasn't linked to this task.

files/xorg.conf for nvidia-glx-driver-384.111 needs to be fixed, aside from that LGTM for desktop users.

Nice, I'll review them when they hit the repo.

Reopening mesa.
I have Nvidia and Xorg packages changes on the old machine, I can send them tomorrow.

Reopening, unfortunately Xorg release will be later than expected so it might require few patches backported to work with old Nvidia drivers.

Should I reopen it?

I'm using Brave for broken websites which have problems on Firefox and I don't understand why you won't to use snap on distro that fully supports it.

@mclang Your mounts look fine, is it after changing rd.luks.uuid to luks.uuid?

From man page:

rd.luks.uuid= is honored only by initial RAM disk (initrd) while luks.uuid= is honored by both the main system and the initrd.

I haven't tested but https://github.com/marcoDallas/acpi_call_GUI_systemd might work on Solus.