Adding Purescript

Adding Purescript

[John Soo]

Hi guix,

I have packaged PureScript in a channel and I would like to merge it  Some of its dependencies are from hackage and are much newer than those in the stackage snapshot we use.  So my question is where should the dependencies belong?

Thanks!

John

Stackage LTS 14 (was: Adding Purescript)

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> I have packaged PureScript in a channel and I would like to merge it

Cool!

> Some of its dependencies are from hackage and are much newer than
> those in the stackage snapshot we use.  So my question is where should
> the dependencies belong?

Maybe we should just bite the bullet and upgrade to LTS 14.  Thoughts?
Would that cover most of the PureScripts dependencies?

I did the bulk of the transition to the current version and it was not
so bad.  We could re-purpose the wip-haskell-updates branch that is
already setup on the build farm (everything on that branch has already
landed in master).  That way, it would be a lot easier to work
collaboratively and incrementally.

One of the things I want to do this time is to do the upgrade in one
mega commit.  I’m pretty sure that some of the commits last time had
inconsistent package sets, which is not ideal.  I’m not sure how to
avoid that upgrading one package at a time.  Hence, my rough plan is to
start by setting GHC 8.6 as the compiler for the build system, and then
run the refresh script with Stackage LTS 14.  After that, I will push
the results to wip-haskell-updates and see how it goes.

Ricardo, what do you think?  Are we okay to take over
wip-haskell-updates?  Does a mega commit make sense or do you think
that’s a bad idea?

This is something that I could get started later this week.  With
respect to PureScript, it might be easier than adding a bunch of more
recent Haskell packages, but that depends on how many packages it is.
Either way, this is something that should be done.  It is pretty safe to
try, too, since if it looks like it is going to be really hairy, we can
always bail and add PureScript with separate dependencies in the
interim.


-- Tim

Re: Stackage LTS 14 (was: Adding Purescript)

[Ricardo Wurmus]

Hi Timothy,

> One of the things I want to do this time is to do the upgrade in one
> mega commit.  I’m pretty sure that some of the commits last time had
> inconsistent package sets, which is not ideal.  I’m not sure how to
> avoid that upgrading one package at a time.  Hence, my rough plan is to
> start by setting GHC 8.6 as the compiler for the build system, and then
> run the refresh script with Stackage LTS 14.  After that, I will push
> the results to wip-haskell-updates and see how it goes.
>
> Ricardo, what do you think?  Are we okay to take over
> wip-haskell-updates?  Does a mega commit make sense or do you think
> that’s a bad idea?

Yes, you can take over wip-haskell-updates.

A single big commit is not a good idea, but you don’t really need it as
you’d merge the branch in one go, so Cuirass would not end up evaluating
any of the intermediate commits anyway.  It’s still good to have smaller
commits to better undo individual changes and more easily understand
related changes.

--
Ricardo

Re: Stackage LTS 14 (was: Adding Purescript)

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Timothy,
>
>> One of the things I want to do this time is to do the upgrade in one
>> mega commit.  I’m pretty sure that some of the commits last time had
>> inconsistent package sets, which is not ideal.  I’m not sure how to
>> avoid that upgrading one package at a time.  Hence, my rough plan is to
>> start by setting GHC 8.6 as the compiler for the build system, and then
>> run the refresh script with Stackage LTS 14.  After that, I will push
>> the results to wip-haskell-updates and see how it goes.
>>
>> Ricardo, what do you think?  Are we okay to take over
>> wip-haskell-updates?  Does a mega commit make sense or do you think
>> that’s a bad idea?
>
> Yes, you can take over wip-haskell-updates.
>
> A single big commit is not a good idea, but you don’t really need it as
> you’d merge the branch in one go, so Cuirass would not end up evaluating
> any of the intermediate commits anyway.  It’s still good to have smaller
> commits to better undo individual changes and more easily understand
> related changes.

AIUI individual updates cannot really be un-done, because that would
break the entire dependency chain.

I think it's OK to "squash" instances like this, both to clarify that
the changes are in fact related, and to make bisecting less painful.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Stackage LTS 14

[Timothy Sample]

Hello,

Marius Bakke <mbakke@fastmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> Ricardo, what do you think?  Are we okay to take over
>>> wip-haskell-updates?  Does a mega commit make sense or do you think
>>> that’s a bad idea?
>>
>> Yes, you can take over wip-haskell-updates.

Great!  I’ve pushed a new branch with updated Haskell packages.  It’s a
little messy yet, but I want the build farm to help me find build
problems before cleaning up too much.  I updated all the packages using
“guix refresh”, and then built and fixed enough to build “ghc-aeson”.
There were a lot of problems, some of which I fixed with “squash!”
commits that I can squash later.  (I’m hoping that using “squash!”
commits to fix the “guix refresh” commits will make collaboration
easier, but maybe it will just give me a headache later when I have to
squash everything – we’ll see!)

>> A single big commit is not a good idea, but you don’t really need it as
>> you’d merge the branch in one go, so Cuirass would not end up evaluating
>> any of the intermediate commits anyway.  It’s still good to have smaller
>> commits to better undo individual changes and more easily understand
>> related changes.
>
> AIUI individual updates cannot really be un-done, because that would
> break the entire dependency chain.
>
> I think it's OK to "squash" instances like this, both to clarify that
> the changes are in fact related, and to make bisecting less painful.

That’s correct, Marius.  Jumping in anywhere along this chain of commits
would yield broken Haskell packages.  That’s what I was hoping to avoid
with a big, atomic commit.  I get that big commits like that are really
hard to audit, though.  Right now, I’m doing it with small commits, but
it is easy enough to go from one style to the other before we merge.

I suppose the core-updates workflow is essentially small commits.  A big
change like bumping GCC happens, and then packages that break as result
of that change get fixed in later commits.  Maybe we should keep that
style for consistency.

I’ll leave it to you maintainers to make the final call.  ;)


-- Tim

Re: Stackage LTS 14

[Timothy Sample]

Hi all,

Timothy Sample <samplet@ngyro.com> writes:

>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Yes, you can take over wip-haskell-updates.
>
> Great!  I’ve pushed a new branch with updated Haskell packages.  It’s a
> little messy yet, but I want the build farm to help me find build
> problems before cleaning up too much.  I updated all the packages using
> “guix refresh”, and then built and fixed enough to build “ghc-aeson”.
> There were a lot of problems, some of which I fixed with “squash!”
> commits that I can squash later.  (I’m hoping that using “squash!”
> commits to fix the “guix refresh” commits will make collaboration
> easier, but maybe it will just give me a headache later when I have to
> squash everything – we’ll see!)

The build farm seems to have stalled, but I have not!

I have “xmonad”, “darcs”, “ghc-pandoc”, and “git-annex” all building
(locally) on top of GHC 8.6, which means that we’re nearly there.
Unfortunately, the mess is getting to be too much, so I plan to clean it
up tomorrow and then push a new, cleaner version of
“wip-haskell-updates”.  There are few minor things to discuss, which I
will gather as I tidy up the commits.

After that, I’m hoping that some others will help with a few of the
final problems (especially the R packages, about which I know little).
I have not checked on Agda or Idris yet either.  In any case, you might
as well wait until I do the cleaning.

Stay tuned!


-- Tim

Re: Stackage LTS 14

[Timothy Sample]

Hello,

Timothy Sample <samplet@ngyro.com> writes:

> I have “xmonad”, “darcs”, “ghc-pandoc”, and “git-annex” all building
> (locally) on top of GHC 8.6, which means that we’re nearly there.
> Unfortunately, the mess is getting to be too much, so I plan to clean it
> up tomorrow and then push a new, cleaner version of
> “wip-haskell-updates”.  There are few minor things to discuss, which I
> will gather as I tidy up the commits.

I pushed a cleaned up version, two fixes for i686, and then a few more
fixes, and things are starting to look good.  At the bottom of this
message is the current list of failures for x86_64 (i686 is a little
worse, but not by much).

However, I have a really weird problem.  When I build “git-annex”, I
build

    /gnu/store/5i2x293qn45dwg2rv6vy45s0r9jbnv8l-git-annex-7.20191024.drv

and it succeeds.  On the build farm, it’s

    /gnu/store/fj5kyjkblxzcxbs6di1kd29j6fpsjvgk-git-annex-7.20191024.drv

and it fails.  I’ve tried “clean-go” and indeed “git clean” followed by
bootstrapping and configuring again.  This does not help.  I took the
log from the build farm and diffed it with my local build log, and all
the interesting parts (e.g., the store paths of everything that goes in
“GHC_PACKAGE_PATH”) match exactly.

Any ideas?  It would be helpful if someone tried on another machine and
check if it matches the build farm or not.  It’s probably something
silly, but I can’t figure it out.

Here’s the list of failing packages.  The first bunch I’ve listed as
“help wanted” – I’ll try and look at them, but some of them are pretty
unfamiliar to me, so it may take some time.  Other people could probably
do a better job!

Help wanted:

    agda-2.5.4.2.x86_64-linux
    agda-ial-1.5.0.x86_64-linux
    beast-0.10.0.x86_64-linux
    cedille-1.1.1.x86_64-linux
    elm-compiler-0.19.0.x86_64-linux
    hedgewars-0.9.25.x86_64-linux
    idris-1.3.2.x86_64-linux
    idris-bifunctors-0.1-1.53d06a6.x86_64-linux
    idris-lens-0.1-1.26f0120.x86_64-linux
    idris-lightyear-0.1-1.6d65ad1.x86_64-linux
    idris-wl-pprint-0.1-1.1d365fc.x86_64-linux
    ngless-0.9.1.x86_64-linux
    rapicorn-16.0.0.x86_64-linux
    xmobar-0.28.x86_64-linux

“Works for me”:

    git-annex-7.20191024.x86_64-linux

Could be deleted:

    ghc-haddock-api-2.19.0.1.x86_64-linux – needed for haddock
    ghc-haddock-2.19.0.1.x86_64-linux – haddock is already provided by GHC
    corrode-0.0.1-b6699fb.x86_64-linux – no updates in years

Finally, there are some packages that have unneeded other versions now.
For instance, we used to have newer versions (than LTS 12) of some
packages for Idris.  Those packages could probably be deleted, but I
need to track them all down.


-- Tim

Re: Stackage LTS 14

[Timothy Sample]

Hi again,

Timothy Sample <samplet@ngyro.com> writes:

> However, I have a really weird problem.  When I build “git-annex”, I
> build
>
>     /gnu/store/5i2x293qn45dwg2rv6vy45s0r9jbnv8l-git-annex-7.20191024.drv
>
> and it succeeds.  On the build farm, it’s
>
>     /gnu/store/fj5kyjkblxzcxbs6di1kd29j6fpsjvgk-git-annex-7.20191024.drv
>
> and it fails.  I’ve tried “clean-go” and indeed “git clean” followed by
> bootstrapping and configuring again.  This does not help.  I took the
> log from the build farm and diffed it with my local build log, and all
> the interesting parts (e.g., the store paths of everything that goes in
> “GHC_PACKAGE_PATH”) match exactly.
>
> Any ideas?  It would be helpful if someone tried on another machine and
> check if it matches the build farm or not.  It’s probably something
> silly, but I can’t figure it out.

I just built this on another machine, and I get the same results as my
first machine.  Maybe something strange has happened on the build
farm....

> Here’s the list of failing packages.  [...]

Here’s an updated list.

Help wanted:

    ngless-0.9.1.x86_64-linux
    xmobar-0.28.x86_64-linux

These two look like they just need to be updated.  They both seem to
need a few new dependencies, though.  For instance, “ngless” needs four
new Haskell packages for the most recent version.  It should be
straight-forward.  There are a lot of options when building “xmobar”,
which is why I’ve been avoiding it.  Depending on the options, it needs
different dependencies.  If we have any “xmobar” users, I would love
your input for the update!  Otherwise, I will do my best to make
reasonable (if rather uninformed) choices.

Broken before GHC update (i.e., should not block merge):

    beast-0.10.0.x86_64-linux
    hedgewars-0.9.25.x86_64-linux
    rapicorn-16.0.0.x86_64-linux

“Works for me”:

    git-annex-7.20191024.x86_64-linux

Could be deleted:

    ghc-haddock-api-2.19.0.1.x86_64-linux – needed for haddock
    ghc-haddock-2.19.0.1.x86_64-linux – haddock is already provided by GHC
    corrode-0.0.1-b6699fb.x86_64-linux – no updates in years

> Finally, there are some packages that have unneeded other versions now.
> For instance, we used to have newer versions (than LTS 12) of some
> packages for Idris.  Those packages could probably be deleted, but I
> need to track them all down.

This still needs doing, but I’m pretty sure it’s just “ghc-megaparsec-7”
and “ghc-network-2.8”.


-- Tim

Re: Stackage LTS 14

[John Soo]

Hi Tim,

Thanks for putting in the work. I use xmobar with a few extra options: dbus, alsa and maybe one more. I can’t remember. I can try submitting a patch for it this week.

My only question is how many options should we enable? We can try all.

Re: Stackage LTS 14

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> Thanks for putting in the work. I use xmobar with a few extra options:
> dbus, alsa and maybe one more. I can’t remember. I can try submitting
> a patch for it this week.

Hooray!  If I fix “ngless” this will be pretty much ready to merge.
Then (pause while a short fanfare plays) PureScript!

> My only question is how many options should we enable? We can try all.

As far as I’m concerned, the only limit is how many you are willing to
get working and/or want to use.  :)


-- Tim

Re: Stackage LTS 14

[John Soo]

[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]

Hi Tim,

Xmobar builds properly with all the extensions but I haven't really given
it a spin.  I did have to add a few more packages, but I think they are
reasonable.

I think the update to ghc after 8.4 will fix a segfault that i have been
experiencing :).

Here are my patches, is this the place to put them?

- John

[-- Attachment #1.2: Type: text/html, Size: 517 bytes --]

[-- Attachment #2: 0002-gnu-Add-ghc-timezone-series.patch --]
[-- Type: text/x-patch, Size: 1532 bytes --]

From 0000579f1152545ca873c2a38a9bd5ef5c48f394 Mon Sep 17 00:00:00 2001
From: John Soo <jsoo1@asu.edu>
Date: Thu, 14 Nov 2019 01:10:01 -0800
Subject: [PATCH 2/5] gnu: Add ghc-timezone-series.

* gnu/packages/haskell-xyz.scm (ghc-timezone-series): Add it.
---
 gnu/packages/haskell-xyz.scm | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index 3f61800d00..c80d905c86 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -11102,6 +11102,29 @@ timer manager.")
 used CPU time of monadic computation with an IO base.")
     (license license:bsd-3)))
 
+(define-public ghc-timezone-series
+  (package
+   (name "ghc-timezone-series")
+   (version "0.1.9")
+   (source
+    (origin
+     (method url-fetch)
+     (uri
+      (string-append
+       "mirror://hackage/package/timezone-series/timezone-series-"
+       version ".tar.gz"))
+     (sha256
+      (base32
+       "1blwgnyzqn917rgqkl4dncv9whv3xmk0lav040qq0214vksmvlz5"))))
+   (build-system haskell-build-system)
+   (home-page "http://projects.haskell.org/time-ng/")
+   (synopsis "Enhanced timezone handling for Time")
+   (description
+    "This package endows @code{Data.Time}, from the time package, with several
+data types and functions for enhanced processing of timezones. For one way to
+create timezone series, see the ghc-timezone-olson package.")
+   (license license:bsd-3)))
+
 (define-public ghc-tldr
   (package
     (name "ghc-tldr")
-- 
2.24.0


[-- Attachment #3: 0004-gnu-Add-ghc-dbus.patch --]
[-- Type: text/x-patch, Size: 2726 bytes --]

From abb2062d2df2727584570091fd72331577dd3781 Mon Sep 17 00:00:00 2001
From: John Soo <jsoo1@asu.edu>
Date: Thu, 14 Nov 2019 01:25:58 -0800
Subject: [PATCH 4/5] gnu: Add ghc-dbus.

* gnu/packages/haskell-xyz.scm (ghc-dbus): Add it.
---
 gnu/packages/haskell-xyz.scm | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index 28c2ffd183..5b8b785a81 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -2665,6 +2665,57 @@ It includes hashing functions for all basic Haskell98 types.")
      "This module provides set and multiset operations on ordered lists.")
     (license license:bsd-3)))
 
+(define-public ghc-dbus
+  (package
+    (name "ghc-dbus")
+    (version "1.2.7")
+    (source
+      (origin
+        (method url-fetch)
+        (uri
+         (string-append
+          "mirror://hackage/package/dbus/dbus-"
+          version ".tar.gz"))
+        (sha256
+          (base32
+            "0ypkjlw9fn65g7p28kb3p82glk7qs7p7vyffccw7qxa3z57s12w5"))))
+    (build-system haskell-build-system)
+    (inputs
+      `(("ghc-cereal" ,ghc-cereal)
+        ("ghc-conduit" ,ghc-conduit)
+        ("ghc-exceptions" ,ghc-exceptions)
+        ("ghc-lens" ,ghc-lens)
+        ("ghc-network" ,ghc-network)
+        ("ghc-random" ,ghc-random)
+        ("ghc-split" ,ghc-split)
+        ("ghc-th-lift" ,ghc-th-lift)
+        ("ghc-vector" ,ghc-vector)
+        ("ghc-xml-conduit" ,ghc-xml-conduit)
+        ("ghc-xml-types" ,ghc-xml-types)))
+    (native-inputs
+      `(("ghc-extra" ,ghc-extra)
+        ("ghc-quickcheck" ,ghc-quickcheck)
+        ("ghc-resourcet" ,ghc-resourcet)
+        ("ghc-tasty" ,ghc-tasty)
+        ("ghc-tasty-hunit" ,ghc-tasty-hunit)
+        ("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)))
+    ;; FIXME - Some tests try to talk to network.
+    (arguments `(#:tests? #f))
+    (home-page
+      "https://github.com/rblaze/haskell-dbus#readme")
+    (synopsis
+      "A client library for the D-Bus IPC system")
+    (description
+      "D-Bus is a simple, message-based protocol for inter-process
+communication, which allows applications to interact with other parts
+of the machine and the user's session using remote procedure
+calls.  D-Bus is a essential part of the modern Linux desktop, where
+it replaces earlier protocols such as CORBA and DCOP. This library
+is an implementation of the D-Bus protocol in Haskell. It can be used
+to add D-Bus support to Haskell applications, without the awkward
+interfaces common to foreign bindings.")
+    (license license:asl2.0)))
+
 (define-public ghc-deepseq-generics
   (package
     (name "ghc-deepseq-generics")
-- 
2.24.0


[-- Attachment #4: 0001-gnu-Add-ghc-alsa-mixer.patch --]
[-- Type: text/x-patch, Size: 1470 bytes --]

From 436b2f7079fe12b71dace446dff0cc086f6b74a6 Mon Sep 17 00:00:00 2001
From: John Soo <jsoo1@asu.edu>
Date: Wed, 13 Nov 2019 23:59:23 -0800
Subject: [PATCH 1/5] gnu: Add ghc-alsa-mixer.

* gnu/packages/haskell-xyz.scm (ghc-alsa-mixer): Add it.
---
 gnu/packages/haskell-xyz.scm | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index e952ab46c0..3f61800d00 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -304,6 +304,29 @@ tool lex or flex for C/C++.")
 needed by both alsa-seq and alsa-pcm.")
     (license license:bsd-3)))
 
+(define-public ghc-alsa-mixer
+  (package
+   (name "ghc-alsa-mixer")
+   (version "0.3.0")
+   (source
+    (origin
+     (method url-fetch)
+     (uri
+      (string-append
+       "mirror://hackage/package/alsa-mixer/alsa-mixer-"
+       version ".tar.gz"))
+     (sha256
+      (base32
+       "00ny2p3276jilidjs44npc8zmbhynz3f2lpmlwwl6swwx5yijsnb"))))
+   (build-system haskell-build-system)
+   (inputs `(("ghc-alsa-core" ,ghc-alsa-core)))
+   (native-inputs `(("ghc-c2hs" ,ghc-c2hs)))
+   (home-page "https://github.com/ttuegel/alsa-mixer")
+   (synopsis "Bindings to the ALSA simple mixer API")
+   (description
+    "This package provides bindings to the ALSA simple mixer API.")
+   (license license:bsd-3)))
+
 (define-public ghc-annotated-wl-pprint
   (package
     (name "ghc-annotated-wl-pprint")
-- 
2.24.0


[-- Attachment #5: 0003-gnu-Add-ghc-timezone-olson.patch --]
[-- Type: text/x-patch, Size: 1885 bytes --]

From bee82f6e2d73f5381c96afe3a01fc012bdffb969 Mon Sep 17 00:00:00 2001
From: John Soo <jsoo1@asu.edu>
Date: Thu, 14 Nov 2019 01:10:31 -0800
Subject: [PATCH 3/5] gnu: Add ghc-timezone-olson

* gnu/packages/haskell-xyz.scm (ghc-timezone-olson): Add it.
---
 gnu/packages/haskell-xyz.scm | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index c80d905c86..28c2ffd183 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -11125,6 +11125,35 @@ data types and functions for enhanced processing of timezones. For one way to
 create timezone series, see the ghc-timezone-olson package.")
    (license license:bsd-3)))
 
+(define-public ghc-timezone-olson
+  (package
+   (name "ghc-timezone-olson")
+   (version "0.1.9")
+   (source
+    (origin
+     (method url-fetch)
+     (uri
+      (string-append
+       "mirror://hackage/package/timezone-olson/timezone-olson-"
+       version ".tar.gz"))
+     (sha256
+      (base32
+       "05abywx1nrcaz0nqzfy4zw62bc5qd7pdfnjvv4drxkwv084ha8rj"))))
+   (build-system haskell-build-system)
+   (inputs
+    `(("ghc-timezone-series" ,ghc-timezone-series)
+      ("ghc-extensible-exceptions" ,ghc-extensible-exceptions)))
+   (home-page "http://projects.haskell.org/time-ng/")
+   (synopsis "Parser and renderer for binary Olson timezone files")
+   (description
+    "A parser and renderer for binary Olson timezone files whose format is
+specified by the tzfile(5) man page on Unix-like systems. For more information
+about this format, see
+http://www.iana.org/time-zones/repository/tz-link.html. Functions are provided
+for converting the parsed data into @code{TimeZoneSeries} objects from the
+timezone-series package.")
+   (license license:bsd-3)))
+
 (define-public ghc-tldr
   (package
     (name "ghc-tldr")
-- 
2.24.0


[-- Attachment #6: 0005-gnu-Update-xmobar-to-0.31.patch --]
[-- Type: text/x-patch, Size: 3207 bytes --]

From a873fdb05d85704967c24fff125c79deea17daa5 Mon Sep 17 00:00:00 2001
From: John Soo <jsoo1@asu.edu>
Date: Thu, 14 Nov 2019 01:32:38 -0800
Subject: [PATCH 5/5] gnu: Update xmobar to 0.31.

* gnu/packages/wm.scm (xmobar): Update to 0.31.
---
 gnu/packages/wm.scm | 35 +++++++++++++++++++++++------------
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index e793d89bfa..4d248fbcdd 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -24,6 +24,7 @@
 ;;; Copyright © 2019 Kyle Andrews <kyle.c.andrews@gmail.com>
 ;;; Copyright © 2019 Ingo Ruhnke <grumbel@gmail.com>
 ;;; Copyright © 2019 Tanguy Le Carrour <tanguy@bioneland.org>
+;;; Copyright © 2019 John Soo <jsoo1@asu.edu>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -649,36 +650,46 @@ tiled on several screens.")
 (define-public xmobar
   (package
     (name "xmobar")
-    (version "0.28")
+    (version "0.31")
     (source (origin
               (method url-fetch)
               (uri (string-append "mirror://hackage/package/xmobar/"
                                   "xmobar-" version ".tar.gz"))
               (sha256
                (base32
-                "1xh87asg8y35srvp7d3gyyy4bkxsw122liihxgzgm8pqv2z3h4zd"))))
+                "1sbxva4zaj060bigmxivpn4zlz0q1qbq2np8gljdqkjvysjzpbka"))))
     (build-system haskell-build-system)
     (native-inputs
      `(("ghc-hspec" ,ghc-hspec)
        ("hspec-discover" ,hspec-discover)))
     (inputs
-     `(("ghc-hinotify" ,ghc-hinotify)
+     `(("ghc-alsa-core" ,ghc-alsa-core)
+       ("ghc-alsa-mixer" ,ghc-alsa-mixer)
+       ("ghc-dbus" ,ghc-dbus)
+       ("ghc-libmpd" ,ghc-libmpd)
+       ("ghc-hinotify" ,ghc-hinotify)
        ("ghc-http" ,ghc-http)
+       ("ghc-http-conduit" ,ghc-http-conduit)
+       ("ghc-http-types" ,ghc-http-types)
        ("ghc-iwlib" ,ghc-iwlib)
+       ("ghc-libmpd" ,ghc-libmpd)
+       ("ghc-old-locale" ,ghc-old-locale)
        ("ghc-parsec-numbers" ,ghc-parsec-numbers)
        ("ghc-regex-compat" ,ghc-regex-compat)
+       ("ghc-temporary" ,ghc-temporary)
+       ("ghc-timezone-olson" ,ghc-timezone-olson)
+       ("ghc-x11" ,ghc-x11)
        ("ghc-x11-xft" ,ghc-x11-xft)
        ("libxpm" ,libxpm)))
     (arguments
-     `(#:configure-flags
-       (list (string-append "--flags="
-                            (string-join (list "with_inotify"
-                                               "with_iwlib"
-                                               "with_utf8"
-                                               "with_weather"
-                                               "with_xft"
-                                               "with_xpm")
-                                         " ")))))
+     `(#:configure-flags (list "--flags=all_extensions")
+       #:phases
+       (modify-phases %standard-phases
+         (add-before 'build 'patch-test-shebang
+           (lambda* (#:key inputs #:allow-other-keys)
+             (substitute* "test/Xmobar/Plugins/Monitors/AlsaSpec.hs"
+               (("/bin/bash") (which "bash")))
+             #t)))))
     (home-page "http://xmobar.org")
     (synopsis "Minimalistic text based status bar")
     (description
-- 
2.24.0

Re: Stackage LTS 14

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> Xmobar builds properly with all the extensions but I haven't really given it a spin.  I did have to
> add a few more packages, but I think they are reasonable.

This is fantastic!  Thanks so much for your help.

> I think the update to ghc after 8.4 will fix a segfault that i have been experiencing :).

\o/

> Here are my patches, is this the place to put them?

This is perfect.  I have “ngless” building, too, so we are well on our
way.  I will incorporate these patches and start working on the final
steps of getting these changes into master.

Thanks again!


-- Tim

Re: Stackage LTS 14

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi John,
>
> John Soo <jsoo1@asu.edu> writes:
>
>> Xmobar builds properly with all the extensions but I haven't really given it a spin.  I did have to
>> add a few more packages, but I think they are reasonable.
>
> This is fantastic!  Thanks so much for your help.
>
>> I think the update to ghc after 8.4 will fix a segfault that i have been experiencing :).
>
> \o/
>
>> Here are my patches, is this the place to put them?
>
> This is perfect.  I have “ngless” building, too, so we are well on our
> way.  I will incorporate these patches and start working on the final
> steps of getting these changes into master.

This is amazing work, thank you both.  :-)

I've read some of the changes and they LGTM.  If Cuirass is happy, I
think you can go ahead and merge the branch.  \o/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Stackage LTS 14

[John Soo]

Hey everyone,

When we bump to Stackage 14 can issue 36653 be closed?

- John

Re: Stackage LTS 14

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> When we bump to Stackage 14 can issue 36653 be closed?

I think these changes should still be merged (with review and fixes).
Eventually Stackage LTS 15 will come out while we’re still on LTS 14.
At that point, we will have the same issue with the importer and linter
giving us information about LTS 15 when we only want LTS 14.


-- Tim

[bug#36653] Stackage LTS 14

[Timothy Sample]

Hi John,

John Soo <jsoo1@asu.edu> writes:

> When we bump to Stackage 14 can issue 36653 be closed?

I think these changes should still be merged (with review and fixes).
Eventually Stackage LTS 15 will come out while we’re still on LTS 14.
At that point, we will have the same issue with the importer and linter
giving us information about LTS 15 when we only want LTS 14.


-- Tim

Re: Stackage LTS 14

[John Soo]

Ah, ok makes sense!

Re: Stackage LTS 14

[Timothy Sample]

Hi,

Marius Bakke <mbakke@fastmail.com> writes:

> I've read some of the changes and they LGTM.  If Cuirass is happy, I
> think you can go ahead and merge the branch.  \o/

I just put everything together and rebased it all on master, fixing
several typos as I did so.  :)  It seems that “ghc@8.6.5” has changed a
few days ago on master, so everything will have to be rebuilt.  Given
that, I recreated the wip-haskell-updates branch so that the build farm
can get to it.  Once it’s done, I’ll push to master.

The only thing I wanted to mention was that I sneaked a newer version of
“libyaml” (0.2.1) in along side the old version (0.1.7).  The Haskell
bindings required the newer version.  It’s possible that we could just
update the old version, but it has quite a few dependencies, so I didn’t
want to get tangled up in it.  I’m bringing it up because it’s the only
non-Haskell change in the commits, and I don’t want anyone to be
surprised.  :)


-- Tim

Re: Stackage LTS 14

[Timothy Sample]

Hi again,

Timothy Sample <samplet@ngyro.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> I've read some of the changes and they LGTM.  If Cuirass is happy, I
>> think you can go ahead and merge the branch.  \o/
>
> I just put everything together and rebased it all on master, fixing
> several typos as I did so.  :)  It seems that “ghc@8.6.5” has changed a
> few days ago on master, so everything will have to be rebuilt.  Given
> that, I recreated the wip-haskell-updates branch so that the build farm
> can get to it.  Once it’s done, I’ll push to master.

Cuirass is not happy.  :(

Three packages are failing (and they have lots of dependencies):
“ghc-fsnotify”, “ghc-foundataion”, and “ghc-hex”.  They all build
locally for me (everything builds locally for me).  According to the
logs, the first two fail during tests.  There could be very sparse
intermittent failures there, because one is testing file system events
and the other uses property tests.  Cuirass has an empty log for
“ghc-hex”.  Is there any way to make Cuirass try again?  Should I
disable the tests for the first two?

ghc-foundation: https://ci.guix.gnu.org/build/1936994/details
ghc-fsnotify: https://ci.guix.gnu.org/build/1936990/details
ghc-hex: https://ci.guix.gnu.org/build/1936990/details

I’m not sure how to proceed here.


-- Tim

Re: Stackage LTS 14

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> I've read some of the changes and they LGTM.  If Cuirass is happy, I
>> think you can go ahead and merge the branch.  \o/
>
> I just put everything together and rebased it all on master, fixing
> several typos as I did so.  :)  It seems that “ghc@8.6.5” has changed a
> few days ago on master, so everything will have to be rebuilt.  Given
> that, I recreated the wip-haskell-updates branch so that the build farm
> can get to it.  Once it’s done, I’ll push to master.

Good catch wrt the GHC rebuild.

> The only thing I wanted to mention was that I sneaked a newer version of
> “libyaml” (0.2.1) in along side the old version (0.1.7).  The Haskell
> bindings required the newer version.  It’s possible that we could just
> update the old version, but it has quite a few dependencies, so I didn’t
> want to get tangled up in it.  I’m bringing it up because it’s the only
> non-Haskell change in the commits, and I don’t want anyone to be
> surprised.  :)

I appreciate the heads-up.  Thanks again for taking on this task.  The
branch LGTM.

I've restarted the builds that you mentioned in another message.  How is
the weather looking, do you think it's ready to merge?  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Stackage LTS 14

[Timothy Sample]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> I appreciate the heads-up.  Thanks again for taking on this task.  The
> branch LGTM.
>
> I've restarted the builds that you mentioned in another message.  How is
> the weather looking, do you think it's ready to merge?  :-)

There are a few remaining issues, but...

I decided to push anyway!  :)

As far as I can tell, the remaining issues also affect master, so there
is no harm pushing.  Also, I have been continually building everything
locally, so I know that all of the packages can be built at least
sometimes.  The major problems are “git-annex”, a few R packages, and
the dependencies of “ghc-fsnotify”, which include “idris”.  The only one
that has been built on master but not on wip-haskell-updates is “idris”
(I can’t tell if restarting the build helped – Cuirass does not show
anything new).  It looks like the set of failing R packages is slightly
different between master and wip-haskell-updates, but I haven’t
investigated too deeply.  I did see some local failures with R packages
when building with a larger “--max-jobs”.  They seemed to go away when I
retried with a lower “--max-jobs”.  They also seemed to consume a lot of
RAM.

It’s done!  \o/  Sorry to anyone (esp. Idris users) who is stuck
building a few packages locally.  Thanks to everyone who helped out and
provided input (with special mention to Robert who packaged GHC 8.6.5 in
the first place and John who spurred me to get started by asking about
PureScript dependencies and who fixed up “xmobar”).  :)


-- Tim

Re: Stackage LTS 14

[John Soo]

Thanks Tim, Marius!

Good work! I am really happy about xmobar, it’s so much more stable now. I’ll take a look at idris next time I get the chance. 

- John

Re: Stackage LTS 14

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

I can confirm that git-annex built locally so no complaints there.

Great job!


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Stackage LTS 14

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

Timothy Sample <samplet@ngyro.com> writes:

> Hi Marius,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> I appreciate the heads-up.  Thanks again for taking on this task.  The
>> branch LGTM.
>>
>> I've restarted the builds that you mentioned in another message.  How is
>> the weather looking, do you think it's ready to merge?  :-)
>
> There are a few remaining issues, but...
>
> I decided to push anyway!  :)

Wohoo!  \o/

The CI has build "idris" and other ghc-fsnotify dependents already.  I
tried restarting "git-annex", but the tests still failed with no
particular error message.

Any git-annex users around here who knows what the issue may be, or how
to debug it further?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]