Re: New section to easily reference Debbugs URLs within Emacs Debbugs

[Mekeor Melire]

Thanks, Maxim, for implementing some of my suggestions in commit 
06dc36ffb7cde821a4762b299d1c95b3788ba110, as I coincidentally 
found out when reading the commit log.


By the way, I still believe it's less off-putting for average people to see 
two lines of regular expressions instead of 28 lines of symbolic 
expressions.


I'd now like to make another suggestion, appended as patch, that allows for 
URLs like https://issues.guix.gnu.org/12345 to be opened in debbugs-mode within 
Emacs.

>From c7531be0ef70e7b872ffe1f759ded05d3819f863 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Mekeor Melire 
Date: Wed, 4 Oct 2023 22:31:31 +0200
Subject: [PATCH] doc: Update bug-reference configuration snippet.

* doc/contributing.texi (The Perfect Setup)
: Make bug-reference-bug-regexp match
URLs based on issues.guix.gnu.org.
---
 doc/contributing.texi | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 0de47a403b..d32d8baf53 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -427,9 +427,13 @@ The Perfect Setup
  (zero-or-one
   (seq "#" (one-or-more
 (char "0-9"))
- (seq "<https://bugs.gnu.org/;
+ (seq (? "<") "https://bugs.gnu.org/;
   (group-n 2 (one-or-more (char "0-9")))
-  ">")
+  (? ">"))
+ (seq (? "<") "https://issues.guix.gnu.org/;
+  (? "issue/")
+  (group-n 2 (one-or-more (char "0-9")))
+  (? ">"))
 (setq bug-reference-url-format "https://issues.guix.gnu.org/%s;)
 
 (require 'debbugs)

base-commit: 0a1af11ff82254b369fa3ac8a9af2d97bb877ed0
prerequisite-patch-id: 5c2772bc2c8e5d80d5bbe55f6d301484e5976243
prerequisite-patch-id: 8bbff2e38835dfc1230b6bd67b342e6137e85f9e
prerequisite-patch-id: 158f8f743ea550ad35ec410cea3ed8fd7b3bc1f5
prerequisite-patch-id: f053f68a1b77d4246cf0f0ae42644f9c51a809a3
-- 
2.41.0

Re: New section to easily reference Debbugs URLs within Emacs Debbugs

[Mekeor Melire]

2023-09-25 21:53 mek...@posteo.de:

Putting all three thoughts together, I'd gather this code 
suggestion:


[2. application/emacs-lisp; new.el]...


Sorry, it seems I forgot to apply my first thought in the appended 
file... (setq bug-reference-url-format 
"https://issues.guix.gnu.org/%s;). Sorry for the noise.

Re: New section to easily reference Debbugs URLs within Emacs Debbugs

[Mekeor Melire]

2023-09-25 21:27 mek...@posteo.de:


2023-09-17 16:51 maxim.courno...@gmail.com:

> Hello,

Hello Maxim,

> If you use Emacs and Emacs-Debbugs, you may be interested in
> applying the settings newly documented in the 'Viewing Bugs 
> within
> Emacs' section of the manual; see it at the bottom of info 
> "(guix)

> The Perfect Setup").
>
> I hope that's useful,

Thank you for sharing. The new section is very useful for me. I 
have

two things to feed back though.


First feedback: I think the new section should instruct to set 
the
`bug-reference-url-format'. I.e. we should add this to the 
suggested

code snippet: (setq bug-reference-url-format
"https://issues.guix.gnu.org/%s;). Otherwise, the suggested code
snippet results in an error when a bug reference is clicked. See
appendix.


Second feedback: It might be nice to write regular-expressions 
using

the `rx' macro, but imho writing them as strings is shorter,
unobtrusive and thus preferable for average Guix users. I.e. I'd
suggest to replace the two setq-expressions of code that the new
manual section suggests, with the following S-expressions
respectively:

(setq bug-reference-bug-regexp "\\(\\b\\(?:[Bb]ug ?#?\\|[Pp]atch
?#\\|[Ff]ixes:? ?#\\|RFE ?#\\|PR
[+a-z-]+/\\)\\([0-9]+\\(?:#[0-9]+\\)?\\)\\|\\)")

(setq debbugs-browse-url-regexp
"^https?://\\(?:bugs\\|debbugs\\|issues\\.guix\\)\\.gnu\\.org/+\\(\\(?:cgi/bugreport\\.cgi\\?bug=\\)?\\)\\(?3:[[:digit:]]+\\)$")


WDYT?


[2. application/emacs-lisp; reproduce-error.el]...


Third thought: Use #' for quoting functions consistently. Maybe do 
some code alignment.


Putting all three thoughts together, I'd gather this code suggestion:



new.el
Description: application/emacs-lisp

Re: New section to easily reference Debbugs URLs within Emacs Debbugs

[Mekeor Melire]

2023-09-17 16:51 maxim.courno...@gmail.com:


Hello,


Hello Maxim,

If you use Emacs and Emacs-Debbugs, you may be interested in 
applying the settings newly documented in the 'Viewing Bugs 
within Emacs' section of the manual; see it at the bottom of 
info "(guix) The Perfect Setup").


I hope that's useful,


Thank you for sharing. The new section is very useful for me. I 
have two things to feed back though.



First feedback: I think the new section should instruct to set the `bug-reference-url-format'. I.e. we should add this to the 
suggested code snippet: (setq bug-reference-url-format 
"https://issues.guix.gnu.org/%s;). Otherwise, the suggested code 
snippet results in an error when a bug reference is clicked. See 
appendix.



Second feedback: It might be nice to write regular-expressions using the `rx' 
macro, but imho writing them as strings is shorter, unobtrusive and thus 
preferable for average Guix users. I.e. I'd suggest to replace the two 
setq-expressions of code that the new manual section suggests, with the 
following S-expressions respectively:

(setq bug-reference-bug-regexp "\\(\\b\\(?:[Bb]ug ?#?\\|[Pp]atch 
?#\\|[Ff]ixes:? ?#\\|RFE ?#\\|PR 
[+a-z-]+/\\)\\([0-9]+\\(?:#[0-9]+\\)?\\)\\|\\)")


(setq debbugs-browse-url-regexp 
"^https?://\\(?:bugs\\|debbugs\\|issues\\.guix\\)\\.gnu\\.org/+\\(\\(?:cgi/bugreport\\.cgi\\?bug=\\)?\\)\\(?3:[[:digit:]]+\\)$")



WDYT?




reproduce-error.el
Description: application/emacs-lisp

Re: Implementing the guix-dameon in Guile

[Mekeor Melire]

2023-09-13 16:36 m...@cbaines.net:

I think this has been talked about for a while [1], but I want 
to make it happen. Currently the guix-daemon is still similar to 
the nix-daemon that it was forked from, and is implemented in 
C++. I think that a Guile implementation of the guix-daemon will 
simplify Guix and better support hacking on and around the 
daemon to add new features and move Guix forward.


Yippie! I'm really excited about this; and convinced that it'll greatly impact 
and improve the Guix project.

I'd like to hear what people think about which direction the 
implementation should go, and what features they'd like to see.


Here's a feature-request (in the long-run). But I'm not sure if I understand 
correctly that a new, improved Guix-daemon enables us to implement this. Sorry 
if I'm wrong. I'd like to be able to step through the build-process of a 
package phase-by-phase and see what changed after each phase by looking at the 
file-tree.

Re: Suggest improve emacs setting in 'The Perfect Setup'

[Mekeor Melire]

2022-12-31 18:17 jbra...@dismail.de:

Possible also mention how to set up page break lines: 
https://github.com/purcell/page-break-lines


By the way, another good alternative to that Emacs package is: 
https://depp.brause.cc/form-feed/


But I don't think that either of these packages should be 
mentioned in The Perfect Setup. They don't relate to Guix 
specifically.

Draft new Guix Cookbook section on Emacs

[Mekeor Melire]

Hello :)

I'd like to contribute to the Guix Cookbook.

The Cookbook is written in Texinfo format but as I'm not fluent in 
it, I decided I'd first draft my contribution in Org-Mode which 
I'd later export as Texinfo and adapt appropriately. I'm sorry 
that this also means that the hereby submitted draft does not come 
as a Git patch for now.


Find below a first draft of a new chapter entitled "Emacs", 
including two subchapters, "Beginners Guide to the Perfect Setup" 
and "Mu4e".


Regarding the Perfect Setup, I'm convinced that it makes sense to 
have a more beginner-friendly tutorial supplementing the 
instructions which are already present in the Guix manual. It's 
meant to have more background information and more, non-essential 
configuration tips, as well as details on usage, including 
keybindings.


Regarding emails, in the long-term, I'd also like to contribute a 
new chapter on how to use the mailing-lists, elaborating on how to 
get local maildir copies of the mailing-lists with tools like 
isync/mbsync or public-inbox etc. But that's for the future!


I'm looking forward to your feedback.

Kindly
Mekeor

* Emacs

** Beginners Guide to the Perfect Setup

# Why this tutorial?

The GNU Guix manual includes contains a chapter on "The Perfect Setup" of Emacs for hacking on Guix. It is the primary and main resource on this topic. In contrast, this tutorial is just a supplement, dedicated towards beginners as it offers more background information, details on usage as well as non-essential, optional configuration.

# What is Emacs and why is it well suited for Guix?

GNU Emacs is a text editor and, at its core, an interpreter of its own Lisp dialect, Emacs-Lisp. It's well suited for hacking on Guix (and Guix-related) code because of its advanced Lisp editing features and since as part of the GNU project, it's free software, just like GNU Guix.

# Do you have to use Emacs for hacking on Guix?

Using Emacs is not a precondition for hacking on Guix(-related) code. For example, there's at least one Guix maintainer who rather uses Vim. But if you're interested in Emacs or already using it, keep on reading.

# Installation

To install Emacs into your Guix user profile, run:

#+begin_src sh
guix install emacs
#+end_src

*** Geiser

# What is Geiser?

Geiser is a package for GNU Emacs that helps with editing code written in the Scheme programming language. In particular, it supports the GNU Guile Scheme interpreter on which GNU Guix is heavily based.

# Why Geiser?

Using Geiser is recommended not only because it enhances your Scheme editing experience with features like automatic documentation, but also it works with the ~guix-devel-mode~ described later on.

# Installation

To install Geiser into your Guix user profile, run:

#+begin_src sh
guix install emacs-geiser emacs-geiser-guile
#+end_src

Afterwards, (re)start Emacs in order to make sure that Geiser finds its way into Emacs' ~load-path~.

 Load Geiser

To load Geiser by default add this to your Emacs initialization file:

#+begin_src elisp
(require 'geiser)
#+end_src

Note that this not only loads Geiser but – through Geiser's autoloads – also hooks Geiser minor-mode onto ~scheme-mode~. I.e. Geiser will start when you open any Scheme file.

 Geiser Guile Load Path

If you maintain a local clone of the Guix source code repository, it already contains a =.dir-locals.el= file which ensures that the path of your local clone is added to ~geiser-guile-load-path~ whenever you open a Scheme file in there. But nevertheless, it makes sense to add the path to your local Guix repository to ~geiser-guile-load-path~ in your Emacs initialization file so that it's set correctly in other directories as well.

Make sure that the compiled files in your local Guix repository are up-to-date. I.e. whenever your local working directory of the repository changes (for example, after running ~git pull~), rebuild Guix as described in the Guix manual. Otherwise, Guile would auto-compile all Guix sources which leads to misconfiguration[fn:1] and likely hits Geiser's timeout. Consider having two Git worktree of the Guix repository, keeping one always compiled.

If you have other Guix-related source code directories on your machine (and you want to load Guile modules from there), you need to put those in the ~geiser-guile-load-path~ variable. (Geiser will then add those paths to Guile's ~%load-path~ and ~%load-compiled-path~ variables.)

#+begin_src elisp
(setq geiser-guile-load-path
  (list
"~/src/guix"
"~/src/some/channel"))
#+end_src

 REPL Configuration

You may find handy to make Geiser automatically start a REPL (read-eval-print-loop) in the background when a Scheme file is opened:

#+begin_src elisp
(setq geiser-mode-start-repl-p t)
#+end_src

If you want to speed up Geiser, let it open a single REPL per project (instead of per file) and forgo version compatibility checks:

#+begin_src elisp
(setq geiser-repl-per-project-p t)
(setq 

Re: Patch xdg-open in emacs-embark package

[Mekeor Melire]

2023-05-10 17:40 jg...@dismail.de:

I think it would be great to not worry about installing xdg-open 
if you install emacs-embark and it depends on it.


I'm not sure about this since embark.el does a lot more than 
invoking xdg-open and also, it can be used without xdg-open, while 
still being useful.

Re: Patch xdg-open in emacs-embark package

[Mekeor Melire]

2023-05-10 02:11 jg...@dismail.de:


Just writing down a public TODO for myself:

TODO: patch xdg-open (xdg-utils) in emacs-embark package.

https://github.com/oantolin/embark/blob/f88314044d5492efeacb9466122889c6e60c8af4/embark.el#L3710

If anyone else wants to work on this feel free to.


We could introduce a defcustom variable for this command, 
upstream, so that we can use `emacs-substitute-variables'[1] 
within the package declaration in the Guix repository. WDYT?


[1] 
https://github.com/guix-mirror/guix/blob/d1aba42ad4e1909faa21d484975c5954c778e002/guix/build/emacs-utils.scm#L211

Re: Emacs next variants

[Mekeor Melire]

2023-03-10 16:39 zimon.touto...@gmail.com:

As far I know, this branch does not contain the feature 
Tree-sitter. Instead, the feature Tree-sitter is in the branch 
"master", which will be branched later as Emacs 30 and somehow 
will be the next next release of Emacs.


2023-03-12 12:47 and...@trop.in:

Sure, I think [...] after emacs-30 release we will include 
tree-sitter in emacs package itself and also we will be able to 
move emacs-next-pgtk to emacs-pgtk.


Emacs 29.1 will support tree-sitter. This mail-thread seems to 
have been mislead by the wrong assumption that Emacs 30 will be 
the first version to support tree-sitter.


Feel free to check "etc/NEWS" within branch "emacs-29" of Emacs' 
repository and correct me if I'm wrong: 
https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29#n36

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

2022-12-27 19:51 mitchellschmeis...@librem.one:


Mekeor Melire  writes:

Here is a naive implementation which extends use-package to use 
guix to ensure packages.


Thank you very much for this great snippet of code. I just 
successfully set it up locally and I'm very happy.


Would you like to create a public Git repository for this 
elisp-package so that we can collaborate on it? If you don't have 
time to do it, I can create a public Git repository (with your 
copyright note; under GPLv3+?; formally owned by an 
"organization").


Personally, I'm also very much of a noob in things elisp. But 
intuitively, I'd suggest these changes:


It is a bit annoying at first because it prompts for y/n 
verification for every package but I think this behavior is 
desirable.


Personally, I found that behaviour a little tidyous. I'd suggest 
to make it at least configurable.



#+BEGIN_SRC emacs-lisp
(require 'guix)
(require 'guix-profiles)
(require 'guix-read)
(require 'guix-ui-package)


(defgroup use-package-guix nil


What do you think about naming this package/feature 
"use-package-ensure-guix" and using that as a prefix for all other 
functions and variables -- except for use-package-ensure-guix? I 
think "use-package-ensure-guix" would be a good package name 
because it's pretty much the only (important) function which this 
packages aims to offer. So, …



  "use-package support for guix" :group 'use-package-ensure)

(defcustom use-package-profile (concat (getenv "HOME") 
"/.emacs.d/guix-profile")


… this variable would then perhaps be renamed into 
"use-package-ensure-guix-profile" or so.



  "Location of use-package guix profile" :type 'string :group
'use-package-guix)

(defun guix-package-installed-p (package)
  (bui-assoc-value package 'installed))

(defun canonicalize-name (package-name)
  "Make sure package name has \"emacs-\" prefix"
  (if (string-match "^emacs-.+" package-name)
  package-name
(concat "emacs-" package-name)))

(defun emacs-package->guix-package (package)
  "Return guix package from package name"
  (car (guix-output-list-get-entries use-package-profile 'name
 (canonicalize-name 
 package


(defun guix-package-id (package)
  (bui-entry-non-void-value package 'id))


(This function could be removed, I think.)


(defun guix-install-package (package)
  (if (guix-package-installed-p package)
  t
(guix-process-package-actions
 use-package-profile
 `((install (,(string-to-number (car (split-string 
 (bui-entry-id package) ":"))) "out"

 (current-buffer)))

(defun guix-installed-packages ()
  (guix-output-list-get-entries use-package-profile 'installed))


(defun use-package-ensure-guix (name args _state  
_no-refresh)

  (dolist (ensure args)
(let ((package
   (or (and (eq ensure t)
(use-package-as-symbol name))
   ensure)))
  (when package
(when (consp package)
  (use-package-pin-package (car package) (cdr package))
  (setq package (car package)))

(let ((package (emacs-package->guix-package 
(use-package-as-string package

  (unless (guix-package-installed-p package)
(condition-case-unless-debug err
(progn
  (when (assoc package (bound-and-true-p
package-pinned-packages))
(package-read-all-archive-contents))
  (if (assoc package package-archive-contents)
  (package-install package)
(package-refresh-contents)
(when (assoc package (bound-and-true-p
  package-pinned-packages))
  (package-read-all-archive-contents))
(guix-install-package package))
  t)


What is the purpose of this long (progn …)? Could we instead 
simply write (guix-install-package package)?




  (error (display-warning 'use-package (format 
  "Failed to

install %s: %s" name (error-message-string err))
:error)


I'd suggest to miss the "error" label on this message, and rather 
label it as "warning" (which is the default). We could also 
suggest to add ":ensure nil" if it's a built-in feature. (E.g. in 
case of (use-package recentf).)



;;;###autoload
(add-to-list 'load-path (concat use-package-profile 
"/share/emacs/site-lisp"))


(provide 'use-package-guix)
#+END_SRC


Finally, I'm not sure if installing packages from my custom local 
guix-channel succeeded. I need to retry and investigate more.

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

2022-12-19 14:15 and...@trop.in:


On 2022-12-18 09:11, Liliana Marie Prikler wrote:

> Am Sonntag, dem 18.12.2022 um 01:54 + schrieb Mekeor Melire:


I'm neither the author, nor the user of guix home import, however I think it 
could be a good place for such a functionality, but I would suggest to 
maintain this helper functions for a while in a personal channel, mature it 
and revisit this question later.


Good idea. But separating this into a personal channel could also lead to the 
feature being forgotten.


To make a solution more robust and complete, you can take a look at 
straight.el and how it redefines use-package-ensure-function and do 
something similiar to generate a list of packages for guix. Another detail 
is that use-package accepts a symbol value for :ensure and you can write 
something like:


;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
(use-package vertico
  :ensure t
  ...)

(use-package vertico-directory
  :ensure vertico
  ...)


True! The parser should consider the :ensure keyword.


This way you won't need a concept of "blocked" packages.


It'd still be good to have such a concept in order to block packages that 
won't be used on Guix-driven system. For example:


#+begin_src elisp
(when (this-is-not-a-guix-driven-system)
 (use-package some-package-that-is-not-packaged-for-guix))

;; or equivalently

(use-package some-package-that-is-not-packaged-for-guix
 :when (this-is-not-a-guix-driven-system))
#+end_src

One more idea: make a function which accepts file-like/origin object instead 
of string and generates a package with propagated-dependencies based on the 
content of source code provided as an argument.


You mean something like this?:

#+begin_src scheme
(define-public my-emacs
 (emacs-from-init
   :custom-emacs-package emacs-with-athena-instead-of-gtk
   :init "/home/user/.emacs.d/init.el"))
#+end_src

By the way, this won't be a "pure" package. When using 
=emacsWithPackagesFromUsePackage= feature from nix-community's emacs-overlay, 
I needed to pass an --impure flag.


Personally, with my emacs config I do the things vice versa: I have elisp 
code in scheme files with a list of explicit dependencies:


https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946


Interesting!

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

2022-12-18 09:11 liliana.prik...@gmail.com:

I think we should be able to build an Emacs service in Guix Home that can 
manage init.el. As a workaround, use-package should also have a :when 
clause, so you can use :when (featurep 'some-package-autoloads) if you're 
unsure whether 'some-package is actually installed. This makes your init 
file a little more resilient and is particularly useful with pure shells.


=guix home import= for init.el is a great idea! (See below for use-cases.)

And yes, =:when (featurep 'some-package-autoloads)= is a workaround that makes 
init.el files loadable even if respective packages are not available. But the 
submitted code aims to enable you to install needed emacs-packages so that 
such a restricting workaround is not needed.


Given the caveats, I would rather like to see an Emacs Lisp based script 
that mocks use-package and generates a manifest by evaluting init.el. This 
should give you more correct results. It's not a bad idea per se, but as-is, 
I think it would better be maintained in your own channel before 
upstreaming.


Problem is that in cases where needed packages are not installed and the user 
did not add =:when (featurep 'foo)= everywhere, it's possible that evaluating 
init.el will fail because of some package not being available. Thus, IMHO, we 
can't rely on Emacs to evaluate the init.el. But we could use Emacs to expand 
the (use-package) macros inside init.el. But I doubt that it's worth it. I 
rather think it's easier to use Guile to parse invocations of =require= and 
=use-package=.


For upstreaming, I see two potential paths. The first one would be 
integration to `guix home import', which Andrew Tropin (CC'd) could probably 
tell you more on. The second would be integration into `guix package' as a 
callable function/command line argument, but IMHO that's less likely to 
pass.


All in all, I think there are three use-cases:

- If you want Guix Home to handle the installation of emacs- packages, there 
 should be =guix home import= to automatically install those packages, as 
 resulting from early- and init.el files.


- If you simply want to install all emacs- packages once per CLI, there should 
 be =guix package --install-from-elisp-file=~/.emacs.d/init.el= and similar 
 CLI-arguments or -commands, such as --install-from-elisp-expression, 
 --install-from-elisp-init-files. There could also be --fit-to-elisp- 
 variants which not only install packages, but also remove redundant, unused 
 emacs-* packages.


- If you want to use a manifest.scm for your Guix user-profile and import 
 appropriate emacs- therein, there should be Guile modules and functions 
 which allow to do so, as the submitted code does. Those modules could also 
 be used with =guix package -e=.


And in all three cases, your early- and init.el files might load packages via 
=require= or =use-package= at least.

Re: bringing npm packages to Guix

[Mekeor Melire]

2022-11-19 18:27 zamfo...@twdb.moe:


Hello, Guix!


Hello :)

A few months ago, I picked up the work towards importing npm packages to 
Guix by Jelle et al. in the hopes of continuing it, and I felt disheartened 
when I concluded that it does indeed seem like a very large part of npm is 
necessary to build even a simple package like jQuery.


Thanks for bringing this back up!

Although, I work with the node/npm ecosystem on a daily basis, unfortunately, 
I don't really understand why it's so difficult to import npm-packages into 
Guix.


But, recently, I decided to spend some more time thinking about it, and I 
realized that not all of the ‘devDependencies’ of a given package are 
actually necessary to build it. A lot of packages have ‘devDependencies’ for 
things such as tests and watching the filesystem for changes for ease of 
development.


Is importing npm-packages into Guix difficult because npm-packages have so 
many dependencies?


If you think about it, what the vast majority of npm packages need to build 
successfully comes down to (optionally) compile TypeScript, then 
(optionally) perform some kind of bundling or transpilation. And that 
doesn’t really require TypeScript or a build tool from npm, since esbuild 
(which is already packaged) can do both of those things by itself.


Is importing npm-packages into Guix so difficult because we have a 
chicken-and-egg problem, since many build-time dependencies (like TypeScript) 
have so many dependencies themselves?


Also, is there a reason to choose esbuild over rust-swc (or vice versa)?

Now, taking away the ‘devDependencies’ when recursing the dependency tree 
makes the whole endeavor of importing an npm package seem *much less* 
difficult and scary! The biggest unfortunate issue is that for packages with 
a build step (TypeScript and/or bundling+transpilation), it is necessary to 
use esbuild ad‐hoc (i.e. in a case-by-case basis), because each package has 
its own build peculiarities, and esbuild doesn’t acknowledge them. (One 
solution could be to create an esbuild wrapper that mimics ‘tsc’ and other 
tools.)


Could we also build TSC with Esbuild, and then use TSC to build packages that 
depend on it, instead of mimicking TSC with Esbuild? Does that make sense?


With "mimicking TSC", do you mean that Esbuild does not transpile multiple 
.ts-files at once? (By the way, Esbuild seems to make use of the tsconfig.json 
file, according to .)


With that approach in mind, I was able to package sucrase as a proof of 
concept! Note that sucrase doesn’t have a lot of transitive dependencies, so 
it was easy to just modify the phases of each package in an ad‐hoc way. 
However, also note that sucrase depends on itself, so I decided to bootstrap 
it with esbuild, then use the bootstrapped version to build sucrase again. 
(The bootstrapped sucrase seems to also work as expected!)


That's so great!

Sorry for asking nooby questions. I just want to catch up and press ahead with 
the discussion.

Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Mekeor Melire]

Hello,

I'd like to share some code, thus prove a concept, ask for 
feedback, and ask if it could makes sense, under certain 
circumstances, to provide similar code in GNU Guix. The code can 
be used in a ~manifest.scm~ file (but probably could also be used 
with ~guix package -e~ or inside ~guix repl~) where it can be used 
to import all ~emacs-*~ packages that are loaded with 
~(use-package PACKAGE [...])~ inside an Elisp-file like ~init.el~:


#+begin_src scheme
;; ~/some/manifest.scm
(specifications->manifest
(append
  (el/file->specifications "/home/user/.emacs.d/init.el")
  (list
"emacs"
"git"
"gnupg"
"mu"
"syncthing")))
#+end_src

It has many severe caveats, including but not limited to:

1. The code uses Guile/Scheme's ~read~ function which interprets 
the Elisp-file as Scheme. Thus, the code does not really find out 
which packages are loaded, but rather it only looks for the 
~(use-package PACKAGE [...])~ pattern of an S-expression. E.g. 
something like ~(apply 'use-package foo)~ won't be caught. (I 
don't expect Guile's Emacs-Lisp language-feature to be mature 
enough to be usable for this.)


2. Not all external packages are loaded with ~use-package~. E.g. 
~(require 'foo)~ might be used directly. But it'd be possible to 
extend the code to allow several ways/patterns of importing 
packages, and maybe also to specify custom patterns.


3. Not all S-expressions that match against ~(use-package 
PACKAGE)~ are load external packages. E.g. ~(if nil (use-package 
foo))~ won't load anything at all. Also, neither ~(use-package 
emacs)~ nor ~(use-package savehist)~ will load anything, because 
they ~require~ features that ship with GNU Emacs by default. 
That's why the functions in the appended code offer an optional 
keyword argument, #:block, in order to block a list packages.


4. The ~manifest.scm~ is not the single source of truth anymore. 
I.e. this code compromises the purpose of a manifest. (It's 
possible to extend the code such that the Elisp-file's hash can 
optionally be verified with given hash.)


Nevertheless, for me, personally, it's pretty neat and handy to 
use, because I don't need to maintain the list of emacs-packages 
in two places. I also think that it could come pretty handy for 
many others, at least in order to initialize their user-profile, 
by running something like ~guix package -e '(some-magic 
"/home/user/.emacs.d/init.el")'~.


What do you think? Should this go into a separate, private 
channel? Into the Guix Cookbook? Into Guix, if so, then probably 
with lots of changes? Should it just stay here, in this mailing 
list thread? Or do you think this is just a bad idea in general?


I should mention that I go the idea for this code from the 
Nix-Community's Emacs-Overlay which offers a similar feature; as 
described in their README as follows:


#+begin_src nix
# 
  https://github.com/nix-community/emacs-overlay#extra-library-functionality

{
environment.systemPackages = [
  (emacsWithPackagesFromUsePackage {
# Your Emacs config file. Org mode babel files are also
# supported.
# NB: Config files cannot contain unicode characters, since
# they're being parsed in nix, which lacks unicode
# support.
# config = ./emacs.org;
config = ./emacs.el;
# ...
})]}
#+end_src

Here's the code. Please show mercy, it's my first real Scheme 
code:


(define-module (manifest)
  #:autoload (gnu packages)(specifications->manifest)
  #:autoload (srfi srfi-1) (drop fold-right)
  #:autoload (ice-9 textual-ports) (get-string-all))

;;
;; LIBRARY

(define el/default-block
;;   "Default list of packages, as symbols, which will be blocked. It's a subset
;; default features provided by GNU Emacs."
  '(emacs hl-line outline savehist))

(define* (el/file->specifications content-f #:key (block el/default-block))
  "Given the file-path CONTENT-F, interprete it as an Emacs-Lisp source-code
and extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
  (call-with-input-file content-f
(lambda (input) (el/port->specifications input #:block block

(define* (el/string->specifications content-s #:key (block el/default-block))
  "Given a string CONTENT-S, interprete it as an Emacs-Lispsource-code and
extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
  (call-with-input-string content-s
(lambda (input) (el/port->specifications input #:block block

(define* (el/port->specifications content-p #:key (block el/default-block))
  "Given the input-port CONTENT-P, interprete it as an Emacs-Lisp source-code
and extract a list of package-names, as strings, that have been loaded using
(use-package PACKAGE [...])."
  (let*
((content-string-or-eof
   (get-string-all content-p))
  (content-string
(if
  (eof-object? content-string-or-eof)

Re: [PATCH guix-artwork v2] website: posts: Add Dissecting Guix, Part 1: Derivations.

[Mekeor Melire]

I have one remark.

2022-12-12 19:31 pa...@disroot.org:


+If you're using Emacs, you can instead install
+[Geiser](https://nongnu.org/geiser), which provides a 
comfortable Emacs UI for
+various Lisp REPLs, invoke `guix repl --listen=tcp:37146 &`, 
and type
+`M-x geiser-connect RET RET RET` to connect to the running 
Guile instance.


As noted in , Guix System 
users, who use the =~/.guile= file which is created by default, 
will need to pass the =INSIDE_EMACS= environment variable to =guix 
repl=, like this:


#+begin_src sh
INSIDE_EMACS=true guix repl --listen=tcp:37146 &
#+end_src

Otherwise, they'll experience a freeze (which they'll need to 
break with C-g).

Re: [PATCH guix-artwork v2] website: posts: Add Dissecting Guix, Part 1: Derivations.

[Mekeor Melire]

2022-12-12 19:31 pa...@disroot.org:

This patch adds an updated blog post, taking the critiques on 
this thread into

account.

* Changed post name to just "Derivations"
* Removed subjective "simple" language
* Added subheadings to "Exploring ``"
* Added field recap to "Conclusion"
* Added "Utilising ``", with examples for 
READ-DERIVATION,
  READ-DERIVATION-FROM-FILE, WRITE-DERIVATION, and 
  BUILD-DERIVATION

* Wrapped lines to 80 columns


looks good to me :)

Re: geiser and guix repl

[Mekeor Melire]

2022-12-12 13:17 luis.felipe...@protonmail.com:


There's this bug report which seems to be related:

Connecting Geiser to Guile listening to a socket: No prompt 
found! (.guile to blame) https://issues.guix.gnu.org/35727.


Yes, thank you. I also think that's exactly this bug. Let's 
continue discussion in that thread!

Re: Dissecting Guix -- blog post series

[Mekeor Melire]

2022-12-11 10:08 pa...@disroot.org:


On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote:

> By the way, the text does not seem to strictly fill columns at 
> a certain line width. So I did not bother to fill columns in 
> the "patch".


Right, I should set up FILL-COLUMNS-INDICATOR... :)


Or auto-fill-mode? :)

> If the purpose is out of scope, then we should not dive in 
> that deeply. Especially, I'd suggest skip the code snippet.


I'm not sure about this.


Personally, I felt kind of fooled at that point, because it felt 
like I had made needless efforts to read an irrelevant code 
snippet.


> I think an example for invoking read-derivation-from-file 
> would round up this tutorial really nicely because it'd close 
> the circle between .drv-files and -objects.


Okay!  And one for write-derivation, too.


Sure :)

By the way, sorry for the malformatted e-mail; I was tweaking 
around with my mail-client's settings. (I'm now using f=f and 
non-broken lines.) Hope my mails are well readable at your end. 
Please let me know if they're not.

Re: geiser and guix repl

[Mekeor Melire]

2022-12-11 12:39 acpadoa...@yahoo.com.br:


I figure out that the issue was indeed the colors.

I had an .guile file forcing it to use colors.


Ah, I guess that's why Guix System ships with the following 
~/.guile file. At least that's where I think I got it from, if I 
remember correctly.


--8<---cut here---start->8---
(cond ((false-if-exception (resolve-interface '(ice-9 readline)))
  =>
  (lambda (module)
;; Enable completion and input history at the REPL.
((module-ref module 'activate-readline
 (else
  (display "Consider installing the 'guile-readline' package 
  for

convenient interactive line editing and input history.\n\n")))

 (unless (getenv "INSIDE_EMACS")
   (cond ((false-if-exception (resolve-interface '(ice-9 
   colorized)))

  =>
  (lambda (module)
;; Enable completion and input history at the 
REPL.

((module-ref module 'activate-colorized
 (else
  (display "Consider installing the 'guile-colorized' 
  package

for a colorful Guile experience.\n\n"
--8<---cut here---end--->8---


Antonio Carlos Padoan Junior  writes:

> I'm facing some trouble using guix repl and geiser with 
> company-mode enabled. Emacs is hanging. I saw in documentation 
> that the issue is probably the regex used to parse the prompt.

>
> However, the default prompt regex looks fine. The only 
> difference I noticed between a geiser's session working 
> correctly (started from emacs) and guix's session (started 
> from terminal + geiser-connect) is the prompt colors.


By the way, personally, starting "guix repl --listen=tcp:37146" 
from terminal and then running M-x geiser-connect makes Emacs 
freeze for me. Do you experience the same?

Re: Dissecting Guix -- blog post series

[Mekeor Melire]

2022-12-08 18:24 pa...@disroot.org:

> Some of you may have seen on IRC that I've been writing a post for the Guix 
> blog that I hope will form the first part of a series. This series aims to 
> dissect the internals of Guix, from bottom to top.

Great, I'm looking forward to read it! Especially, personally, I'm eager for 
the rather fundamental concepts of Guix (and Nix).

> Perhaps they could go in the cookbook once the series is done?

Yes, I personally think the content should be published at two places at the 
same time: OTOH, it should either be incorporated into either the manual or the 
cookbook; and OTOH, it should be published as a blog-post. The blog-post should 
also link to the respective section of the manual or cookbook in a preamble.

> * Dissecting Guix, Part 1: Derivations
> * Dissecting Guix, Part 2: The Humble G-Expression
> * Dissecting Guix, Part 3: Packages
> * Dissecting Guix, Part 4: Monads
> * Dissecting Guix, Part 5: Profiles and Search Paths
> * Dissecting Guix, Part 6: Goings-On in the Build Container
> * Dissecting Guix, Part 7: Record Types
> * Dissecting Guix, Part 8: Substitutes and Grafts
> * Dissecting Guix, Part 9: Cross-Compilation

I think it'd also be fine to come up with the titles during the process of 
writing as sometimes that process itself is insightful. E.g. I could imagine 
parts 2 and 4 to collapse. Maybe, maybe not, you'll see.

> * Dissecting Guix, Part 10: Services
>
> Walks you through the process of creating a service, and thouroughly explains 
> system configuration.

How'd this part differ from section "12.18 Defining Services" of the manual?

> * Dissecting Guix, Part 11: Home Services
> * Dissecting Guix, Part 12: Writing a Subcommand
> * Dissecting Guix, Part 13: Lending a Hand
>
> How to edit the Guix source code and submit patches to be reviewed by the 
> lovely Guix community!

How'd this part differ from sections 22 and "22.6 Submitting Patches" from the 
manual?

Now, as for the actual article. Firstly, I added some comments below. Secondly, 
I created a "patch" suggesting some changes.

By the way, the text does not seem to strictly fill columns at a certain line 
width. So I did not bother to fill columns in the "patch".

> title: Dissecting Guix, Part 1: Derivations and Derivation
> date: TBC
> author: (
> tags: Dissecting Guix, Functional package management, Programming interfaces, 
> Scheme API
> ---
> To a new user, Guix's functional architecture can seem quite alien, and
> possibly offputting.  With a combination of extensive `#guix`-querying,
> determined manual-reading, and plenty of source-perusing, they may
> eventually figure out how everything fits together by themselves, but this
> can be frustrating and often takes a fairly long time.
>
> However, once you peel back the layers, the "Nix way" is actually rather
> elegant, if perhaps not as simple as the mutable, imperative style
> implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and,
> [`pacman`](https://wiki.archlinux.org/title/pacman).  This series of blog
> posts will cover basic Guix concepts, taking a "ground-up" approach by
> dealing with lower-level concepts first, and hopefully make those months of
> information-gathering unnecessary.
>
> Before we dig in to Guix-specific concepts, we'll need to learn about one
> inherited from [Nix](https://nixos.org), the original functional package
> manager and the inspiration for Guix; the idea of a _derivation_ and its
> corresponding _store items_.
>
> These concepts were originally described by Eelco Dolstra, the author of Nix,
> in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see
> _§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_.
>
> # Store Items
>
> As you almost certainly know, everything that Guix builds is stored in the
> _store_, which is almost always the `/gnu/store` directory.  It's the job of
> the 
> [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)
> to manage the store and build things.  If you run
> [`guix build 
> PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html),
> `PKG` will be built or downloaded from a substitute server if available, and
> a path to an item in the store will be displayed.
>
> ```
> $ guix build irssi
> /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3
> ```
>
> This item contains the final result of building [`irssi`](https://irssi.org).
> Let's peek inside:
>
> ```
> $ ls $(guix build irssi)
> bin/  etc/  include/  lib/  share/
> $ ls $(guix build irssi)/bin
> irssi*
> ```
>
> `irssi` is quite a simple package.  What about a more complex one, like
> [`glib`](https://docs.gtk.org/glib)?
>
> ```
> $ guix build glib
> /gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin
> /gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug
> /gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc
> /gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3
> 

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-09 23:10 mek...@posteo.de:

> 2022-12-05 17:23 i...@selidor.net:
>
> > in #59746 I skipped documenting `resume_offset` with more detail, even
> > if it's needed for resuming from a swap file. The reason is that
> > according to [swsusp doc][1], some specific tool may be needed to
> > compute the swap file offset. There is [swap-offset][2] from the
> > uswsusp suite, which is missing from Guix and no longer shipped with
> > Debian.
>
> What about the "filefrag" executable from the "e2fsprogs" package.
> According to this article, it can be used in place of the deprecated
> uswsusp suite:
>
> https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html

I just tried this out. And it worked like a charm! I have hibernated and
resumed successfully - first time with Guix System. I'm so happy :)

Would you like to add instructions for swap-files to your
patch-series #59746?

What I did: First, determine offset:

--8<---cut here---start->8---
$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1717986918 (4194304 blocks of 4096 bytes)
 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..   0:5308416..   5308416:  1:
--8<---cut here---end--->8---

Then, use offset in operating-system declaration:

--8<---cut here---start->8---
  (kernel-arguments
(cons*
  "resume=/dev/mapper/cryptroot"
  "resume_offset=5308416"
  %default-kernel-arguments))
--8<---cut here---end--->8---

Caveat: IIUC, this does not work with Btrfs.

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-05 17:23 i...@selidor.net:

> in #59746 I skipped documenting `resume_offset` with more detail, even
> if it's needed for resuming from a swap file. The reason is that
> according to [swsusp doc][1], some specific tool may be needed to
> compute the swap file offset. There is [swap-offset][2] from the
> uswsusp suite, which is missing from Guix and no longer shipped with
> Debian.

What about the "filefrag" executable from the "e2fsprogs" package.
According to this article, it can be used in place of the deprecated
uswsusp suite:

https://www.linuxuprising.com/2021/08/how-to-enable-hibernation-on-ubuntu.html

Re: Status of hibernation (suspend to disk) in Guix

[Mekeor Melire]

2022-12-02 21:32 m...@tobias.gr:

> Ivan Vilata i Balaguer 写道：

> > But then I wonder if I may have rushed to post the patch, as I don't
> > know whether hibernation is supposed to be more or less mature or
> > supported in Guix (we may not want to encourage people to use a
> > feature which may easily cause data loss)… Though it works quite
> > well for me!
>
> OTOH, I deliberately hadn't documented ‘resume=’ so far.
>
> OTOH, I have been hibernating multiple times a day for years now, only
> ever rebooting my laptop for kernel updates.
>
> So the feature is probably safe, and we should probably consider it
> supported at this point. Thanks for bringing it up!
>
> > So the TL;DR would be: Is it worth adding such documentation, given
> > the current state of hibernation support in Guix?
>
> I think documenting the current status quo in time for 1.4.0 is a good
> idea.
>
> The next step is to automate things so ‘resume=’ becomes optional.
> This should have landed already, but hasn't for personal reasons. The
> code is basically ready, but won't be in the release.

Thanks for making hibernation work and for bringing that up. I have two
questions:

  1. Does hibernation work in case of swap-partition inside an
 luks-encrypted device?

  2. Does hibernation work in case of a swap-file inside a
 root-partition inside a luks-encrypted device?

Also, I'm not sure if it makes sense to mark the hibernation-feature
stable and finished if the mentioned two cases are not supported.

Re: guix open

[Mekeor Melire]

2022-11-18 / 13:49 / jg...@dismail.de:

> what do you think of having a `guix open` command that opens the projects
> home-page in your $BROWSER?
>
> For example, in case you want to specify the browser and override the default
> $BROWSER (e.g. icecat):
>
> guix open nnn --browser=chromium
>
> bloat?

what's the advantage over this one-liner?

guix show recutils | recsel -P homepage | xargs xdg-open

Re: guix melpa mirror!

[Mekeor Melire]

2022-11-16 / 07:09 / jg...@dismail.de:

> Have people seen this yet?
> https://github.com/babariviere/guix-emacs

yes, i used this for a while (as you might have seen in the list of
closed issues). but i regularly ran into errors and failures. on the
other hand, the author reacted quite quickly and fixed the mistakes.
still, personally, i didn't find it stable enough to use.

Split (gnu packages suckless) module

[Mekeor Melire]

Hi Guix :)

I would like to propose to split the (gnu packages suckless) module,
located in the /gnu/packages/suckless.scm source file. It contains
package declarations for software written by the Suckless group, namely
following packages:

blind, colors, dmenu, dwm, fortify-headers, human, lchat, libutf,
noice, prout, sbm, scron, sent, skroll, slock, slscroll, slstatus,
spoon, st, surf, tabbed, wificurse, xbattmon

The reasons for this proposal are:

  1. We generally do not create modules according to the groups of
 developers, but rather package declarations are grouped into
 modules according to their function (e.g. "wm") or according to
 some technical or factual realm they belong to (e.g. "haskell" or
 "music"). There is no reason why software from the Suckless group
 should not follow this rule.

  2. There are hints indicating that the Suckless group sympathizes to
 oppressive Nazi ideology. The Suckless group is a registered
 association in Munich, Germany.

 
https://web.archive.org/web/20210817073134/https://ev.suckless.org/impressum/

 - It has been reported that one of their members (L.H.) called
   their mail server "Wolfsschanze" which was the name of Hitlers
   last bunker.

   https://twitter.com/pid_eins/status/1113738766471057408

 - In 2017, they did a torch march during their conference which is
   a Nazi symbol.

   
https://web.archive.org/web/20210910103557/http://suckless.org/conferences/2017/

 - In 2018, on the Devuan mailing list, one of their members (E.W.)
   depicts the defeat of Nazi Germany as a genocide on Germans.

   
https://web.archive.org/web/20210613185451/https://lists.dyne.org/lurker/message/20181010.120415.e5f96d11.en.html

What do you think? Maybe we should start discussing where each of these
suckless software package declarations should be moved to? My
suggestions follow:

#+begin_src
blind:
Command line video editing utilities
→ (gnu packages video)

colors:
Extract colors from pictures
→ (gnu packages image)

dmenu:
Dynamic menu
→ (gnu packages xorg)

dwm:
Dynamic window manager
→ (gnu packages wm)

fortify-headers:
Standalone fortify-source implementation
→ ?

human:
Convert bytes to human readable formats
→ (gnu packages textutils)

lchat:
Line chat is a frontend for the irc client ii from suckless
→ (gnu packages irc)

libutf:
Plan 9 compatible UTF-8 library
→ (gnu packages c)

noice:
Small file browser
→ (gnu packages disk)

prout:
Smaller lp command
→ ?

sbm:
Simple bandwidth monitor
→ (gnu packages monitoring)

scron:
Simple cron daemon
→ ?

sent:
Plain-text presentation tool
→ (gnu packages textutils)

skroll:
Commandline utility which scrolls text
→ (gnu packages textutils)

slock:
Simple X session lock
→ (gnu packages xorg)

slscroll:
Scroll-back buffer program for st
→ (gnu packages terminals)

slstatus:
Status monitor for window managers
→ (gnu packages wm)

spoon:
Set dwm status
→ (gnu packages wm)

st:
Simple terminal emulator
→ (gnu packages terminals)

surf:
Simple web browser
→ (gnu packages web-browsers)

tabbed:
Tab interface for application supporting Xembed
→ (gnu packages xorg)

wificurse:
Wifi DoS attack tool
→ (gnu packages networking)

xbattmon:
Simple battery monitor for X
→ (gnu packages xorg)
#+end_src

Ciao Guix :)

Wrap %default-guix-channel inside channel-with-substitutes-available by default?

[Mekeor Melire]

I think, by default, the focus should be on speeding up Guix (and
specifically `guix pull`). I suggest to wrap %default-guix-channel
inside channel-with-substitutes-available, like this:

(define %default-channels
  (list (channel-with-substitutes-available
%default-guix-channel
"https://ci.guix.gnu.org;)))

This way, beginners would enjoy a little speed-up, and sophisticated
users could still use (list %default-guix-channel).

What do you think?

Speed up package installation by using images instead of archives (like distri)?

[Mekeor Melire]

Hello Guix!

On the Guix-blog¹, Ludo already mentioned the lightning talk of Michael 
Stapelberg on the “distri” package manager which installs packages 
faster than common package managers by an order of magnitude.


Common package managers install a package by downloading it as an 
(compressed) archive and extracting the archive. But this extraction 
takes very long as it requires to create dozens of files on the file 
system which is an expensive IO operation.


In contrast, distri downloads the package as an (squashfs) image. That's 
it. The image will then be mounted (which is not an expensive IO 
operation) as a read-only virtual-file-system. (But as it's not 
recommendable to mount as many images as there are installed packages, 
distri mounts the package-images lazily, i.e. right before they are 
being used.)


(At least, the above explanation reflects my understanding.)

Thus, I wonder: (0) Does it make sense to make Guix follow this idea as 
well? I.e. should we make Guix install packages by downloading images 
and mounting those instead of extracting archives? (1) Does this even 
fit into Guix technically? I.e. how hard would it be to implement this? 
(2) And would it even be worth it? I.e. how much faster would Guix 
become?


I hope for an exciting discussion!


mekeor

--

Footnotes:

  1: 
https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/

Re: How to package go-sqlite3, go-fuse, and finally TMSU?

[Mekeor Melire]

Frederick Muriithi  writes:

> I was looking into how to write package definitions for go packages,
> and was searching for any work on a Go build system, and ran into this
> thread.
>
> I have done some work trying to write definitions for go packages in
> the following repositories:
>
> - https://github.com/fredmanglis/guix-arvados
> - https://github.com/fredmanglis/guix-ipfs
>
> Maybe I can assist in the building of the go build system in my
> off-peak hours. My guile skills are very weak at this point, but I am
> willing to learn as I go.
>
> Let me know what you think.

I just briefly looked into your code.

Apparently you know how to build Go programs and you understand the Go
infrastructure. Guix needs you.

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: NetworkManager instead of Wicd in ‘%desktop-services’?

[Mekeor Melire]

Mark H Weaver  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Now, as someone who doesn’t use GNOME, I wonder if NM would work well
>> for me.  Last time I tried it’s CLI was too low-level to be usable, and
>> I don’t remember seeing a curses interface.  Suggestions?
>
> There is a curses interface included with Network Manager.  It's called
> 'nmtui'.  It's not getting built because it depends on 'newt', which is
> not an input to our Network Manager package.

Personally, I like to use the command-line interface of network-manager
called 'nmcli' which comes with it out of the box.

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

How to package go-sqlite3, go-fuse, and finally TMSU?

[Mekeor Melire]

I want to package TMSU:

https://github.com/oniony/TMSU

As described in the COMPILING instructions at

https://github.com/oniony/TMSU/blob/master/COMPILING.md

it needs these two go-libraries:

go-sqlite: https://github.com/mattn/go-sqlite3
go-fuse:   https://github.com/hanwen/go-fuse

But how to package go-libraries for Guix? We don't have a
go-build-system. On usual distributions, you install these libraries
either with `go get github.com/mattn/go-sqlite3` or `go install
github.com/mattn/go-sqlite3`. In fact, Nix just downloads those two
libraries to the same directory as TMSU:


https://github.com/NixOS/nixpkgs/blob/2e983f14f628dab9d83282eca5f85da0846ba0af/pkgs/tools/filesystems/tmsu/default.nix

PS: Do you know alternatives similar to TMSU?

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: Looking to contribute

[Mekeor Melire]

Danny Milosavljevic  writes:

> Wait.  AFAIK one cannot delete system generations [yet].  Has that changed?
>
> But deleting user [package] generations works, yes.

Somewhere on the mailing-list I found out that you can delete a system
generation like this:

$ rm /var/guix/profiles/system-N-link
$ guix gc

(as root?)

Re: Haskell updates?

[Mekeor Melire]

Ricardo Wurmus  writes:

> is anyone working on Haskell updates?  Looks like we have some catching
> up to do.

I'm not working on it, but I'm willing to join. How do we want to
proceed? What's the plan? What's the strategy?

We have a stackage-importer now, right? Can't we just import all packages from
stackage-lts?

What about the idea, developed by Federico Beffa and Troy Sankey at

https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00226.html

, to create a package ghc-all-cabal-files as implicit dependency of those ghc-*
packages which are listed in

https://github.com/commercialhaskell/all-cabal-files/tree/hackage

? Federico, Troy, are you working on this? Unfortunately, both of you
seem to got pretty inactive lately, AFAICS.

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: Defining user services in Guix.

[Mekeor Melire]

Mathieu Othacehe  writes:

>>> But you can start your own shepherd under your user account and have that 
>>> shepherd manage user services - it's nice.
>
> Thank you Danny for the details procedure. I'll use that for now !
>
>> Surely we could do better, like providing unprivileged users with a tool
>> akin to ‘guix system reconfigure’ but to manage their own services.
>> This came up several times in the past.
>
> Well, I think it's too bad that user services can't be handled as easily
> as the other services in Guix.
>
> I would be eager to participate to some sort of guix system reconfigure
> --user-services that would allow people to write and share their
> unpriviledged services :).

Btw, beside user-specific services, we also already discussed
user-specific aliases for the `guix ...` commands. So now, there are at
least two things a user-specific configuration file could contain. :)

One, the system.scm would contain

 (operating-system
; ...
(services
; ...
))

And secondly, each user could have a user.scm e.g. like

(user-configuration
; ...
(aliases
'(
("sysrec" "system reconfigure")
("pl" "pull")
; ...
))
(services
(emacs-daemon-service)
(dzen-service)
; ...
))

or similar :)

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: Git-style aliases in Guix?

[Mekeor Melire]

What I really mean to say is, that it'd be a shame, if Guix had a
configuration file like Git which uses this syntax:

[user]
name = example
email = example@example.example
[alias]
i = init
z = stash
s = status

I mean, all the files Guix reads are written in Scheme (config.scm,
manifest.scm, any package.scm). So, how could it work that Guix was
configured in Scheme?

Is there any way we could make config.scm include a similar data-type as
`operating-system`, maybe called `guix-configuration` or whatever, which
has a field called `aliases`?

I mean, implementing aliases isn't per-se difficult. But I'd love to
have a much broader approach to configure Guix (and Guix' CLI).


Ludovic Courtès <l...@gnu.org> writes:

> Mekeor Melire <mekeor.mel...@gmail.com> skribis:
>
>> So, `operating-system` let's you declare an operating system. What if
>> there was a Scheme function called `guix` or so which allowed you to
>> configure Guix itself?
>>
>> Then, defining Guix aliases could look as follows; maybe saved in a file
>> called guix.scm:
>>
>>   (guix
>> (aliases '(
>>   ("p" . "package")
>>   ("s" . "package -s")
>>   ("m" . "package -m"
>>
>> And similar to `operating-system`, there would be many other
>> configuration fields...
>
> I think that would be pretty cool.
>
> There’ve been discussions in the past about adding aliases:
>
>   https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00325.html
>
> Ludo’.


--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

Re: [PATCH] gnu: Add dzen.

[Mekeor Melire]

>From d235a347a21d50902d42f161a6c840516eff9d42 Mon Sep 17 00:00:00 2001
From: Mekeor Melire <mekeor.mel...@gmail.com>
Date: Fri, 3 Mar 2017 00:22:47 +0100
Subject: [PATCH] gnu: Add dzen.

* gnu/packages/xdisorg.scm (dzen): New variable.
---
 gnu/packages/xdisorg.scm | 52 
 1 file changed, 52 insertions(+)

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 3d69661ba..e729bcac2 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -16,6 +16,7 @@
 ;;; Copyright © 2016 Alex Kost <alez...@gmail.com>
 ;;; Copyright © 2016 Marius Bakke <mba...@fastmail.com>
 ;;; Copyright © 2016 Petter <pet...@mykolab.ch>
+;;; Copyright © 2017 Mekeor Melire <mekeor.mel...@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -36,6 +37,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
@@ -1023,6 +1025,56 @@ border, and background.  It also supports multihead 
setups, customized mouse
 actions, a built-in clock, a battery monitor and a system tray.")
 (license license:gpl2)))
 
+(define-public dzen
+  (let ((commit "488ab66019f475e35e067646621827c18a879ba1")
+(revision "1"))
+(package
+ (name "dzen")
+ (version (string-append "0.9.5-" ; Taken from `config.mk`.
+ revision "." (string-take commit 7)))
+ (source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/robm/dzen.git;)
+(commit commit)))
+  (file-name (string-append name "-" version))
+  (sha256
+   (base32
+"0y47d6ii87vf4a517gi4fh0yl06f8b085sra77immnsasbq9pxnw"
+ (build-system gnu-build-system)
+ (arguments
+  `(#:tests? #f ; No test suite.
+#:make-flags ; Replacement for `config.mk`.
+(list
+ (string-append "VERSION = " ,version)
+ (string-append "PREFIX = " %output)
+ "MANPREFIX = ${PREFIX}/share/man"
+ "INCS = -I."
+ "LIBS = -lc -lX11 -lXinerama -lXpm $(shell pkg-config --libs xft)"
+ "CFLAGS = -Wall -Os ${INCS} -DVERSION=\\\"${VERSION}\\\"\
+ -DDZEN_XINERAMA -DDZEN_XPM -DDZEN_XFT $(shell pkg-config --cflags 
xft)"
+ "LDFLAGS = ${LIBS}"
+ "CC = gcc"
+ "LD = ${CC}")
+#:phases
+(modify-phases %standard-phases
+  (delete 'configure) ; No configuration script.
+  ;; Use own make-flags instead of `config.mk`.
+  (add-before 'build 'dont-include-config-mk
+(lambda* (#:key outputs #:allow-other-keys)
+  (substitute* "Makefile" (("include config.mk") "")))
+ (inputs
+  `(("libx11"  ,libx11)
+("libxft"  ,libxft)
+("libxpm"  ,libxpm)
+("libxinerama" ,libxinerama)))
+ (native-inputs `(("pkg-config" ,pkg-config)))
+ (synopsis "General purpose messaging, notification and menuing program 
for X11")
+ (description "Dzen is a general purpose messaging, notification and 
menuing
+program for X11.  It was designed to be fast, tiny and scriptable in any 
language.")
+ (home-page "https://github.com/robm/dzen;)
+ (license license:expat
+
 (define-public xcb-util-xrm
   (package
 (name "xcb-util-xrm")
-- 
2.11.0

Re: Git-style aliases in Guix?

[Mekeor Melire]

John Darrington <j...@darrington.wattle.id.au> writes:

> On Mon, Feb 27, 2017 at 09:30:07AM +0100, Mekeor Melire wrote:
>
>  John Darrington <j...@darrington.wattle.id.au> writes:
>
>  > On Sun, Feb 26, 2017 at 10:15:10PM +0100, Mekeor Melire wrote:
>  >
>  >  Concerning how to implement this alias feature within Guix, I'd 
> first
>  >  like to pose a much broader question. So, on GuixSD you have a
>  >  configuration, written in Scheme, for your operating system. 
> Couldn't we
>  >  make Guix have a scheme-configuration file for itself, as well?
>  >
>  > We do.  guix/config.scm
>
>  How can you configure Guix itself in your config.scm? I'm only aware of
>  the operating-system declaration which is used to configure the OS, not
>  Guix itself.
>
> What kind of configuration had you in mind?

So, `operating-system` let's you declare an operating system. What if
there was a Scheme function called `guix` or so which allowed you to
configure Guix itself?

Then, defining Guix aliases could look as follows; maybe saved in a file
called guix.scm:

  (guix
(aliases '(
  ("p" . "package")
  ("s" . "package -s")
  ("m" . "package -m"

And similar to `operating-system`, there would be many other
configuration fields...

Re: Git-style aliases in Guix?

[Mekeor Melire]

John Darrington <j...@darrington.wattle.id.au> writes:

> On Sun, Feb 26, 2017 at 10:15:10PM +0100, Mekeor Melire wrote:
>
>  Concerning how to implement this alias feature within Guix, I'd first
>  like to pose a much broader question. So, on GuixSD you have a
>  configuration, written in Scheme, for your operating system. Couldn't we
>  make Guix have a scheme-configuration file for itself, as well?
>  
> We do.  guix/config.scm

How can you configure Guix itself in your config.scm? I'm only aware of
the operating-system declaration which is used to configure the OS, not
Guix itself.

Re: Git-style aliases in Guix?

[Mekeor Melire]

I'd also like to have some Guix aliases. In Git, you can define aliases
like so:

 # define new alias
 $ git config --global alias.i init
 # use new alias
 $ git i

Personally, I'd prefer to type `guix p -i` for `guix package -i`.
Anyway.


Concerning how to implement this alias feature within Guix, I'd first
like to pose a much broader question. So, on GuixSD you have a
configuration, written in Scheme, for your operating system. Couldn't we
make Guix have a scheme-configuration file for itself, as well?


Alex Griffin  writes:

> I think it would be cool and useful if Guix had some kind of config file
> where users could define new commands or aliases, as in git. I'm sure
> many people here already have their own helper code to work witk Guix,
> whether that's in shell scripts, bashrc, guile, elisp, etc. And it would
> make it easier to experiment with changing the command line syntax
> without committing to any change too soon.
>
> I've attached my own Guix wrapper function to show some use cases, like:
>
> # New features
> * automatically invoke `./pre-inst-env` when ~/.config/guix/latest
> points to a git repo
> * `guix make` builds Guix in your git checkout directory
> * `guix clean` cleans out your Guix git checkout
> * `guix visit ` opens a package's homepage in a browser
> * `guix ls` lists the files in a Guix package (must be present or built
> on your machine)
>
> # Convenience Commands
> * `guix search` wraps `guix package -s` with a recutils template
> * `guix manifest` -> guix package --manifest=~/.config/guix/profile.scm
> * `guix reconfigure` -> sudo guix system reconfigure
> ~/.config/guix/system.scm
> * `guix repl` just invokes `./pre-inst-env guile`, but it should
> probably also load some Guix modules.
>
> # Simple Aliases
> * `guix add` or `guix install` -> guix package --install
> * `guix env` -> guix environment
> * `guix try` -> guix environment --ad-hoc
> * `guix profile` -> guix package
> * `guix show` or `guix info` -> guix package --show=
> * `guix remove` or `guix uninstall` -> guix package --remove
>
> What does everyone think? If you like the idea, what would the
> implementation/config file look like?


--

[PATCH] gnu: Add dzen.

[Mekeor Melire]

From 33d25348eb60372120e95e3bb5afd19bdad64795 Mon Sep 17 00:00:00 2001
From: Mekeor Melire <mekeor.mel...@gmail.com>
Date: Tue, 21 Feb 2017 00:02:25 +0100
Subject: [PATCH] gnu: Add dzen.

* gnu/packages/xdisorg.scm (dzen): New variable.
---
 gnu/packages/xdisorg.scm | 53 
 1 file changed, 53 insertions(+)

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 510684a6c..5be976b36 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -16,6 +16,7 @@
 ;;; Copyright © 2016 Alex Kost <alez...@gmail.com>
 ;;; Copyright © 2016 Marius Bakke <mba...@fastmail.com>
 ;;; Copyright © 2016 Petter <pet...@mykolab.ch>
+;;; Copyright © 2017 Mekeor Melire <mekeor.mel...@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -36,6 +37,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
@@ -1030,6 +1032,57 @@ border, and background.  It also supports multihead 
setups, customized mouse
 actions, a built-in clock, a battery monitor and a system tray.")
 (license license:gpl2)))
 
+(define-public dzen
+  (let
+  ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
+   (revision "1"))
+(package
+ (name "dzen")
+ (version (string-append
+   "0.9.5-" ; Taken from `config.mk`.
+   revision "-" (string-take commit 7)))
+ (source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/robm/dzen.git;)
+(commit commit)))
+  (file-name (string-append name "-" version))
+  (sha256 (base32
+   
"0y47d6ii87vf4a517gi4fh0yl06f8b085sra77immnsasbq9pxnw"
+ (build-system gnu-build-system)
+ (arguments
+  `(#:tests? #f ; No test suite.
+#:make-flags ; Replacement for `config.mk`.
+(list
+ (string-append "VERSION = " ,version)
+ (string-append "PREFIX = " %output)
+ "MANPREFIX = ${PREFIX}/share/man"
+ "INCS = -I."
+ "LIBS = -lc -lX11 -lXinerama -lXpm $(shell pkg-config --libs xft)"
+ "CFLAGS = -Wall -Os ${INCS} -DVERSION=\\\"${VERSION}\\\"\
+ -DDZEN_XINERAMA -DDZEN_XPM -DDZEN_XFT $(shell pkg-config --cflags 
xft)"
+ "LDFLAGS = ${LIBS}"
+ "CC = gcc"
+ "LD = ${CC}")
+#:phases
+(modify-phases %standard-phases
+  (delete 'configure) ; No configuration script.
+  ;; Use own make-flags instead of `config.mk`.
+  (add-before 'build 'dont-include-config-mk
+(lambda* (#:key outputs #:allow-other-keys)
+  (substitute* "Makefile" (("include config.mk") "")))
+ (inputs
+  `(("libx11"  ,libx11)
+("libxft"  ,libxft)
+("libxpm"  ,libxpm)
+("libxinerama" ,libxinerama)))
+ (native-inputs `(("pkg-config" ,pkg-config)))
+ (synopsis "General purpose messaging, notification and menuing program 
for X11")
+ (description "Dzen is a general purpose messaging, notification and 
menuing
+program for X11.  It was designed to be fast, tiny and scriptable in any 
language.")
+ (home-page "https://github.com/robm/dzen;)
+ (license license:expat
+
 (define-public xcb-util-xrm
   (package
 (name "xcb-util-xrm")
-- 
2.11.0

[PATCH] gnu: Add dzen.

[Mekeor Melire]

From 04f94c306f99a7bacc96b60ed60e9bb83a9cf767 Mon Sep 17 00:00:00 2001
From: Mekeor Melire <mekeor.mel...@gmail.com>
Date: Tue, 14 Feb 2017 00:21:08 +0100
Subject: [PATCH] gnu: Add dzen.

* gnu/packages/xdisorg.scm (dzen): New variable.
---
 gnu/packages/xdisorg.scm | 48 
 1 file changed, 48 insertions(+)

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 510684a6c..7835c3660 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -16,6 +16,7 @@
 ;;; Copyright © 2016 Alex Kost <alez...@gmail.com>
 ;;; Copyright © 2016 Marius Bakke <mba...@fastmail.com>
 ;;; Copyright © 2016 Petter <pet...@mykolab.ch>
+;;; Copyright © 2017 Mekeor Melire <mekeor.mel...@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -36,6 +37,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
@@ -1030,6 +1032,52 @@ border, and background.  It also supports multihead 
setups, customized mouse
 actions, a built-in clock, a battery monitor and a system tray.")
 (license license:gpl2)))
 
+(define-public dzen (package
+  (name "dzen")
+  (version "0.9.5")
+  (synopsis "General purpose messaging, notification and menuing program for 
X11")
+  (description "Dzen is a general purpose messaging, notification and menuing
+program for X11.  It was designed to be fast, tiny and scriptable in any 
language.")
+  (home-page "https://github.com/robm/dzen;)
+  (license license:x11)
+  (source (origin
+  (method git-fetch)
+  (uri (git-reference
+  (url "https://github.com/robm/dzen.git;)
+  (commit "488ab66019f475e35e067646621827c18a879ba1")))
+  (file-name (string-append name "-" version))
+  (sha256 (base32
+  "0y47d6ii87vf4a517gi4fh0yl06f8b085sra77immnsasbq9pxnw"
+  (build-system gnu-build-system)
+  (native-inputs `(("pkg-config" ,pkg-config)))
+  (inputs `(
+  ("libx11"  ,libx11)
+  ("libxft"  ,libxft)
+  ("libxpm"  ,libxpm)
+  ("libxinerama" ,libxinerama)))
+  (arguments `(
+  #:tests? #f
+  ; use our make-flags instead of `config.mk`
+  #:make-flags (list
+  (string-append "VERSION = " ,version)
+  (string-append "PREFIX = " %output)
+  "MANPREFIX = ${PREFIX}/share/man"
+  "INCS = -I."
+  "LIBS = -lc -lX11 -lXinerama -lXpm $(shell pkg-config --libs xft)"
+  "CFLAGS = -Wall -Os ${INCS} -DVERSION=\\\"${VERSION}\\\"\
+  -DDZEN_XINERAMA -DDZEN_XPM -DDZEN_XFT $(shell pkg-config 
--cflags xft)"
+  "LDFLAGS = ${LIBS}"
+  "CC = gcc"
+  "LD = ${CC}")
+  #:phases (modify-phases
+  %standard-phases
+  ; do not `./configure`
+  (delete 'configure)
+  ; do not `include config.mk` in `Makefile`
+  (add-before 'build 'dont-include-config-mk
+  (lambda* (#:key outputs #:allow-other-keys)
+  (substitute* "Makefile" (("include config.mk") "")
+
 (define-public xcb-util-xrm
   (package
 (name "xcb-util-xrm")
-- 
2.11.0

[PATCH] xmonad 0.12

[Mekeor Melire]

commit d0e39d8316f6c935a8710482db617253c8824e6c
Author: Mekeor Melire <mekeor.mel...@gmail.com>
Date:   Sat Jan 21 21:08:11 2017 +0100

gnu: xmonad: Update to version 0.12.

* gnu/packages/wm.scm (xmonad): Update to 0.12.
* gnu/packages/wm.scm (ghc-xmonad-contrib): Update to 0.12.
* gnu/packages/haskell.scm (ghc-setlocale): Added 1.0.0.4 which was required
  by xmonad 0.12.

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index f28009f17..d0651b963 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -1607,6 +1607,23 @@ UTF8 without truncation.")
 environment variables.")
 (license license:expat)))
 
+(define-public ghc-setlocale
+  (package
+(name "ghc-setlocale")
+(version "1.0.0.4")
+(source (origin
+(method url-fetch)
+(uri (string-append
+"https://hackage.haskell.org/package/setlocale-;
+ version "/setlocale-" version ".tar.gz"))
+(sha256 (base32
+"1sd73zgpijr9xjdj5p562cmlcxmx5iff5k8xh9b6rpcgrgnnlf9j"
+(build-system haskell-build-system)
+(home-page "https://hackage.haskell.org/package/setlocale;)
+(synopsis "Haskell bindings to setlocale")
+(description "Haskell bindings to setlocale")
+(license license:bsd-3)))
+
 (define-public ghc-x11
   (package
 (name "ghc-x11")
diff --git a/gnu/packages/wm.scm b/gnu/packages/wm.scm
index 5b761e81b..f16bf151e 100644
--- a/gnu/packages/wm.scm
+++ b/gnu/packages/wm.scm
@@ -320,30 +320,22 @@ prompt.")
 (define-public xmonad
   (package
 (name "xmonad")
-(version "0.11.1")
+(version "0.12")
 (synopsis "Tiling window manager")
 (source (origin
-  (method url-fetch)
-  (uri (string-append "mirror://hackage/package/xmonad/"
-  name "-" version ".tar.gz"))
-  (sha256
-   (base32
-"1pfjssamiwpwjp1qqkm9m9p9s35pv381m0cwg6jxg0ppglibzq1r"))
-  (modules '((guix build utils)))
-  (snippet
-   ;; Here we update the constraints on the utf8-string package in
-   ;; the Cabal file.  We allow a newer version which is compatible
-   ;; with GHC 7.10.2.  The same change is applied on Hackage.  See
-   ;; 
<https://hackage.haskell.org/package/xmonad-0.11.1/revisions/>.
-   '(substitute* "xmonad.cabal"
-  (("utf8-string >= 0.3 && < 0.4")
-   "utf8-string >= 0.3 && < 1.1")
+(method url-fetch)
+(uri (string-append
+"mirror://hackage/package/xmonad/xmonad-" version ".tar.gz"))
+(sha256 (base32
+"1mzx3p17ppgmi30q3phaj58x6kxn73pbbkn9v9gzgmd8skdlkxp8"
 (build-system haskell-build-system)
 (inputs
- `(("ghc-mtl" ,ghc-mtl)
-   ("ghc-utf8-string" ,ghc-utf8-string)
-   ("ghc-extensible-exceptions" ,ghc-extensible-exceptions)
-   ("ghc-x11" ,ghc-x11)))
+ `(("ghc-extensible-exceptions" ,ghc-extensible-exceptions)
+   ("ghc-mtl"   ,ghc-mtl)
+   ("ghc-quickcheck",ghc-quickcheck)
+   ("ghc-setlocale" ,ghc-setlocale)
+   ("ghc-utf8-string"   ,ghc-utf8-string)
+   ("ghc-x11"   ,ghc-x11)))
 (arguments
  `(#:phases
(modify-phases %standard-phases
@@ -376,15 +368,15 @@ tiled on several screens.")
 (define-public ghc-xmonad-contrib
   (package
 (name "ghc-xmonad-contrib")
-(version "0.11.4")
+(version "0.12")
 (source
  (origin
(method url-fetch)
-   (uri (string-append "mirror://hackage/package/xmonad-contrib/"
-   "xmonad-contrib-" version ".tar.gz"))
+   (uri (string-append
+   "mirror://hackage/package/xmonad-contrib/xmonad-contrib-" version 
".tar.gz"))
(sha256
 (base32
- "1g5cw9vvnfbiyi599fngk02zlmdhrf82x0bndhypkn6kybab6yd3"
+ "04gk449dxwmimmb6y2d2hvvmv91r91xlj879qzlyq0mcf723278k"
 (build-system haskell-build-system)
 (propagated-inputs
  `(("ghc-mtl" ,ghc-mtl)