Packaging elm-compiler 0.19.1
Hi,
I'm trying to upgrade to elm-compiler 0.19.1. With the attached patch,
it fails with the following error:
Configuring elm-0.19.1...
Setup.hs: Encountered missing dependencies:
time >=1.9.1
I think that time is part of GHC. I removed the version requirement for
time, but then it failed with the following error:
[ 8 of 130] Compiling File ( builder/src/File.hs,
dist/build/elm/elm-tmp/File.dyn_o )
builder/src/File.hs:49:13: error:
Not in scope: ?Time.nominalDiffTimeToSeconds?
Neither ?Data.Time.Clock? nor ?Data.Time.Clock.POSIX? exports
?nominalDiffTimeToSeconds?.
|
49 | (Time . Time.nominalDiffTimeToSeconds . Time.utcTimeToPOSIXSeconds)
| ^
How can I fix this problem?
--
Matthew Kraai
diff --git a/gnu/local.mk b/gnu/local.mk
index 2402b1e349..f74c66e3b0 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -39,6 +39,7 @@
# Copyright © 2020 Martin Becze
# Copyright © 2020 Malte Frank Gerdes
# Copyright © 2020 Vinicius Monego
+# Copyright © 2020 Matthew Kraai
#
# This file is part of GNU Guix.
#
@@ -948,7 +949,6 @@ dist_patch_DATA =
\
%D%/packages/patches/elfutils-tests-ptrace.patch \
%D%/packages/patches/elixir-path-length.patch\
%D%/packages/patches/elm-compiler-disable-reactor.patch \
- %D%/packages/patches/elm-compiler-fix-map-key.patch \
%D%/packages/patches/emacs-exec-path.patch \
%D%/packages/patches/emacs-exwm-fix-fullscreen-states.patch \
%D%/packages/patches/emacs-fix-scheme-indent-function.patch \
diff --git a/gnu/packages/elm.scm b/gnu/packages/elm.scm
index feaa9c8d5c..f1e609b65b 100644
--- a/gnu/packages/elm.scm
+++ b/gnu/packages/elm.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Robert Vollmert
+;;; Copyright © 2020 Matthew Kraai
;;;
;;; This file is part of GNU Guix.
;;;
@@ -35,7 +36,7 @@
(define-public elm-compiler
(package
(name "elm-compiler")
-(version "0.19.0")
+(version "0.19.1")
(source
(origin
(method git-fetch)
@@ -44,10 +45,9 @@
(url "https://github.com/elm/compiler/";)
(commit version)))
(sha256
-(base32 "0s93z9vr0vp5w894ghc5s34nsq09sg1msf59zfiba87sid5vgjqy"))
+(base32 "1rdg3xp3js9xadclk3cdypkscm5wahgsfmm4ldcw3xswzhw6ri8w"))
(patches
-(search-patches "elm-compiler-disable-reactor.patch"
-"elm-compiler-fix-map-key.patch"
+(search-patches "elm-compiler-disable-reactor.patch"
(build-system haskell-build-system)
(arguments
`(#:phases
@@ -71,6 +71,7 @@
("ghc-ansi-wl-pprint" ,ghc-ansi-wl-pprint)
("ghc-edit-distance" ,ghc-edit-distance)
("ghc-file-embed" ,ghc-file-embed)
+ ("ghc-filelock" ,ghc-filelock)
("ghc-http" ,ghc-http)
("ghc-http-client" ,ghc-http-client)
("ghc-http-client-tls" ,ghc-http-client-tls)
diff --git a/gnu/packages/haskell-xyz.scm b/gnu/packages/haskell-xyz.scm
index d6c50ade71..961075e7ea 100644
--- a/gnu/packages/haskell-xyz.scm
+++ b/gnu/packages/haskell-xyz.scm
@@ -28,6 +28,7 @@
;;; Copyright © 2020 Alexandru-Sergiu Marton
;;; Copyright © 2020 Carlo Holl
;;; Copyright © 2020 Christopher Lemmer Webber
+;;; Copyright © 2020 Matthew Kraai
;;;
;;; This file is part of GNU Guix.
;;;
@@ -4414,6 +4415,28 @@ the files in a directory, and turn them into
@code{(path, bytestring)} pairs
embedded in your Haskell code.")
(license license:bsd-3)))
+(define-public ghc-filelock
+ (package
+(name "ghc-filelock")
+(version "0.1.1.5")
+(source
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://hackage.haskell.org/package/filelock/filelock-";
+ version
+ ".tar.gz"))
+ (sha256
+(base32
+ "06a44i7a956d7xkk2na4090xj2a7b7a228pk4spmccs4x20ymssh"
+(build-system haskell-build-system)
+(native-inputs `(("ghc-async" ,ghc-async)))
+(home-page "http://github.com/takano-akio/filelock";)
+(synopsis "Portable interface to file locking (flock / LockFileEx)")
+(description "This package provides an interface to Windows and Unix file
+locking functionalities.")
+(license license:public-domain)))
+
(define-public ghc-filemanip
(package
(name "ghc-filemanip")
diff --git a/gnu/packages/patches/elm-compiler-disable-reactor.patch
b/gnu/packages/patches/elm-compiler-disable-reactor.patch
index 9871b55e8d..a91bbd94b8 100644
--- a/gnu/packages/patches/elm-compiler-disable-reactor.patch
+++ b/gnu/packages/patches/elm-compiler-disable-reactor.patch
@@ -1,16 +1,21 @@
-commit 20d80e2323b565a36751c9455e535d8f73fa32f7
-Author: Robert Vollmert
-Date: Fri Jun 14 16:05:47 2019 +0200
+From 6edf6711f08a5c67400f0eb087c9e966aa93b05a Mon Sep 17 00:00:00 2001
+From: Robert Vollmert
Re: [RFC] Package of Nomacs
Hi Rovanion, Am Donnerstag, den 31.12.2020, 16:37 +0100 schrieb Rovanion Luckey: > [...] > > > Use git-fetch instead and don't recurse into submodules. You will > > likely encounter some errors, because it doesn't seem as though > > nomacs > > expects you to have its inputs properly packages. *sigh* > > Hmm, this one I'm not sure I understand the reasoning behind. I think > I read in some packaging guidelines that url-fetch was preferred if > possible. The reason is two-fold: First, it seems to me, that this is a github- generated tarball, which have been known to be unstable. Second, the tarball includes a large number of 3rd party sources already packaged in Guix. Most of them are git submodules, so by using a non-recursive checkout you can strip them without much effort. url-fetch is to be preferred, when there is a sane tarball to fetch. Most projects only hosted on github don't have that, but certain large- scale projects (such as GNU itself or GNOME) do host tarballs. It also enables mirror:// URLS, which translate to a number of hosts, the first of which to successfully provide a package is chosen. > > Instead of adding the path to the source directory, try `(cd > > "ImageLounge")` in a phase after 'unpack. > > > > I'm told that cd is an unbound variable when I try that :/ My bad, the Scheme procedure equivalent to cd is "chdir". Regards, Leo
How would packaging Steam-proton games be received?
Happy end of the forever year, everyone One thing I know that I have run into, and have heard so many times over from those on Windows is how unstable or much of a hassle it can be to get games to work. In the last few weeks, I spent ~20 hours just to this hassle myself. Having everything included as a guix package would go a very long way to resolving these instabilities, kicking most of the problems down to just the kernel and kernel modules which is far more constrained. This should make it easier to make not Windows more palatable, but AGPL+DRM isn't exactly the most cozy of relationships. Given this, would having these games as packages be permissible? Perfect being the enemy of the good and all that.
Re: Packaging elm-compiler 0.19.1
Hi Matthew, I’m not 100% sure how guix handles the ghc “boot” libraries but I think time is installed alongside ghc. Doing guix environment --pure --ad-hoc ghc -- ghc-pkg list gets me time-1.9.3. So I do think the version bounds should be satisfied without any other dependency. Mind sharing more of the package definition? - John
Re: How would packaging Steam-proton games be received?
Josh Marshall writes: > Happy end of the forever year, everyone > > One thing I know that I have run into, and have heard so many times over > from those on Windows is how unstable or much of a hassle it can be to get > games to work. In the last few weeks, I spent ~20 hours just to this > hassle myself. Having everything included as a guix package would go a > very long way to resolving these instabilities, kicking most of the > problems down to just the kernel and kernel modules which is far more > constrained. This should make it easier to make not Windows more > palatable, but AGPL+DRM isn't exactly the most cozy of relationships. > Given this, would having these games as packages be permissible? Perfect > being the enemy of the good and all that. Hi Josh, I'm not quite sure what games/software you're referring to, can you clarify? In terms of Steam and Proton which you mention, as far as I'm aware, Steam is non-free software, so not suitable for Guix to distribute [1]. As for Proton, it might be free software, I'm unsure, so maybe that would be useful to package? 1: https://guix.gnu.org/manual/en/html_node/Software-Freedom.html Thanks, Chris signature.asc Description: PGP signature
Re: How would packaging Steam-proton games be received?
On Thu, Dec 31, 2020 at 01:09:06PM -0500, Josh Marshall wrote: > One thing I know that I have run into, and have heard so many times over > from those on Windows is how unstable or much of a hassle it can be to get > games to work. In the last few weeks, I spent ~20 hours just to this > hassle myself. Having everything included as a guix package would go a > very long way to resolving these instabilities, kicking most of the > problems down to just the kernel and kernel modules which is far more > constrained. This should make it easier to make not Windows more > palatable, but AGPL+DRM isn't exactly the most cozy of relationships. > Given this, would having these games as packages be permissible? Perfect > being the enemy of the good and all that. In general, we follow the Free System Distribution Guidelines (FSDG) in deciding what is acceptable to include in GNU Guix: https://www.gnu.org/distros/free-system-distribution-guidelines.en.html All software must be freely licensed, and support for DRM is not permitted. However, if you have code that is working for you, or you think that Guix can improve the situation overall, Guix channels are a well-supported way to use Guix while remaining separate from it. signature.asc Description: PGP signature
Re: How would packaging Steam-proton games be received?
So a separate channel would work for non-free software? I know the stuff is fundamentally gross. I'd still like to have a better way to get out of an ecosystem that is basically entirely all non-free software and a transition to fully free becomes possible. On Thu, Dec 31, 2020 at 1:56 PM Leo Famulari wrote: > On Thu, Dec 31, 2020 at 01:09:06PM -0500, Josh Marshall wrote: > > One thing I know that I have run into, and have heard so many times over > > from those on Windows is how unstable or much of a hassle it can be to > get > > games to work. In the last few weeks, I spent ~20 hours just to this > > hassle myself. Having everything included as a guix package would go a > > very long way to resolving these instabilities, kicking most of the > > problems down to just the kernel and kernel modules which is far more > > constrained. This should make it easier to make not Windows more > > palatable, but AGPL+DRM isn't exactly the most cozy of relationships. > > Given this, would having these games as packages be permissible? Perfect > > being the enemy of the good and all that. > > In general, we follow the Free System Distribution Guidelines (FSDG) in > deciding what is acceptable to include in GNU Guix: > > https://www.gnu.org/distros/free-system-distribution-guidelines.en.html > > All software must be freely licensed, and support for DRM is not > permitted. > > However, if you have code that is working for you, or you think that > Guix can improve the situation overall, Guix channels are a > well-supported way to use Guix while remaining separate from it. >
Re: How would packaging Steam-proton games be received?
Hi Josh, I'm replying off-list, because this subject has been discussed s many times without reaching a different conclusion, and because I worry about starting a flamewar on the mailing list. On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote: > So a separate channel would work for non-free software? I know the stuff > is fundamentally gross. I'd still like to have a better way to get out of > an ecosystem that is basically entirely all non-free software and a > transition to fully free becomes possible. If we think about free software in terms of the "4 freedoms" [0], channels are a fully-supported way to help people take advantage of the "zero-eth freedom", which is the freedom to use the software (Guix) as one sees fit. Personally, I think that ensuring an operating system is 100% free software (and with no DRM support) hampers the success of the free software movement by driving away users. If we lived in a world with free software support for common hardware (ahem, WiFi, Bluetooth, LTE) and for popular software use cases (popular games and apps, commercial and educational software), then offering a totally free system would be a viable approach. But, that world doesn't exist. Even though some people who are happy to use 10+ year old computers for very limited use cases might think it does... many of them don't even use mobile phones... they don't understand contemporary computing at all, from a practical perspective. Nevertheless, the GNU Guix project has made a commitment to working within the FSDG, and we are basically stuck with it barring some cataclysmic change. I think that maintaining a harmonious atmosphere within Guix will help it continue to grow, and channels can satisfy the need for things that don't fit the FSDG. If Guix becomes large enough, it could be transformative for the free software movement. [0] https://www.gnu.org/philosophy/free-sw.en.html signature.asc Description: PGP signature
Re: How would packaging Steam-proton games be received?
On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote: > So a separate channel would work for non-free software? I know the stuff > is fundamentally gross. I'd still like to have a better way to get out of > an ecosystem that is basically entirely all non-free software and a > transition to fully free becomes possible. Yes, channels can work for any kind of software, and they let us keep Guix as "100% free software". There will be occasional hiccups as the module imports from GNU Guix into the channel are changed, but it shouldn't be too often.
Re: How would packaging Steam-proton games be received?
OK, thanks everyone. I've got my next steps. Sorry if this subject has been repetitive. On Thu, Dec 31, 2020 at 2:55 PM Leo Famulari wrote: > On Thu, Dec 31, 2020 at 02:12:16PM -0500, Josh Marshall wrote: > > So a separate channel would work for non-free software? I know the stuff > > is fundamentally gross. I'd still like to have a better way to get out > of > > an ecosystem that is basically entirely all non-free software and a > > transition to fully free becomes possible. > > Yes, channels can work for any kind of software, and they let us keep > Guix as "100% free software". There will be occasional hiccups as the > module imports from GNU Guix into the channel are changed, but it > shouldn't be too often. >
Re: How would packaging Steam-proton games be received?
I don't know in depth how Proton works internally, but I think it includes non free DLLs, including DRM support, to improve compatibility with Windows games. If my understanding is correct, shipping Proton and games that depend on it as part of Guix would be a tacit endorsement of proprietary software that exercises unjust control over users. The GNU project, as a matter of policy, does not recommend non free software components, or free components like DRM that are exclusively useful for restraining user freedoms, so that may be a dead end. I like your energy in this thread though and agree that it would be great if we could help gamers break out of the ugly Steam ecosystem. Itch is an independent game distributor and they also publish all their client code as free software: https://github.com/itchio Bringing Itch to Guix might be an interesting project, if we could find a way to modify the client so that it does not recommend any games that are not free software. There's a healthy and growing list of such games here: https://itch.io/games/tag-open-source We might have to build our own game discovery portal to replace the upstream itch.io storefront, but that would be a really nice thing to have in general. Itch has its own tools for game developers to build their game and ship updates to their users. For example, they designed their own protocol for shipping new game builds using minimal resources: https://github.com/itchio/wharf It would be beneficial if Guix could learn some of Itch's tricks, to support fast moving projects that want to ship frequent updates to users.
Re: How would packaging Steam-proton games be received?
An expanded user-base brings with it an expanded developer-base. On Thu, Dec 31, 2020 at 3:50 PM Ryan Prior wrote: > I don't know in depth how Proton works internally, but I think it includes > non free DLLs, including DRM support, to improve compatibility with Windows > games. If my understanding is correct, shipping Proton and games that > depend on it as part of Guix would be a tacit endorsement of proprietary > software that exercises unjust control over users. The GNU project, as a > matter of policy, does not recommend non free software components, or free > components like DRM that are exclusively useful for restraining user > freedoms, so that may be a dead end. > > I like your energy in this thread though and agree that it would be great > if we could help gamers break out of the ugly Steam ecosystem. Itch is an > independent game distributor and they also publish all their client code as > free software: https://github.com/itchio > > Bringing Itch to Guix might be an interesting project, if we could find a > way to modify the client so that it does not recommend any games that are > not free software. There's a healthy and growing list of such games here: > https://itch.io/games/tag-open-source > > We might have to build our own game discovery portal to replace the > upstream itch.io storefront, but that would be a really nice thing to > have in general. > > Itch has its own tools for game developers to build their game and ship > updates to their users. For example, they designed their own protocol for > shipping new game builds using minimal resources: > https://github.com/itchio/wharf > > It would be beneficial if Guix could learn some of Itch's tricks, to > support fast moving projects that want to ship frequent updates to users. >
Re: How would packaging Steam-proton games be received?
On Thu, Dec 31, 2020 at 02:53:24PM -0500, Leo Famulari wrote: > Hi Josh, > > I'm replying off-list, because this subject has been discussed s > many times without reaching a different conclusion, and because I worry > about starting a flamewar on the mailing list. Oops, I forgot to remove the cc. Oh well.
Re: [RFC] Package of Nomacs
Hi Leo and thank you for your comments.
The nomacs package should probably go to gnu/packages/image-
> viewers.scm.
>
Yup.
> Use git-fetch instead and don't recurse into submodules. You will
> likely encounter some errors, because it doesn't seem as though nomacs
> expects you to have its inputs properly packages. *sigh*
>
Hmm, this one I'm not sure I understand the reasoning behind. I think I
read in some packaging guidelines that url-fetch was preferred if possible.
> Instead of adding the path to the source directory, try `(cd
> "ImageLounge")` in a phase after 'unpack.
>
I'm told that cd is an unbound variable when I try that :/
#:phases (modify-phases %standard-phases
(add-after 'unpack 'cd-to-source-dir
(lambda _ (call-with-output-string (cd
"ImageLounge")
Try to sort them alphabetically, also don't put too much effort into
> making the tails align.
>
Check.
> One thing that's missing is the plugins that are developed in a
> > separate git repository [0] and not included in the source tarballs
> > of the main repository [1]. Ideas on how to make them available in
> > the `plugins` directory during build time are welcome.
> A trick that's often used in Guix is
> (inputs
> `(("extra-source-package"
> ,(origin ...)))
>[other inputs])
> You can then (copy-recursively (assoc-ref inputs "extra-source-
> package") destination) in a phase between 'unpack and 'configure.
>
Thank you! And thank you for the rest of the comments too.
Happy new year!
