Prepare 1.6.1.1 (only hackage release) (backport #2681) (#2684)

* Prepare 1.6.1.1 (only hackage release) (#2681)

* Disable -dynamic for all workflows

* Remove quotes

* Bump version to 1.6.1.1

* Update changelog for 1.6.1.1

* Correct flag set

* add comment to ci step

* Restore header and link

(cherry picked from commit 9d75cc5)

# Conflicts:
#	ChangeLog.md

* Fix merge conflict

Co-authored-by: Javier Neira <atreyu.bbb@gmail.com>

Author: mergify[bot]

.github/actions/setup-build/action.yml

@@ -63,10 +63,19 @@ runs:
         fi
       shell: bash
 
+    # The default build for haskell-language-server executable is dynamic for linux and macOS
+    # to get a executable which works for Template Haskell
+    # However we continue providing full static executables in releases so we have to disable it
+    # *for all workflows*, including test, flags and release builds
+    - name: Disable -dynamic
+      run: |
+        echo -e "package haskell-language-server\n  flags: -dynamic" >> cabal.project.local
+      shell: bash
+
     - if: inputs.os == 'Windows' && inputs.ghc == '8.8.4'
       name: (Windows,GHC 8.8) Modify `cabal.project` to workaround segfaults
       run: |
-        echo -e 'package floskell\n    ghc-options: -O0' >> cabal.project.local
+        echo -e 'package floskell\n  ghc-options: -O0' >> cabal.project.local
       shell: bash
 
     # Shorten binary names as a workaround for filepath length limits in Windows,

.github/workflows/build.yml

@@ -48,11 +48,6 @@ jobs:
         echo "tests: false" >> cabal.project.local
         echo "benchmarks: false" >> cabal.project.local
 
-    - name: Disable -dynamic
-      run: |
-        echo "package haskell-language-server" >> cabal.project.local
-        echo "  flags: -dynamic" >> cabal.project.local
-
     - uses: ./.github/actions/setup-build
       with:
         ghc: ${{ matrix.ghc }}

ChangeLog.md

@@ -1,5 +1,37 @@
 # Changelog for haskell-language-server
 
+## 1.6.1.1 (*only hackage release*)
+
+- Release to update haskell-language-server.cabal in hackage, setting the build for the executable component as dynamically linked
+  - The motivation is build by default a hls executable which works for Template Haskell
+  - This doesn't need a full release cause it does not affect release executables which continue being fully static
+
+### Pull requests merged for 1.6.1.1
+
+- Prepare 1.6.1.1 (only hackage release)
+([#2681](https://github.com/haskell/haskell-language-server/pull/2681)) by @jneira
+- Add the -dynamic flag and update build instructions
+([#2668](https://github.com/haskell/haskell-language-server/pull/2668)) by @pepeiborra
+
+## 1.6.1.0
+
+This is a bug fix release to restore a fully statically linked haskell-language-server-wrapper executable.
+
+- It has been reported [here](https://github.com/haskell/haskell-language-server/issues/2650)
+  - Thanks all reporters for the fast feedback
+- The bug has been traced [here](https://github.com/haskell/haskell-language-server/pull/2615#discussion_r795059782)
+- And the fix is in [this pr](https://github.com/haskell/haskell-language-server/pull/2647)
+
+### Pull requests merged for 1.6.1.0
+
+- Post 1.6.0.0 fixes and prepare 1.6.1.0 bug fix release
+([#2647](https://github.com/haskell/haskell-language-server/pull/2647)) by @jneira
+- Move hackage back to flake.nix
+([#2652](https://github.com/haskell/haskell-language-server/pull/2652)) by @guibou
+- Wingman: Fix #1879
+([#2644](https://github.com/haskell/haskell-language-server/pull/2644)) by @MorrowM
+
+
 ## 1.6.0.0
 
 Time for a new and exciting hls release:

docs/troubleshooting.md

@@ -160,27 +160,27 @@ The server log will show which cradle is being chosen.
 
 Using an explicit `hie.yaml` to configure the cradle can resolve the problem, see the [configuration page](./configuration.md#configuring-your-project-build).
 
-### Static binaries and template haskell support
+### Static binaries
 
-Static binaries use the GHC linker for dynamically loading dependencies when typechecking TH code, and this can run into issues when loading shared objects linked against mismatching system libraries, or into GHC linker  bugs (mainly the Mach linker used in Mac OS, but also potentially the ELF linker).
+Static binaries use the GHC linker for dynamically loading dependencies when typechecking Template Haskell code, and this can run into issues when loading shared objects linked against mismatching system libraries, or into GHC linker  bugs (mainly the Mach linker used in Mac OS, but also potentially the ELF linker).
 Dynamically linked binaries (including`ghci`) use the system linker instead of the GHC linker and avoid both issues.
 
 The easiest way to obtain a dynamically linked HLS binary is to build HLS locally. With `cabal` this can be done as follows:
 
 ```bash
-cabal update && cabal install pkg:haskell-language-server"
+cabal update && cabal install pkg:haskell-language-server
 ```
 
 If you are compiling with a ghc version with a specific `cabal-ghc${ghcVersion}.project` in the repo you will have to use it. For example for ghc-9.0.x:
 
 ```bash
-cabal update && cabal install pkg:haskell-language-server --project-file=cabal-ghc90.project"
+cabal update && cabal install pkg:haskell-language-server --project-file=cabal-ghc90.project
 ```
 
 Or with `stack`:
 
 ```bash
-stack install haskell-language-server --stack-yaml=stack-${ghcVersion}.yaml"
+stack install haskell-language-server --stack-yaml=stack-${ghcVersion}.yaml
 ```
 
 You also can leverage `ghcup compile hls`:

haskell-language-server.cabal

@@ -1,7 +1,7 @@
 cabal-version:      2.4
 category:           Development
 name:               haskell-language-server
-version:            1.6.1.0
+version:            1.6.1.1
 synopsis:           LSP server for GHC
 description:
   Please see the README on GitHub at <https://github.com/haskell/haskell-language-server#readme>