Cleanup dependencies

Rebuild against ghc 8.6.5 and pandoc 2.5

Rebuild against ghc 8.6.5

Rebuild against ghc 8.6.5

Rebuild against ghc 8.6.5

Rebuild against ghc 8.6.5

Rebuild against ghc 8.6.5

Rebuild against ghc 8.6.5

Fix padding

Rebuild against pandoc 2.5

Remove %cabal_register

Removed %cabal_register

Or should I rather go and submit it as an issue to vifm developers?

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 you likely no manual copying is needed, since you already fixed the boot partition

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