Simplify cabal options, since static linking is the default

Simplify cabal build options, since static linking is the default

Simplify cabal options, since static linking is the default.

Simplify options and remove shared library, which produced missing dependency on polyparse.

Looks like xmonad and xmonad-contrib must provide all their dependencies either way.
xmonad configuration is done by compiling a Haskell script which uses XMonad and other related packages.
And in order to compile it all of the dependencies must be registered in ghc.

However, I am not sure if we want the package to be named ghcup or ghcup-hs (according to GitHub project name).

I will be able to package it after Haskell stack is upgraded (T10518).

In T10518#200866, @GZGavinZhao wrote:

My personal opinion is that the ghc in our repo is solely for the purpose of packaging. If users/developers want to develop in Haskell, they should install ghcup from our repo and fetch their desired GHC/cabal/stack/hls from ghcup and not from us. Therefore, I don't think there's a need for haskell-language-server. Instead, ghcup should be on a similar important level like ghc and cabal are.

I think it would also make sense to remove haskell- prefix from haskell-cabal-install and haskell-stack after the stack is upgraded.

As a proof of concept I rebuilt shellcheck with static linking in D14091.

cc @biqqles

Update package version

Use proper author name

Use proper author name

Use proper author name

Use proper author name

Oh wait, I see that we already have hyperfine in repositories, which is a more advanced and better supported tool for benchmarking.
So I think we will switch to hyperfine at work.

I can maintain it, since I'll be using it at work.

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