Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

[Ludovic Courtès]

Daniel Pimentel  skribis:

> I added 'export LC_ALL="C"' in my ~.bashrc.
>
> I'll to do upgrade and report it.

With LC_ALL=C, one sidesteps the problem.  For real testing, you need to
use LC_ALL=pt_BR.utf8 or something like that.

Ludo’.

Re: [PATCH] gnu: qt-4: Disable webkit build.

[Ludovic Courtès]

Andreas Enge  skribis:

> the attached patch removes the webkit module from qt-4, in the same spirit
> as removing chromium from qt-5 some time ago. My main motivation was to work
> around the build failure on armhf; the patched qt-4 now builds there.

LGTM.  I think we should also rm -rf the code in a snippet.

Besides, would our WebKit be picked up if we added it as an input?

Please keep  updated and mention it in the
commit log.

Thanks!

Ludo’.

Re: [PATCH 3/3] gnu: rtorrent: Update to 0.9.6.

[Ludovic Courtès]

Alex Kost  skribis:

> From 5865f01649e401fd135ff55fe9964aa81f64f5f9 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sat, 3 Oct 2015 22:23:40 +0300
> Subject: [PATCH 3/3] gnu: rtorrent: Update to 0.9.6.
>
> * gnu/packages/bittorrent.scm (rtorrent): Update to 0.9.6.
>   [source]: Use new URL.

I haven’t built it, but LGTM.

Thanks!

Ludo’.

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> So with current ‘core-updates’, someone on a “foreign distro” needs to
> do:
>
>   guix package -i glibc-locales
>   export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22
>
> Note the extra “/2.22”, which comes from commit f2d7bbb.  This is a bit
> of an annoyance for end users, but the point is that eventually this
> would allow us to recommend things like:
>
>   export 
> GUIX_LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23
>
> The only question is whether having the “/2.22” prefix by default is a
> good idea.  Opinions?

I think the "/2.22" suffix will be needed to prevent another awkward
transition the next time glibc makes an incompatible change to their
locales.  Suppose that 2.23 makes another incompatible change.  After
that, many Guix systems will have a mixture of software linked with
glibc-2.22 and glibc-2.23.

One question: when this happens, do we have a mechanism for
automatically setting GUIX_LOCPATH to:

  $HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23

or will that have to be done manually?

 Mark

Re: [PATCH 0/2] Avoiding incompatible locale data in LOCPATH

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> After a lot more thought, I changed my mind.
>
> I realized that with the patch at
> , it’s OK to
> have, say,
>
>   
> LOCPATH=$HOME/.guix-profile/lib/locale/2.22:$HOME/.guix-profile/lib/locale/2.23
>
> That way, programs will pick locale data that is compatible; so a 2.23
> program might pick most of its locale data from the /2.22 directory (if
> they are compatible), and some of them from /2.23 (if the format has
> changed.)

I'm a bit uncomfortable with this.  A few questions:

* Will your glibc patch reliably ensure that no functionality is lost
  because of picking up the wrong version of locales?

* Do we have a mechanism for automatically setting LOCPATH (or
  GUIX_LOCPATH) to include all of the available locale versioned
  subdirectories?

  Mark

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>
>> Alex Kost  skribis:
>>
>>> * emacs/guix-devel.el (guix-devel-setup-repl): Use (guix packages) module.
>>>   (guix-devel-download-package-source): New command.
>>>   (guix-devel-keys-map): Add key binding for it.
>>> * doc/emacs.texi (Emacs Development): Document it.
>>
>> [...]
>>
>>> +(defun guix-devel-download-package-source ()
>>> +  "Download the source of the current package.
>>> +Use this function to compute SHA256 hash of the package source."
>>> +  (interactive)
>>> +  (guix-devel-with-definition def
>>> +(guix-devel-use-modules "(guix scripts download)")
>>> +(when (or (not guix-operation-confirm)
>>> +  (y-or-n-p (format "Download '%s' package source?" def)))
>>> +  (guix-geiser-eval-in-repl
>>> +   (format "(guix-download (origin-uri (package-source %s)))"
>>> +   def)
>>
>> What about instead building the ‘package-source-derivation’ of the
>> package?  That way, that would do the exact same thing as ‘guix build
>> -S’ and would work not only with ‘url-fetch’ but also with the other
>> things.
>>
>> WDYT?
>
> The goal of this command is to display a hash.

So this would be something one would use as they write a package
definition, to fill in the ‘sha256’ field, right?

In that case, I would suggest something based on the URL at point rather
than the origin at point.

However, if this is “too convenient”, I’m afraid this would give an
incentive to not check OpenPGP signatures when they are available.

> At first I also thought about building a package source and then to
> calculate the hash of the store file, but this way will lead to the
> wrong hashes for "snippet"-ed origins.  Or do I miss anything?

Well, I think bindings for ‘package-source-derivation’ would also be
useful, but IIUC this is not what you had in mind.

Thanks,
Ludo’.

Re: [PATCH 2/3] gnu: libtorrent: Update to 0.13.6.

[Ludovic Courtès]

Alex Kost  skribis:

> From 0fcf4b7368ce6f145a1cd45bd4b675145b5da4dc Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sat, 3 Oct 2015 22:21:33 +0300
> Subject: [PATCH 2/3] gnu: libtorrent: Update to 0.13.6.
>
> * gnu/packages/bittorrent.scm (libtorrent): Update to 0.13.6.
>   [source]: Use new URL.
>   [native-inputs]: Uncomment "cppunit" (for tests).
>   [argument]: Remove (to enable tests).

LGTM!

Ludo'.

Re: [PATCH 1/3] gnu: libtorrent, rtorrent: Update home pages.

[Ludovic Courtès]

Alex Kost  skribis:

> From 3272d2f71e02a3b8a4ad1e664a5636293200b923 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Sat, 3 Oct 2015 22:16:27 +0300
> Subject: [PATCH 1/3] gnu: libtorrent, rtorrent: Update home pages.
>
> * gnu/packages/bittorrent.scm (libtorrent): Update 'home-page'.
>   (rtorrent): Likewise.

Sure!

Ludo'.

Re: [PATCH 1/3] gnu: libtorrent, rtorrent: Update home pages.

[Alex Kost]

Ludovic Courtès (2015-10-04 19:57 +0300) wrote:

> Alex Kost  skribis:
>
>> From 3272d2f71e02a3b8a4ad1e664a5636293200b923 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Sat, 3 Oct 2015 22:16:27 +0300
>> Subject: [PATCH 1/3] gnu: libtorrent, rtorrent: Update home pages.
>>
>> * gnu/packages/bittorrent.scm (libtorrent): Update 'home-page'.
>>   (rtorrent): Likewise.
>
> Sure!

Oof, I pushed these patches (as I had the response from Andreas) and
just after that I found your replies.  Sorry for the rush and thanks for
replying!

-- 
Alex

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

[Alex Kost]

Ludovic Courtès (2015-10-04 19:57 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-10-03 23:35 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 * emacs/guix-devel.el (guix-devel-setup-repl): Use (guix packages) module.
   (guix-devel-download-package-source): New command.
   (guix-devel-keys-map): Add key binding for it.
 * doc/emacs.texi (Emacs Development): Document it.
>>>
>>> [...]
>>>
 +(defun guix-devel-download-package-source ()
 +  "Download the source of the current package.
 +Use this function to compute SHA256 hash of the package source."
 +  (interactive)
 +  (guix-devel-with-definition def
 +(guix-devel-use-modules "(guix scripts download)")
 +(when (or (not guix-operation-confirm)
 +  (y-or-n-p (format "Download '%s' package source?" def)))
 +  (guix-geiser-eval-in-repl
 +   (format "(guix-download (origin-uri (package-source %s)))"
 +   def)
>>>
>>> What about instead building the ‘package-source-derivation’ of the
>>> package?  That way, that would do the exact same thing as ‘guix build
>>> -S’ and would work not only with ‘url-fetch’ but also with the other
>>> things.
>>>
>>> WDYT?
>>
>> The goal of this command is to display a hash.
>
> So this would be something one would use as they write a package
> definition, to fill in the ‘sha256’ field, right?

Exactly.  For example, here is how I update a package using Geiser:

- I modify its 'version' field,
- "C-M-x" to reevaluate the package definition,
- "C-c . s" to download the new source and show its hash,
- replace the old hash with the new one,
- and finally "C-c . b" to build the new version of package.

> In that case, I would suggest something based on the URL at point rather
> than the origin at point.

It's neither URL at point, nor origin at point: it's like "C-c . b" but
to download the source of the current package definition instead of
building it.

Also I don't understand how it can be based on the URL at point as
instead of the full URL, we have something like this:

  (uri (string-append "http://.../foo-; version ".tar.xz"))

So currently to use "guix download", at first you need to manually
construct the full URL.  I find this inconvenient, that's why I want to
have a command to download a source of the current package and to
display its hash.

> However, if this is “too convenient”, I’m afraid this would give an
> incentive to not check OpenPGP signatures when they are available.

Sorry, I have no idea what it means :-(

>> At first I also thought about building a package source and then to
>> calculate the hash of the store file, but this way will lead to the
>> wrong hashes for "snippet"-ed origins.  Or do I miss anything?
>
> Well, I think bindings for ‘package-source-derivation’ would also be
> useful, but IIUC this is not what you had in mind.

If you mean to make a command to build the current package source, it
can be done, although I don't see how it can be useful.

-- 
Alex

Re: No sound in games using sdl-mixer

[Alex Kost]

Ludovic Courtès (2015-10-04 15:45 +0300) wrote:

> FWIW I just tried ExtremeTuxRacer and it works out of the box for me (on
> GuixSD).
>
> I do use PulseAudio though.  To allow ETR’s sound output to mix with
> other things that may be playing sound already, I have this in my
> ~/.asoundrc:
>
>
> pcm.!default {
> type pulse
> }
>
> Should we add it to the account skeletons?

Hm, wouldn't this break a sound somehow if a user doesn't have
pulseaudio installed?

BTW, I have never had problems with simultaneous sound from different
programs with ALSA.

-- 
Alex

Re: No sound in games using sdl-mixer

[Ricardo Wurmus]

Ludovic Courtès  writes:

> FWIW I just tried ExtremeTuxRacer and it works out of the box for me (on
> GuixSD).
>
> I do use PulseAudio though.  To allow ETR’s sound output to mix with
> other things that may be playing sound already, I have this in my
> ~/.asoundrc:
>
> --8<---cut here---start->8---
> pcm.!default {
> type pulse
> }
> --8<---cut here---end--->8---
>
> Should we add it to the account skeletons?

I don’t think that’s a good idea.  This means that the ALSA library will
always try to output to the “pulse” backend, which may not exist.  For
example, I do not use PulseAudio, so I do not have the “pulse” backend,
so this ~/.asoundrc setting would not work in my case.  (I don’t know if
it would do harm, to be fair.)

Is there a better way to make sdl-mixer output to the ALSA backend by
default?  I think outputing to ALSA is a safe default choice, as most
applications do not directly output to PulseAudio but to ALSA.

~~ Ricardo

[PATCH 1/2] gnu: Add physfs.

[Alex Kost]

Is there a suitable module for this library?

>From beec892399a21b0436a2b971881e5cc15545bec2 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 4 Oct 2015 19:49:24 +0300
Subject: [PATCH 1/2] gnu: Add physfs.

* gnu/packages/physfs.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add it.
---
 gnu-system.am   |  1 +
 gnu/packages/physfs.scm | 58 +
 2 files changed, 59 insertions(+)
 create mode 100644 gnu/packages/physfs.scm

diff --git a/gnu-system.am b/gnu-system.am
index 8eb268f..386d3f4 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -253,6 +253,7 @@ GNU_SYSTEM_MODULES =\
   gnu/packages/pem.scm\
   gnu/packages/perl.scm\
   gnu/packages/photo.scm			\
+  gnu/packages/physfs.scm			\
   gnu/packages/pkg-config.scm			\
   gnu/packages/plotutils.scm			\
   gnu/packages/polkit.scm			\
diff --git a/gnu/packages/physfs.scm b/gnu/packages/physfs.scm
new file mode 100644
index 000..7fc993d
--- /dev/null
+++ b/gnu/packages/physfs.scm
@@ -0,0 +1,58 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Alex Kost 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see .
+
+(define-module (gnu packages physfs)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system cmake)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (gnu packages compression)
+  #:use-module (gnu packages doxygen))
+
+(define-public physfs
+  (package
+(name "physfs")
+(version "2.0.3")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://icculus.org/physfs/downloads/physfs-;
+version ".tar.bz2"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"0sbbyqzqhyf0g68fcvvv20n3928j0x6ik1njmhn1yigvq2bj11na"
+(build-system cmake-build-system)
+(arguments
+ '(#:tests? #f)); no check target
+(inputs
+ `(("zlib" ,zlib)))
+(native-inputs
+ `(("doxygen" ,doxygen)))
+(home-page "http://icculus.org/physfs;)
+(synopsis "Filesystem abstraction library")
+(description
+ "PhysicsFS is a library to provide abstract access to various archives.
+It is intended for use in video games.  For security, no file writing done
+through the PhysicsFS API can leave a defined @emph{write directory}.  For
+file reading, a @emph{search path} with archives and directories is defined,
+and it becomes a single, transparent hierarchical file system.  So archive
+files can be accessed in the same way as you access files directly on a disk,
+and it makes it easy to ship a new archive that will override a previous
+archive on a per-file basis.")
+(license license:zlib)))
-- 
2.5.3

[PATCH 2/2] gnu: Add manaplus.

[Alex Kost]

I don't know if there is a better workaround for the SDL headers, but
this problem is rather common: there is a workaround in 'abbaye' and a
special patch for 'pingus'.

The problem is: the source code has lines like this:

  #include 

but the headers of all SDL packages are placed in “include/SDL/”
subdirectories.  And an upstream often doesn't use "pkg-config" for
every SDL package to define CFLAGS and assumes that all SDL headers are
placed in one directory.  So we have to invent workarounds for such
packages.

I just mention this problem here, perhaps someone will come up with a
general solution.

>From 220a23aad452663f8262935cfa09fe5321e33602 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Sun, 4 Oct 2015 20:34:48 +0300
Subject: [PATCH 2/2] gnu: Add manaplus.

* gnu/packages/games.scm (manaplus): New variable.
---
 gnu/packages/games.scm | 58 ++
 1 file changed, 58 insertions(+)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 7eb65bb..c080e61 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -10,6 +10,7 @@
 ;;; Copyright © 2015 Andreas Enge 
 ;;; Copyright © 2015 David Hashe 
 ;;; Copyright © 2015 Christopher Allan Webber 
+;;; Copyright © 2015 Alex Kost 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -46,6 +47,7 @@
   #:use-module (gnu packages libunwind)
   #:use-module (gnu packages image)
   #:use-module (gnu packages ncurses)
+  #:use-module (gnu packages physfs)
   #:use-module (gnu packages python)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages xorg)
@@ -1047,3 +1049,59 @@ on the screen and keyboard to display letters.")
 ;; Most files under gpl2+ or gpl3+, but eat.wav under gpl3
 (license license:gpl3)))
 
+(define-public manaplus
+  (package
+(name "manaplus")
+(version "1.5.9.26")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://repo.manaplus.org/manaplus/download/;
+version "/manaplus-" version ".tar.xz"))
+  (sha256
+   (base32
+"070ms1cv7q88284pqh66lfhacckgv7m9s8z9009k2laypibx7vs6"
+(build-system gnu-build-system)
+(arguments
+ '(#:modules ((ice-9 match)
+  (ice-9 regex)
+  (srfi srfi-1)
+  (guix build gnu-build-system)
+  (guix build utils))
+   ;; The package relies on "sdl-config" to find SDL header files,
+   ;; which adds "include/SDL" for 'sdl' itself.  We need to include
+   ;; such directories for all sdl packages.
+   #:configure-flags
+   (let* ((sdl-rx   (make-regexp "\\`sdl"))
+  (includes (filter-map (match-lambda
+  ((name . dir)
+   (and (regexp-exec sdl-rx name)
+(string-append
+ "-I" dir "/include/SDL"
+%build-inputs)))
+ (list (format #f "CPPFLAGS=~{~a ~}" includes)
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
+(inputs
+ `(("glu" ,glu)
+   ("curl" ,curl)
+   ("libxml2" ,libxml2)
+   ("mesa" ,mesa)
+   ("physfs" ,physfs)
+   ("sdl" ,sdl)
+   ("sdl-gfx" ,sdl-gfx)
+   ("sdl-image" ,sdl-image)
+   ("sdl-mixer" ,sdl-mixer)
+   ("sdl-net" ,sdl-net)
+   ("sdl-ttf" ,sdl-ttf)))
+(home-page "http://manaplus.org;)
+(synopsis "Client for 'The Mana World' and similar games")
+(description
+ "ManaPlus is a 2D MMORPG client for game servers.  It is the only
+fully supported client for @uref{http://www.themanaworld.org, The mana
+world}, @uref{http://evolonline.org, Evol Online} and
+@uref{http://landoffire.org, Land of fire}.")
+;; "src/debug/*" and "src/sdl2gfx/*" are under Zlib.
+;; "data/themes/{golden-delicious,jewelry}/*" are under CC-BY-SA.
+;; The rest is under GPL2+.
+(license (list license:gpl2+ license:zlib license:cc-by-sa4.0
-- 
2.5.3