You are welcome!
Glad I was able to help.

From the lightdm.log:

[+51.51s] DEBUG: Session pid=1425: Logging to .xsession-errors
[+51.79s] DEBUG: Activating VT 7
[+51.79s] DEBUG: Activating login1 session 1
[+51.79s] DEBUG: Seat seat0 changes active session to 
[+51.79s] DEBUG: Seat seat0 changes active session to 1
[+51.79s] DEBUG: Session 1 is already active
[+61.38s] DEBUG: Session pid=1425: Exited with return value 2

The last line here indicates that something went wrong with the process with pid=1425.
Can you check if ~/.xsession-errors file has anything in it?

Is it maybe worth installing the lts kernels, uninstalling all my old NVIDIA drivers and installing the latest lts ones?

You would also need to install linux-lts and boot into that kernel to try.

You can also check if the installed drivers are for the -current kernel and not for -lts -- see table at https://getsol.us/articles/troubleshooting/boot-management/en/#installing-an-alternative-kernel.

So, the way I worked around the issue initially, before fixing boot partition, is I manually copied configs for the new kernel from /boot directory to boot partition and then changed the kernel via clr-boot-manager to the new one.
For me right now this is what clr-boot-manager list-kernels shows:

$ sudo clr-boot-manager list-kernels
* com.solus-project.current.5.6.19-159
  com.solus-project.current.5.6.19-158

with the current 159 release selected.
Can you check if the new kernel shows up on your system?
If it shows up but not selected (not marked with the *), then you can try to boot into it following https://getsol.us/articles/troubleshooting/general-troubleshooting/en/#boot-into-previous-kernel.
Then if it successfully boots and you can login into DE, you can switch permanently to this kernel by running:

sudo clr-boot-manager update

My understanding is that it switches default kernel to the currently booted one.

Could be a similar issue to T9327. But I would wait until someone with more experience confirms my guess.
Maybe @DataDrake would be interested in this.

I had similar issue a while ago after a kernel update (linux-current package).
In my case I was booting into wrong kernel, which I discovered by running following command from https://getsol.us/articles/troubleshooting/general-troubleshooting/en/#display-manager-wont-start

eopkg info linux-current | head -n2; uname -a

Can you check if the above command (or the one for linux-lts) shows two matching kernel versions?

Noticed two things:

1. If I install a game via Steam and check the box for "create desktop icon" (or something like that), then the icon appears on the desktop even with "Desktop icons" disabled in Budgie settings.
2. When you click on the application in the task bar, which is running on the other workspace, it tries to open a new instance of that application on current workspace instead of switching to the workspace where the application is already running. This messes up with windows which are running in a single-instance mode, for example I can't switch to Steam if it is running on the other workspace, without manually switching to that workspace.

@liontiger23 Is it possible it's just still considered your mouse as being captured by the game?

I'm not sure if this is an issue with the update or Budgie (I don't have stable Solus Budgie, where I can test it), but I don't remember encountering it before.

Followed the instructions and the kernels have successfully been updated.
Thanks a lot!

Use explicit prefix and nuke docs

Add MAINTAINERS.md and fix prefix

Add MAINTAINERS.md

Fix copy-pasted name

I can maintain it, since I'll be using it in vifm for work and at home.

I can maintain it, since I'll be using it in vifm for work and at home.

Pinging @DataDrake to determine the fate of this task and accompanying patch. :)

Update packager name

Update packager name

Update packager name

Update packager name

Update packager name

Update packager name

Update packager name

I can submit a patch if it is accepted for inclusion.

Update source to hackage instead of github

Change GPL-2.0-or-later to GPL-2.0-only as per https://hackage.haskell.org/package/pandoc-crossref

Add MAINTAINERS.md

I've submitted a patch for review, so I guess this task can be re-opened?

@DataDrake since this issue is in the process of resolving, should I create a separate request for arm-linux-guneabihf gcc toolchain?
If you guys will figure out the correct package structure and naming scheme for these toolchains here, I will try to package arm-linux-gnueabihf based on @chax work.

Removed redundant %configure

Yes, I'll get to it in couple of days