| Message ID | Ycrl4T40hbpOuqc6@noor.fritz.box |
|---|---|
| State | Accepted |
| Headers | show |
Hi Lars, Thanks for taking a look and testing. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, December 28th, 2021 at 5:24 AM, Lars-Dominik Braun wrote: > Hi John, > > thanks for your patches. I also upgraded xmonad locally (see > attached patch), but I didn’t need the version bumps/new packages > (i.e. xmonad’s test suite builds and runs fine). Are they really > necessary? > I can confirm your patch also builds and checks fine (though didn't look at the log in much detail). Taking a quick look at the new dependency, it is for some testing but seems optional: https://github.com/xmonad/xmonad/commit/031bbd62306e592ddd0768d4e5b1105bf5e81032 So maybe that's why it builds/checks fine. Since we can easily add the needed packages, I would err on including it, what do you think? I removed/added dependencies based on a fresh guix import and looking at the Hackage info for xmonad. I think some of the dependencies that were removed were due to older versions (or to support older GHC?) or I guess libraries that aren't needed anymore. > > Note that this new version has breaking configuration changes, detailed in their announcement: https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html Is that worth a news entry for guix pull? It has been a long time since xmonad released a new version, for those that stay on the stable release. > > I was also hesitant to push the new version for this reason. Additionally > xmonad is part of Stackage, which we use where possible. How about adding > a xmonad-next package instead and make the switch when Stackage includes > the new version? > We do tend to follow LTS Stackage, but I wasn't sure how something like XMonad fits since I imagine most people that use it aren't using Haskell otherwise. Also, since it has been a few years since they had a release, I thought it would be nice to have it. Anyway, an xmonad-next could make the transition easier for anyone using the previous stable release. I've been using cabal but with an update in Guix would look to make my setup more Guix-y. To summarize, I would opt for the changes in dependencies to follow upstream, and making a separate xmonad-next avoids further disruption anyway. Personally, I also wanted to submit those new packages as part of a whole lot of Haskell packages I will be submitting to get haskell-gi and taffybar in Guix. Thanks, John
commit 0b099048a1f4c8aaf9a7830e089ff2e085a7ca92
Author: Lars-Dominik Braun <lars@6xq.net>
Date: Thu Nov 18 09:30:48 2021 +0100
dirty: xmonad upgrade
diff --git a/gnu/packages/patches/xmonad-dynamic-linking.patch b/gnu/packages/patches/xmonad-dynamic-linking.patch
index 4f3386e53a..0aa91954ee 100644
--- a/gnu/packages/patches/xmonad-dynamic-linking.patch
+++ b/gnu/packages/patches/xmonad-dynamic-linking.patch
@@ -2,15 +2,15 @@ This patch is required for xmonad to make use of shared libraries.
Without it, xmonad will not work since we do not (by default) use
statically linked Haskell libraries.
-diff -ruN xmonad-0.15-a/src/XMonad/Core.hs xmonad-0.15-b/src/XMonad/Core.hs
---- xmonad-0.15-a/src/XMonad/Core.hs 1969-12-31 19:00:00.000000000 -0500
-+++ xmonad-0.15-b/src/XMonad/Core.hs 1969-12-31 19:00:00.000000000 -0500
-@@ -681,6 +681,8 @@
- compileGHC bin dir errHandle =
- runProcess "ghc" ["--make"
- , "xmonad.hs"
-+ , "-dynamic"
-+ , "-fPIC"
- , "-i"
- , "-ilib"
- , "-fforce-recomp"
+diff -Naur xmonad-0.17.0.orig/src/XMonad/Core.hs xmonad-0.17.0/src/XMonad/Core.hs
+--- xmonad-0.17.0.orig/src/XMonad/Core.hs 2001-09-09 03:46:40.000000000 +0200
++++ xmonad-0.17.0/src/XMonad/Core.hs 2021-11-13 10:40:17.840524866 +0100
+@@ -664,6 +664,8 @@
+ where
+ ghcArgs = [ "--make"
+ , "xmonad.hs"
++ , "-dynamic"
++ , "-fPIC"
+ , "-i" -- only look in @lib@
+ , "-ilib"
+ , "-fforce-recomp"
diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index c6881154fe..d661307c4f 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -739,7 +739,7 @@ (define-public i3lock-fancy
(define-public xmonad
(package
(name "xmonad")
- (version "0.15")
+ (version "0.17.0")
(synopsis "Tiling window manager")
(source (origin
(method url-fetch)
@@ -747,7 +747,7 @@ (define-public xmonad
"xmonad-" version ".tar.gz"))
(sha256
(base32
- "0a7rh21k9y6g8fwkggxdxjns2grvvsd5hi2ls4klmqz5xvk4hyaa"))
+ "04qspdz9w6xpw1npcmx2zx0595wc68q985pv4i0hvp32zillvdqy"))
(patches (search-patches "xmonad-dynamic-linking.patch"))))
(build-system haskell-build-system)
(inputs
@@ -759,9 +759,7 @@ (define-public xmonad
ghc-utf8-string
ghc-x11))
(arguments
- `(#:cabal-revision
- ("1" "0yqh96qqphllr0zyz5j93cij5w2qvf39xxnrb52pz0qz3pywz9wd")
- #:phases
+ `(#:phases
(modify-phases %standard-phases
(add-after
'install 'install-xsession
@@ -865,18 +863,15 @@ (define-public yeganesh
(define-public ghc-xmonad-contrib
(package
(name "ghc-xmonad-contrib")
- (version "0.16")
+ (version "0.17.0")
(source
(origin
(method url-fetch)
(uri (string-append "mirror://hackage/package/xmonad-contrib/"
"xmonad-contrib-" version ".tar.gz"))
(sha256
- (base32 "1pddgkvnbww28wykncc7j0yb0lv15bk7xnnhdcbrwkxzw66w6wmd"))))
+ (base32 "11g1cyfgfvcmz35qhgi9wzxrk3br8m8b7qy3jvph4nnf6aj13wvy"))))
(build-system haskell-build-system)
- (arguments
- `(#:cabal-revision
- ("1" "0vimkby2gq6sgzxzbvz67caba609xqlv2ii2gi8a1cjrnn6ib011")))
(propagated-inputs
(list ghc-old-time
ghc-random
@@ -886,6 +881,8 @@ (define-public ghc-xmonad-contrib
ghc-x11
ghc-x11-xft
xmonad))
+ (native-inputs
+ (list ghc-quickcheck ghc-hspec hspec-discover))
(home-page "https://xmonad.org")
(synopsis "Third party extensions for xmonad")
(description
Hi John, thanks for your patches. I also upgraded xmonad locally (see attached patch), but I didn’t need the version bumps/new packages (i.e. xmonad’s test suite builds and runs fine). Are they really necessary? > Note that this new version has breaking configuration changes, detailed in their announcement: https://xmonad.org/news/2021/10/27/xmonad-0-17-0.html Is that worth a news entry for guix pull? It has been a long time since xmonad released a new version, for those that stay on the stable release. I was also hesitant to push the new version for this reason. Additionally xmonad is part of Stackage, which we use where possible. How about adding a xmonad-next package instead and make the switch when Stackage includes the new version? Cheers, Lars