Re: [PATCH] Gracefully handle incompatible locale data

[Carlos O'Donell]

On 10/27/2015 11:30 AM, Samuel Thibault wrote:
> Hello,
> 
> Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit :
>>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof 
>> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
>>
>> This patch changes such conditions to return EINVAL instead of aborting.
> 
> Just like it does for the __glibc_unlikely (idx > (size_t)
> newdata->filesize) test above, so it doesn't actually introduce any new
> error condition.
> 
> I thus commited the change, thanks!
> 
> Samuel
> 

Thanks Samuel!

c.

Re: [PATCH] Gracefully handle incompatible locale data

[Carlos O'Donell]

On 10/13/2015 10:45 AM, Ludovic Courtès wrote:
>> - What does localedef --list-archive return?
>>
>>   - The new LC_COLLATE format will make it's way into the binary locale 
>> archive
>> and that means glibc can't read the locale-archive? Does it fail? exit 
>> code?
> 
> The patch does not change how locale archives are handled.
> 
> I think we’re confusing locale archive and locale data; or am I simply
> missing something?  :-)

Your patch is OK.

Notes:

(1) Do we return NULL and EINVAL? Yes.

Loading locale data from the locale archive uses _nl_load_locale_from_archive.
The function _nl_load_locale_from_archive calls _nl_intern_locale_data
which can trigger the assert on invalid type sizes.

~~~ locale/loadarchive.c ~~~
134 _nl_load_locale_from_archive (int category, const char **namep)
...
478 lia->data[cnt] = _nl_intern_locale_data (cnt,
479  results[cnt].addr,
480  results[cnt].len);
~~~

Which seems like it can trigger the assertion when loading the larger
LC_COLLATE data from the archive. Now we return NULL, ignore the failed load,
and potentially return NULL again since `lia->data[category]` is now NULL.

This means `_nl_find_locale` returns NULL, and then functions like `setlocale`
appear to return NULL to indicate no data was loaded with errno set to EINVAL.

(2) Does localedef --list-archive work?

Yes. It is unaffected by the LC_COLLATE changes since the locale archive records
have explicit length and can be listed even when they can't be loaded. This is
wrong IMO, and we should have done something to detect the invalid LC_COLLATE
and print a warning, but that's another QoI issue unrelated to the patch you're
trying to apply.

c.

Re: [PATCH] system: grub: On MIPS, the linux image name is vmlinuz

[Mark H Weaver]

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

> I just pushed this and two other non-controversial patches from
> ‘wip-loongson2f’.

Sounds good, thanks!

> I could continue, because the remainder looks OK too at first glance
> (mostly I need to test that the new GRUB works fine here), but I thought
> I’d leave you a chance to chime in.  ;-)
>
> So the backlog currently is this:
>
> + 8692ab8 TEMPORARY_HACK: gnu: gst-plugins-base: Disable tests on MIPS and 
> ARM.
> + 8549720 NON_INTEL_ONLY: services: xorg: Remove xf86-video-intel.
> + 7380191 gnu: grub: Add support for Loongson-based machines.

FYI, the commit "7380191 gnu: grub: Add support for Loongson-based
machines" contains a mistake that shows itself on non-MIPS machines: the
quote in the following line should be quasiquote:

  '(("qemu" ,qemu-for-tests)

I fixed it in my local tree but haven't yet pushed it.

 Mark

Re: [PATCH 1/1] gnu: lua: Build with dynamic library support.

[Leo Famulari]

Calling all Lua experts! Or even somebody that has used Lua before! ;)

I studied the lua-5.1 and lua-5.2 Makefiles more carefully and I will
split this up into separate packages for each version, with some
changes.

On Tue, Oct 27, 2015, at 11:48, Ludovic Courtès wrote:
> By “fixing the flags”, do you mean that the .so that we have for 5.1
> does not actually contain position-independent code?  That CFLAGS was
> ignored?

I'm not sure about the state of our lua-5.1's liblua.so. How to test it?

These changes are about building Lua so that it can load Lua libraries
dynamically. Currently, the lua-5.1 we package lacks this feature.
Possibly the lua-5.2 is the same way.

> > I will have to look into it again. I tested the results by starting the
> > Lua interpreter while linking a shared library:
> > $ lua -lssl
> 
> I’m not familiar with Lua; what does this command do?

`lua` starts the interactive lua interpreter. Giving it the argument
`-lname` calls "require('name') before executing script.  Typically used
to load libraries." (quoted from them Lua man page). Some helpful people
in the Prosody chatroom suggested it as a simple way to test if a Lua
interpreter can load dynamic libraries or not. Our lua-5.1 can't:
$ ll `which lua`
lrwxrwxrwx 7 root guixbuild 61 Dec 31  1969
/var/guix/profiles/per-user/leo/guix-profile/bin/lua ->
/gnu/store/fl27mjm8kxp0rj989cd8mj67qjvl0jr3-lua-5.1.5/bin/lua
$ lua -lssl
lua: error loading module 'ssl.core' from file
'/home/leo/.guix-profile/usr/lib/lua/5.1/ssl.so':
dynamic libraries not enabled; check your Lua installation
stack traceback:
[C]: ?
[C]: in function 'require'
/home/leo/.guix-profile/usr/share/lua/5.1/ssl.lua:7: in main
chunk
[C]: ?
[C]: ?

> I thought the goal was to get liblua.so for 5.2, but this seems to be
> testing something else?

By default, building Lua does not create liblua.so, which is why the
lua51-liblua-so.patch is there. I can look into a similar patch for 5.2. 

Also, we need to set up the search paths to help Lua find Lua libraries.
That can be configured at build time. I figured I would try to get a
working Lua interpreter in master before working on those things, but I
am open to guidance.

Revised patches forthcoming.

Leo

Re: [PATCH] system: grub: On MIPS, the linux image name is vmlinuz

[Ludovic Courtès]

I just pushed this and two other non-controversial patches from
‘wip-loongson2f’.

I could continue, because the remainder looks OK too at first glance
(mostly I need to test that the new GRUB works fine here), but I thought
I’d leave you a chance to chime in.  ;-)

So the backlog currently is this:

+ 8692ab8 TEMPORARY_HACK: gnu: gst-plugins-base: Disable tests on MIPS and ARM.
+ 8549720 NON_INTEL_ONLY: services: xorg: Remove xf86-video-intel.
+ 7380191 gnu: grub: Add support for Loongson-based machines.
+ 139588b gnu: grub: Update to 2.02-beta2-502-gc93d3e6.
+ fd70853 gnu: grub: Install documentation.
+ cde6189 gnu: grub: Use modify-phases and other minor cleanups.
+ 4f17937 gnu: Add linux-libre-loongson2f.
+ 61e8280 doc: Add texinfo to the requirements when building from git.
+ 5a45f27 gnu: linux-libre: On MIPS, the linux image name is vmlinuz, not 
bzImage.
+ 4cb1515 gnu: linux-libre: Add case for ARCH=mips.
+ 4917d6a gnu: linux-libre: Add 'supported-systems' field: Intel only for now.

Ludo’.

Re: [PATCH] refresh: Support comma separated updater types.

[Ludovic Courtès]

Alex Kost  skribis:

> From 4a5132f171dfe6bac99661e75e7c5e53c4f74116 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Tue, 27 Oct 2015 21:13:05 +0300
> Subject: [PATCH] refresh: Support comma separated updater types.
>
> * guix/scripts/refresh.scm (%options): Handle comma separated types for
>   '--type' option.
>   (guix-refresh): Adjust accordingly.
>   (show-help): Likewise.
> * doc/guix.texi (Invoking guix refresh): Document it.

[...]

> +  (let ((names (map string->symbol (string-split arg #\,

I prefer ‘string-tokenize’, which is standard, even though it’s more
verbose.

> +  (lists
> +   (apply append lists

Rather: (concatenate lists).

OK with these changes.

Thank you for the quick patch!

Ludo’.

[PATCH] refresh: Support comma separated updater types.

[Alex Kost]

Ludovic Courtès (2015-10-26 00:42 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-10-21 15:54 +0300) wrote:
>>
>>> Hello!
>>>
>>> We now have a number of importers, which is great, but so far we had no
>>> support to update packages once they had been imported, even though most
>>> of the code to do that already is in the importer.
>>>
>>> So commit 0a7c5a09 generalizes the upstream-tracking code from (guix
>>> gnu-maintenance) a bit, such that we can then easily define “updaters”
>>> based on the import code.  As an example, subsequent commits add an
>>> updater for ELPA and one for CRAN.  The end result is:
>>>
>>>
>>> $ ./pre-inst-env guix refresh -t cran -t elpa
>>> gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 
>>> 0.10.0 to 0.11.0
>>> gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 
>>> to 11.88.9
>>>
>>> (When ‘-t’ is omitted, all the updaters are used.)
>>
>> Great!  What about instead of (or along with) "-t cran -t elpa", use a
>> comma separated list as it is done in "guix lint --checkers=..."?
>
> I agree it would be more consistent (I guess I was a bit lazy here…)
> Would you like to make this change?  Otherwise I can give it a go.

Yes, I'd like.  The patch is attached, thanks!

>From 4a5132f171dfe6bac99661e75e7c5e53c4f74116 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 27 Oct 2015 21:13:05 +0300
Subject: [PATCH] refresh: Support comma separated updater types.

* guix/scripts/refresh.scm (%options): Handle comma separated types for
  '--type' option.
  (guix-refresh): Adjust accordingly.
  (show-help): Likewise.
* doc/guix.texi (Invoking guix refresh): Document it.
---
 doc/guix.texi|  6 +++---
 guix/scripts/refresh.scm | 14 --
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1bb7125..6fede5d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4263,8 +4263,8 @@ inconvenient.
 
 @item --type=@var{updater}
 @itemx -t @var{updater}
-Select only packages handled by @var{updater}.  Currently, @var{updater}
-may be one of:
+Select only packages handled by @var{updater} (may be a comma separated
+list of updaters).  Currently, @var{updater} may be one of:
 
 @table @code
 @item gnu
@@ -4279,7 +4279,7 @@ For instance, the following commands only checks for updates of Emacs
 packages hosted at @code{elpa.gnu.org} and updates of CRAN packages:
 
 @example
-$ guix refresh -t elpa -t cran
+$ guix refresh --type=elpa,cran
 gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
 gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9
 @end example
diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index a66b3f9..b2c9db0 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -69,7 +69,8 @@
 arg)
 (option '(#\t "type") #t #f
 (lambda (opt name arg result)
-  (alist-cons 'updater (string->symbol arg) result)))
+  (let ((names (map string->symbol (string-split arg #\,
+(alist-cons 'updaters names result
 (option '(#\L "list-updaters") #f #f
 (lambda args
(list-updaters-and-exit)))
@@ -114,7 +115,8 @@ specified with `--select'.\n"))
   -s, --select=SUBSETselect all the packages in SUBSET, one of
  `core' or `non-core'"))
   (display (_ "
-  -t, --type=UPDATER restrict to updates from UPDATER--e.g., 'gnu'"))
+  -t, --type=UPDATER,... restrict to updates from the specified updaters
+ (e.g., 'gnu')"))
   (display (_ "
   -L, --list-updaterslist available updaters and exit"))
   (display (_ "
@@ -209,15 +211,15 @@ downloaded and authenticated; not updating~%")
   (define (options->updaters opts)
 ;; Return the list of updaters to use.
 (match (filter-map (match-lambda
- (('updater . name)
-  (lookup-updater name))
+ (('updaters . names)
+  (map lookup-updater names))
  (_ #f))
opts)
   (()
;; Use the default updaters.
%updaters)
-  (lst
-   lst)))
+  (lists
+   (apply append lists
 
   (define (keep-newest package lst)
 ;; If a newer version of PACKAGE is already in LST, return LST; otherwise
-- 
2.5.0

Re: [PATCH] upstream: Add 'description' field to 'upstream-updater'.

[Alex Kost]

Ludovic Courtès (2015-10-27 20:26 +0300) wrote:

> Alex Kost  skribis:
>
>> From 19cee5ca983f663117d272382d7063d48e273cd0 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Mon, 26 Oct 2015 21:24:53 +0300
>> Subject: [PATCH] upstream: Add 'description' field to 'upstream-updater'.
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Suggested by Ludovic Courtès .
>>
>> * guix/upstream.scm (): Use 'define-record-type*'.
>>   [description]: New field.
>>   (lookup-updater): Adjust accordingly.
>> * guix/gnu-maintenance.scm (%gnu-updater): Likewise.
>> * guix/import/cran.scm (%cran-updater): Likewise.
>> * guix/import/elpa.scm (%elpa-updater): Likewise.
>
> Could you also add missing files to po/guix/POTFILES.in?

Sure!  I forgot about it.

> OK with this change, thank you!

Fixed and pushed, thanks!

-- 
Alex

Re: [PATCH 15/15] scripts: Add 'container' subcommand.

[Ludovic Courtès]

"Thompson, David"  skribis:

> From f5312c2445d774c9355c947d3c748d064740246e Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Wed, 1 Jul 2015 20:32:07 -0400
> Subject: [PATCH] scripts: Add 'container' subcommand.
>
> * guix/scripts/container.scm: New file.
> * guix/scripts/container/exec.scm: New file.
> * po/guix/POTFILES.in: Add them.
> * Makefile.am (MODULES): Add them.
> * doc/guix.texi (Invoking guix container): New section.

[...]

> +Note: This tool is experimental.  The interface is subject to radical
> +change in the future.

Rather:  

  @quotation Note
  As of version @value{VERSION}, this tool is experimental.  The ...
  @end quotation

The rest looks good to me.

There are no tests, but ‘container-excursion’ is already tested in
tests/containers.scm and exec.scm does little more than call it, so I
think it’s OK.

Thanks!

Ludo’.

Re: [PATCH 13/15] scripts: system: Add 'container' action.

[Ludovic Courtès]

"Thompson, David"  skribis:

> From 5dde31ef51502726a2915cc4faba81f4fadb851c Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Mon, 8 Jun 2015 09:04:38 -0400
> Subject: [PATCH] scripts: system: Add 'container' action.
>
> * guix/scripts/system.scm (show-help): Display 'container' action.
>   (system-derivation-for-action, guix-system): Add 'container' case.
>   (perform-action): Skip GRUB config generation when building a container.
> * doc/guix.texi (Invoking guix system): Document it.

[...]

> +  ;; A range of 65536 uid/gids is used to cover 16 bits worth of
> +  ;; users and groups, which is sufficient for most cases.

Should be enough for everyone.  ;-)

>(display (_ "\
> +  container build a Linux container that shares the host's store\n"))

I’d remove “Linux” here (after all, we use libc’s interface, which
hopefully will be implemented for the Hurd eventually.)

OK with this change, thank you!

Ludo’.

Re: [PATCH 03/12] import: pypi: Use "pypi-uri" instead of building the URL manually.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> * guix/import/pypi.scm (make-pypi-sexp): Use "pypi-uri".
> * tests/pypi.scm: Update the tests accordingly.

LGTM, provided ‘pypi-uri’ does not rely on mirror://, as discussed
earlier:

  https://lists.gnu.org/archive/html/guix-devel/2015-10/msg00347.html

Sorry for the delay!

Ludo’.

Re: [PATCH] upstream: Add 'description' field to 'upstream-updater'.

[Ludovic Courtès]

Alex Kost  skribis:

> From 19cee5ca983f663117d272382d7063d48e273cd0 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Mon, 26 Oct 2015 21:24:53 +0300
> Subject: [PATCH] upstream: Add 'description' field to 'upstream-updater'.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Suggested by Ludovic Courtès .
>
> * guix/upstream.scm (): Use 'define-record-type*'.
>   [description]: New field.
>   (lookup-updater): Adjust accordingly.
> * guix/gnu-maintenance.scm (%gnu-updater): Likewise.
> * guix/import/cran.scm (%cran-updater): Likewise.
> * guix/import/elpa.scm (%elpa-updater): Likewise.

Could you also add missing files to po/guix/POTFILES.in?

OK with this change, thank you!

Ludo’.

Re: Inconsistencies in 'guix system' and 'guix package'

[Ludovic Courtès]

Alex Kost  skribis:

> 1. Should 'guix system' actions share the same options?
>
> I think it is confusing that recently added 'guix system' actions
> (dmd-graph, extension-graph and list-generations) can take the same
> command-line options as the other system actions (--dry-run, --no-grub,
> etc.), because specifying these options doesn't take any effect.
>
> Another thing: "guix system  --help" displays the same help
> message for any action.  With 'list-generations' it is even more
> confusing, as (unlike the other actions) it takes PATTERN, not FILE as
> the positional argument.
>
> What about splitting 'guix system' into submodules (as it is done for
> 'guix import') with putting general bits into (guix scripts system)?

I like the idea of submodules à la ‘guix import’!  Would you like to
give it a try?  The thing is, all the actions except ‘list-generations’
have a lot in common.

I am indeed unsatisfied with the current situation, but did not have a
better idea.

> 2. What about adding subcommands for 'guix package'?
>
> As we have 'guix system list-generations', would it be more consistent
> to have 'guix package list-generations' instead of the current 'guix
> package --list-generations'?

Or the other way around?  :-)

> More generally, I think there is a similar issue with 'guix package', as
> with 'guix system': using some options together doesn't make sense
> (e.g., using --keep-failed, --show and --dry-run).  For example, the
> following command:
>
>   guix package --show=magit --list-generations=1
>
> displays generation 1, while the following:
>
>   guix package --list-generations=1 --show=magit
>
> describes 'magit' package.
>
> Analogously, would it be appropriate to replace some 'guix package'
> options (--show, --list-generations --list-installed, --list-available)
> with subcommands ('guix package show', ...)?

But then some operations would have no subcommands: install, remove,
rollback, etc.  So the syntax would be:

  guix package SUBCOMMAND OPTIONS

or:

  guix package OPTIONS

depending on the situation.  That’s not great either.

Maybe (thinking out loud) we could separate this in:

  guix package -> for installation, removal, upgrade, rollback
  guix query   -> for list-whatever, show

and then we need to find a place for --delete-generations.

Thoughts?

Seems like a can of worms, definitely post-0.9.0.

Ludo’.

Re: [PATCH] Gracefully handle incompatible locale data

[Ludovic Courtès]

Samuel Thibault  skribis:

> Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit :
>>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof 
>> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
>> 
>> This patch changes such conditions to return EINVAL instead of aborting.
>
> Just like it does for the __glibc_unlikely (idx > (size_t)
> newdata->filesize) test above, so it doesn't actually introduce any new
> error condition.
>
> I thus commited the change, thanks!

Thank you!  :-)

Ludo’.

Re: [PATCH] Add MOSAIK.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Efraim Flashner  writes:

[...]

>> I ran `./pre-inst-env guix build -s i686-linux mosaik` and the build failed 
>> for me.
>
> I can confirm this.  Too bad.  The reason is that “ssw.c” uses macros
> from emmintrin.h that are always inlined.  Inlining fails here due to
> “target specific option mismatch”.
>
> Does this only happen when cross-compiling or will this also happen if
> it’s built natively on i686?

It happens natively: The -s above does a native build (for
cross-compilation, it’s --target, which must be passed a full GNU
triplet.)

Ludo’.

Re: [PATCH 1/1] gnu: lua: Build with dynamic library support.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Tue, Oct 27, 2015, at 08:47, Ludovic Courtès wrote:
>> Leo Famulari  skribis:
>> 
>> > Notably, this enables the use of dynamic libraries with Lua.
>> 
>> A better subject line for the commit would be:
>> 
>>   gnu: lua-5.2: Build shared libraries.
>> 
>> AFAICS, the problem is only with Lua 5.2:
>> 
>> --8<---cut here---start->8---
>> $ ls $(guix build lua-5.1)/lib
>> liblua.a  liblua.so  liblua.so.5.1  lua
>> $ ls $(guix build lua-5.2)/lib
>> liblua.a  lua  pkgconfig
>> --8<---cut here---end--->8---
>> 
>> Thus I would suggest leaving ‘lua-5.1’ unchanged.
>
> The make flags were broken before, for both 5.1 and 5.2, but in
> different ways. So the commit isn't about enabling shared libraries but
> fixing the flags. And I'm not sure about using Lua as a library. I was
> more interested in using other libraries with Lua.

By “fixing the flags”, do you mean that the .so that we have for 5.1
does not actually contain position-independent code?  That CFLAGS was
ignored?

> For 5.2, MYCFLAGS is available to "users" to append flags to what is set
> by the platform flag ("linux").
>
> For 5.1, MYCFLAGS does NOT append, so you must manually copy the
> platform dependent flags onto the command-line and then append your
> flags.
>
> In both cases, our build instructions clobber the platform dependent
> flags.

OK.

>> > * gnu/packages/lua.scm (lua, lua-5.1)[arguments]: Set the make flags
>> >   properly for each version of lua.
>> 
>> [...]
>> 
>> > +++ b/gnu/packages/lua.scm
>> > @@ -24,6 +24,7 @@
>> >#:use-module (guix packages)
>> >#:use-module (guix download)
>> >#:use-module (guix build-system gnu)
>> > +  #:use-module (guix utils)
>> 
>> Looks like this line is not needed, is it?
>
> I thought that was necessary to use substitute-keyword-arguments.

Oh right.

>> > #:phases (alist-replace
>> >   'build
>> > - (lambda _ (zero? (system* "make" "CFLAGS=-fPIC" 
>> > "linux")))
>> > + (lambda _ (zero? (system* "make" "MYCFLAGS=-fPIC" 
>> > "linux")))
>> 
>> I just tried and AFAICS this line has no effect: Lua 5.2 still lacks
>> liblua.so.  Am I missing something?
>
> I will have to look into it again. I tested the results by starting the
> Lua interpreter while linking a shared library:
> $ lua -lssl

I’m not familiar with Lua; what does this command do?

I thought the goal was to get liblua.so for 5.2, but this seems to be
testing something else?

>> > @@ -89,8 +106,8 @@ for configuration, scripting, and rapid prototyping.")
>> >version ".tar.gz"))
>> >(sha256
>> > (base32 
>> > "0ydxpqkmsn2c341j4r2v6r5r0ig3kbwv3i9jran3iv81s6r6rgjm"))
>> > -(patches (list (search-patch "luajit-symlinks.patch")
>> > -   (search-patch "luajit-no_ldconfig.patch")
>> > +  (patches (list (search-patch "luajit-symlinks.patch")
>> > + (search-patch "luajit-no_ldconfig.patch")
>> 
>> Unnecessary too.
>
> I figured that I should remove this tabulation while I was touching the
> file.

OK, it can’t hurt, indeed.

Thanks,
Ludo’.

Re: [PATCH] Gracefully handle incompatible locale data

[Samuel Thibault]

Hello,

Ludovic Courtès, le Tue 22 Sep 2015 17:27:55 +0200, a écrit :
>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof 
> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.
> 
> This patch changes such conditions to return EINVAL instead of aborting.

Just like it does for the __glibc_unlikely (idx > (size_t)
newdata->filesize) test above, so it doesn't actually introduce any new
error condition.

I thus commited the change, thanks!

Samuel

Re: [PATCH] GCJ: run libjava tests.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> Attached is a new patch that pulls the ‘#:test-target’ line out of the
>> ‘substitute-keyword-arguments’ expression.  The indentation of many
>> lines changes because of this.  ‘git diff -w’ shows that the actual
>> change is pretty small.
>
> [...]
>
>> + `(#:test-target "check-target-libjava"
>> +   ,@(substitute-keyword-arguments `(#:modules ((guix build 
>> gnu-build-system)
>> +(guix build utils)
>> +(ice-9 regex)
>> +(srfi srfi-1)
>> +(srfi srfi-26))
>> +   ,@(package-arguments 
>> gcc))
>
> #:test-target could even go after #:modules in the argument to
> ‘substitute-keyword-arguments’, for consistency.

Ah, yes, that’s much prettier.  I’ll push with this change.  Thanks!

~~ Ricardo

Inconsistencies in 'guix system' and 'guix package'

[Alex Kost]

Hello,

1. Should 'guix system' actions share the same options?

I think it is confusing that recently added 'guix system' actions
(dmd-graph, extension-graph and list-generations) can take the same
command-line options as the other system actions (--dry-run, --no-grub,
etc.), because specifying these options doesn't take any effect.

Another thing: "guix system  --help" displays the same help
message for any action.  With 'list-generations' it is even more
confusing, as (unlike the other actions) it takes PATTERN, not FILE as
the positional argument.

What about splitting 'guix system' into submodules (as it is done for
'guix import') with putting general bits into (guix scripts system)?

2. What about adding subcommands for 'guix package'?

As we have 'guix system list-generations', would it be more consistent
to have 'guix package list-generations' instead of the current 'guix
package --list-generations'?

More generally, I think there is a similar issue with 'guix package', as
with 'guix system': using some options together doesn't make sense
(e.g., using --keep-failed, --show and --dry-run).  For example, the
following command:

  guix package --show=magit --list-generations=1

displays generation 1, while the following:

  guix package --list-generations=1 --show=magit

describes 'magit' package.

Analogously, would it be appropriate to replace some 'guix package'
options (--show, --list-generations --list-installed, --list-available)
with subcommands ('guix package show', ...)?

I'm not talking about adding 'guix install' or alike as was discussed in
a separate thread¹, but I agree with Andy that «"guix package" is doing
too much as it is».

¹ http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00086.html

-- 
Alex

Re: [PATCH 1/1] gnu: lua: Build with dynamic library support.

[Leo Famulari]

On Tue, Oct 27, 2015, at 08:47, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> 
> > Notably, this enables the use of dynamic libraries with Lua.
> 
> A better subject line for the commit would be:
> 
>   gnu: lua-5.2: Build shared libraries.
> 
> AFAICS, the problem is only with Lua 5.2:
> 
> --8<---cut here---start->8---
> $ ls $(guix build lua-5.1)/lib
> liblua.a  liblua.so  liblua.so.5.1  lua
> $ ls $(guix build lua-5.2)/lib
> liblua.a  lua  pkgconfig
> --8<---cut here---end--->8---
> 
> Thus I would suggest leaving ‘lua-5.1’ unchanged.

The make flags were broken before, for both 5.1 and 5.2, but in
different ways. So the commit isn't about enabling shared libraries but
fixing the flags. And I'm not sure about using Lua as a library. I was
more interested in using other libraries with Lua.

For 5.2, MYCFLAGS is available to "users" to append flags to what is set
by the platform flag ("linux").

For 5.1, MYCFLAGS does NOT append, so you must manually copy the
platform dependent flags onto the command-line and then append your
flags.

In both cases, our build instructions clobber the platform dependent
flags.

> > * gnu/packages/lua.scm (lua, lua-5.1)[arguments]: Set the make flags
> >   properly for each version of lua.
> 
> [...]
> 
> > +++ b/gnu/packages/lua.scm
> > @@ -24,6 +24,7 @@
> >#:use-module (guix packages)
> >#:use-module (guix download)
> >#:use-module (guix build-system gnu)
> > +  #:use-module (guix utils)
> 
> Looks like this line is not needed, is it?

I thought that was necessary to use substitute-keyword-arguments.
 
> > #:phases (alist-replace
> >   'build
> > - (lambda _ (zero? (system* "make" "CFLAGS=-fPIC" "linux")))
> > + (lambda _ (zero? (system* "make" "MYCFLAGS=-fPIC" 
> > "linux")))
> 
> I just tried and AFAICS this line has no effect: Lua 5.2 still lacks
> liblua.so.  Am I missing something?

I will have to look into it again. I tested the results by starting the
Lua interpreter while linking a shared library:
$ lua -lssl

> > +  `(modify-phases ,lua-phases
> > + (replace
> > +   'build
> > +   (lambda _
> > + (and
> > +  (zero? (system* "make" (string-append
> > +"MYCFLAGS="
> > +(string-join '("-fPIC "
> > +   "-DLUA_USE_LINUX "
> > +   "MYLIBS=-Wl,-E "
> > +   "-ldl -lreadline "
> > +   "-lhistory -lncurses")))
> > +"linux")))
> 
> This is in ‘lua-5.1’, so it’s unnecessary AFAICS.
> 
> > @@ -89,8 +106,8 @@ for configuration, scripting, and rapid prototyping.")
> >version ".tar.gz"))
> >(sha256
> > (base32 
> > "0ydxpqkmsn2c341j4r2v6r5r0ig3kbwv3i9jran3iv81s6r6rgjm"))
> > - (patches (list (search-patch "luajit-symlinks.patch")
> > -(search-patch "luajit-no_ldconfig.patch")
> > +  (patches (list (search-patch "luajit-symlinks.patch")
> > + (search-patch "luajit-no_ldconfig.patch")
> 
> Unnecessary too.

I figured that I should remove this tabulation while I was touching the
file.

> 
> Thanks for looking into it!

I will look into it again.

Re: [PATCH] scripts: build: Add --file option.

[Alex Kost]

David Thompson (2015-10-27 01:23 +0300) wrote:

> diff --git a/doc/guix.texi b/doc/guix.texi
> index 7715b72..abd8de3 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -3615,6 +3615,19 @@ The @var{options} may be zero or more of the following:
>  
>  @table @code
>  
> +@item --file=@var{file}
> +@itemx -e @var{file}
Typo: -f

-- 
Alex

Re: [PATCH] system: container: Update to new service API.

[Ludovic Courtès]

Sorry, I meant to preserve #:container? behavior but I forgot this bit.

I believe the attached patch provides an Even Greater Way to address the
problem, namely by making the modprobe/firmware thing an optional
service.

Could you try and report back?  I tried it in a VM and there’s no
regression.

Besides, we’ll have to make sure ‘guix system extension-graph’ honors
--container.

Ludo’.

diff --git a/gnu/services.scm b/gnu/services.scm
index d0fe0ad..a02d79e 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -62,6 +62,7 @@
 boot-service-type
 activation-service-type
 activation-service->script
+%linux-bare-metal-service
 etc-service-type
 etc-directory
 setuid-program-service-type
@@ -202,20 +203,6 @@ file."
 (union-build #$output '#$things))
 #:modules '((guix build union))
 
-(define (modprobe-wrapper)
-  "Return a wrapper for the 'modprobe' command that knows where modules live.
-
-This wrapper is typically invoked by the Linux kernel ('call_modprobe', in
-kernel/kmod.c), a situation where the 'LINUX_MODULE_DIRECTORY' environment
-variable is not set---hence the need for this wrapper."
-  (let ((modprobe "/run/current-system/profile/bin/modprobe"))
-(gexp->script "modprobe"
-  #~(begin
-  (setenv "LINUX_MODULE_DIRECTORY"
-  "/run/booted-system/kernel/lib/modules")
-  (apply execl #$modprobe
- (cons #$modprobe (cdr (command-line
-
 (define* (activation-service->script service)
   "Return as a monadic value the activation script for SERVICE, a service of
 ACTIVATION-SCRIPT-TYPE."
@@ -240,8 +227,7 @@ ACTIVATION-SCRIPT-TYPE."
 
   (mlet* %store-monad ((actions  (service-activations))
(modules  (imported-modules %modules))
-   (compiled (compiled-modules %modules))
-   (modprobe (modprobe-wrapper)))
+   (compiled (compiled-modules %modules)))
 (gexp->file "activate"
 #~(begin
 (eval-when (expand load eval)
@@ -256,12 +242,6 @@ ACTIVATION-SCRIPT-TYPE."
 (activate-/bin/sh
  (string-append #$(canonical-package bash) "/bin/sh"))
 
-;; Tell the kernel to use our 'modprobe' command.
-(activate-modprobe #$modprobe)
-
-;; Let users debug their own processes!
-(activate-ptrace-attach)
-
 ;; Run the services' activation snippets.
 ;; TODO: Use 'load-compiled'.
 (for-each primitive-load '#$actions)
@@ -287,6 +267,41 @@ ACTIVATION-SCRIPT-TYPE."
   ;; receives.
   (service activation-service-type #t))
 
+(define %modprobe-wrapper
+  ;; Wrapper for the 'modprobe' command that knows where modules live.
+  ;;
+  ;; This wrapper is typically invoked by the Linux kernel ('call_modprobe',
+  ;; in kernel/kmod.c), a situation where the 'LINUX_MODULE_DIRECTORY'
+  ;; environment variable is not set---hence the need for this wrapper.
+  (let ((modprobe "/run/current-system/profile/bin/modprobe"))
+(program-file "modprobe"
+  #~(begin
+  (setenv "LINUX_MODULE_DIRECTORY"
+  "/run/booted-system/kernel/lib/modules")
+  (apply execl #$modprobe
+ (cons #$modprobe (cdr (command-line
+
+(define %linux-kernel-activation
+  ;; Activation of the Linux kernel running on the bare metal (as opposed to
+  ;; running in a container.)
+  #~(begin
+  ;; Tell the kernel to use our 'modprobe' command.
+  (activate-modprobe #$%modprobe-wrapper)
+
+  ;; Let users debug their own processes!
+  (activate-ptrace-attach)))
+
+(define linux-bare-metal-service-type
+  (service-type (name 'linux-bare-metal)
+(extensions
+ (list (service-extension activation-service-type
+  (const %linux-kernel-activation))
+
+(define %linux-bare-metal-service
+  ;; The service that does things that are needed on the "bare metal", but not
+  ;; necessary or impossible in a container.
+  (service linux-bare-metal-service-type #f))
+
 (define (etc-directory service)
   "Return the directory for SERVICE, a service of type ETC-SERVICE-TYPE."
   (files->etc-directory (service-parameters service)))
diff --git a/gnu/system.scm b/gnu/system.scm
index aa76882..de85156 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -290,7 +290,8 @@ a container or that of a \"bare metal\" system."
;; container.
(if container?
'()
-   (list (service firmware-service-type
+   (list %linux-bare-metal-service
+  

Re: [PATCH] Add MOSAIK.

[Ricardo Wurmus]

Efraim Flashner  writes:

> On Fri, 23 Oct 2015 10:42:49 +0200
> Ricardo Wurmus  wrote:
>
>> > Mosaik fails on all architectures except for x86_64. Should it be disabled
>> > or are there configure flags to make it work elsewhere?  
>> 
>> I think this is caused by ‘includes/linux.inc’, which is unconditionally
>> included by default.
>> 
>> Disabling the line
>> 
>> include includes/$(BLD_PLATFORM).inc
>> 
>> should be sufficient to fix this.
>> 
>> Alternatively, we could set BLD_PLATFORM (to something other than just
>> “linux” on non-x86_64) and patch “include” to read “-include”, so that
>> it doesn’t cause an error when the file does not exist.
>> 
>> That’s what the attached patch does.
>> 
>
> I ran `./pre-inst-env guix build -s i686-linux mosaik` and the build failed 
> for me.

I can confirm this.  Too bad.  The reason is that “ssw.c” uses macros
from emmintrin.h that are always inlined.  Inlining fails here due to
“target specific option mismatch”.

Does this only happen when cross-compiling or will this also happen if
it’s built natively on i686?

~~ Ricardo

Re: [PATCH 1/1] gnu: lua: Build with dynamic library support.

[Ludovic Courtès]

Leo Famulari  skribis:

> Notably, this enables the use of dynamic libraries with Lua.

A better subject line for the commit would be:

  gnu: lua-5.2: Build shared libraries.

AFAICS, the problem is only with Lua 5.2:

--8<---cut here---start->8---
$ ls $(guix build lua-5.1)/lib
liblua.a  liblua.so  liblua.so.5.1  lua
$ ls $(guix build lua-5.2)/lib
liblua.a  lua  pkgconfig
--8<---cut here---end--->8---

Thus I would suggest leaving ‘lua-5.1’ unchanged.

> * gnu/packages/lua.scm (lua, lua-5.1)[arguments]: Set the make flags
>   properly for each version of lua.

[...]

> +++ b/gnu/packages/lua.scm
> @@ -24,6 +24,7 @@
>#:use-module (guix packages)
>#:use-module (guix download)
>#:use-module (guix build-system gnu)
> +  #:use-module (guix utils)

Looks like this line is not needed, is it?

> #:phases (alist-replace
>   'build
> - (lambda _ (zero? (system* "make" "CFLAGS=-fPIC" "linux")))
> + (lambda _ (zero? (system* "make" "MYCFLAGS=-fPIC" "linux")))

I just tried and AFAICS this line has no effect: Lua 5.2 still lacks
liblua.so.  Am I missing something?

> +  `(modify-phases ,lua-phases
> + (replace
> +   'build
> +   (lambda _
> + (and
> +  (zero? (system* "make" (string-append
> +"MYCFLAGS="
> +(string-join '("-fPIC "
> +   "-DLUA_USE_LINUX "
> +   "MYLIBS=-Wl,-E "
> +   "-ldl -lreadline "
> +   "-lhistory -lncurses")))
> +"linux")))

This is in ‘lua-5.1’, so it’s unnecessary AFAICS.

> @@ -89,8 +106,8 @@ for configuration, scripting, and rapid prototyping.")
>version ".tar.gz"))
>(sha256
> (base32 
> "0ydxpqkmsn2c341j4r2v6r5r0ig3kbwv3i9jran3iv81s6r6rgjm"))
> -   (patches (list (search-patch "luajit-symlinks.patch")
> -  (search-patch "luajit-no_ldconfig.patch")
> +  (patches (list (search-patch "luajit-symlinks.patch")
> + (search-patch "luajit-no_ldconfig.patch")

Unnecessary too.

Thanks for looking into it!

Ludo’.

Re: [PATCH] GCJ: run libjava tests.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Attached is a new patch that pulls the ‘#:test-target’ line out of the
> ‘substitute-keyword-arguments’ expression.  The indentation of many
> lines changes because of this.  ‘git diff -w’ shows that the actual
> change is pretty small.

[...]

> + `(#:test-target "check-target-libjava"
> +   ,@(substitute-keyword-arguments `(#:modules ((guix build 
> gnu-build-system)
> +(guix build utils)
> +(ice-9 regex)
> +(srfi srfi-1)
> +(srfi srfi-26))
> +   ,@(package-arguments gcc))

#:test-target could even go after #:modules in the argument to
‘substitute-keyword-arguments’, for consistency.

Otherwise LGTM.

Thanks!

Ludo’.

Re: [PATCH] gnu: Add xcompmgr

[Ludovic Courtès]

Andreas Enge  skribis:

> On Mon, Oct 26, 2015 at 11:30:40PM +0100, Ludovic Courtès wrote:
>> http://cgit.freedesktop.org/xorg/app/xcompmgr/tree/COPYING, which is
>
> As it is not part of xorg proper, I think it should go to xdisorg.scm.
> Are you okay with me moving it there?

Fine with me (I wondered about it and noticed a couple of “misplaced”
packages at the bottom of xorg.scm and thought xcompmgr was closer to
Xorg than these).  Make sure to remove #:use-module clauses that the
patch added.

Thanks,
Ludo’.

Re: [PATCH] Add MOSAIK.

[Efraim Flashner]

On Fri, 23 Oct 2015 10:42:49 +0200
Ricardo Wurmus  wrote:

> > Mosaik fails on all architectures except for x86_64. Should it be disabled
> > or are there configure flags to make it work elsewhere?  
> 
> I think this is caused by ‘includes/linux.inc’, which is unconditionally
> included by default.
> 
> Disabling the line
> 
> include includes/$(BLD_PLATFORM).inc
> 
> should be sufficient to fix this.
> 
> Alternatively, we could set BLD_PLATFORM (to something other than just
> “linux” on non-x86_64) and patch “include” to read “-include”, so that
> it doesn’t cause an error when the file does not exist.
> 
> That’s what the attached patch does.
> 

I ran `./pre-inst-env guix build -s i686-linux mosaik` and the build failed for 
me.

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


pgpT9UuOhKPxq.pgp
Description: OpenPGP digital signature

Re: [PATCH] Fix subread on non-x86_64

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> the attached patch should fix the build of subread on non-x86_64 by
>> overriding the CC and CCFLAGS variables, which by default are set to
>> contain a lot of x86_64 optimisations.
>
> Nice!  Could you add a comment explaining that?

Sure.

>> From 71a37b56d0962f0db4009bdb6a88c22025278a00 Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Fri, 23 Oct 2015 14:16:27 +0200
>> Subject: [PATCH] gnu: subread: Use SSE optimizations on x86_64 only.
>>
>> * gnu/packages/bioinformatics.scm (subread)[arguments]: Override CC and
>>   CCFLAGS conditionally dependent on target system.
>
> [...]
>
>> +   (if (string-prefix? "x86_64" system)
>> +   (string-append "CCFLAGS=" (string-join (append flags 
>> flags64) " "))
>> +   (string-append "CCFLAGS=" (string-join flags " "
>
> The last argument to ‘string-join’ can be omitted here.

Okay.  Pushed with the above changes.
Thanks!

~~ Ricardo

Re: [PATCH] GCJ: run libjava tests.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> ‘substitute-keyword-arguments’ only works if the given keyword appears
> in the input:
>
>   (substitute-keyword-arguments '()
> ((#:foo _) 'bar))
>
>   => ()
>
> It might be what’s happening here?

You are right, this exactly what happened here.

Attached is a new patch that pulls the ‘#:test-target’ line out of the
‘substitute-keyword-arguments’ expression.  The indentation of many
lines changes because of this.  ‘git diff -w’ shows that the actual
change is pretty small.

>From 95609455bbdaa43699a66efe9a5508c06e0bf9ad Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Thu, 22 Oct 2015 13:02:37 +0200
Subject: [PATCH] gnu: gcj: Run libjava tests.

* gnu/packages/gcc.scm (gcj)[native-inputs]: Add dejagnu.
  [arguments]: Replace check phase to run "check-target-libjava" target.
---
 gnu/packages/gcc.scm | 138 +++
 1 file changed, 72 insertions(+), 66 deletions(-)

diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 7e4f18b..5d07255 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -1,7 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès 
 ;;; Copyright © 2014, 2015 Mark H Weaver 
-;;; Copyright © 2014 Ricardo Wurmus 
+;;; Copyright © 2014, 2015 Ricardo Wurmus 
 ;;; Copyright © 2015 Andreas Enge 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -27,6 +27,7 @@
   #:use-module (gnu packages compression)
   #:use-module (gnu packages multiprecision)
   #:use-module (gnu packages texinfo)
+  #:use-module (gnu packages dejagnu)
   #:use-module (gnu packages doxygen)
   #:use-module (gnu packages xml)
   #:use-module (gnu packages docbook)
@@ -460,77 +461,82 @@ using compilers other than GCC."
("javac.in" ,javac.in)
("ecj-bootstrap" ,ecj-bootstrap)
,@(package-inputs gcc)))
+(native-inputs
+ `(("dejagnu" ,dejagnu)
+   ,@(package-native-inputs gcc)))
 ;; Suppress the separate "lib" output, because otherwise the
 ;; "lib" and "out" outputs would refer to each other, creating
 ;; a cyclic dependency.  
 (outputs
  (delete "lib" (package-outputs gcc)))
 (arguments
- (substitute-keyword-arguments `(#:modules ((guix build gnu-build-system)
-(guix build utils)
-(ice-9 regex)
-(srfi srfi-1)
-(srfi srfi-26))
-   ,@(package-arguments gcc))
-   ((#:configure-flags flags)
-`(let ((ecj (assoc-ref %build-inputs "ecj-bootstrap")))
-   `("--enable-java-home"
- "--enable-gjdoc"
- ,(string-append "--with-ecj-jar=" ecj)
- "--enable-languages=java"
- ,@(remove (cut string-match "--enable-languages.*" <>)
-   ,flags
-   ((#:phases phases)
-`(modify-phases ,phases
-   (add-after
-'unpack 'add-lib-output-to-rpath
-(lambda _
-  (substitute* "libjava/Makefile.in"
-(("libgcj_bc_dummy_LINK = .* -shared" line)
- (string-append line " -Wl,-rpath=$(libdir)"))
-(("libgcj(_bc)?_la_LDFLAGS =" ldflags _)
- (string-append ldflags " -Wl,-rpath=$(libdir)")
-   (add-after
-'install 'install-javac-and-javap-wrappers
-(lambda _
-  (let* ((javac  (assoc-ref %build-inputs "javac.in"))
- (ecj(assoc-ref %build-inputs "ecj-bootstrap"))
- (gcj(assoc-ref %outputs "out"))
- (gcjbin (string-append gcj "/bin/"))
- (jvm(string-append gcj "/lib/jvm/"))
- (target (string-append jvm "/bin/javac")))
-
-(symlink (string-append gcjbin "jcf-dump")
- (string-append jvm "/bin/javap"))
-
-(copy-file ecj (string-append gcj "/share/java/ecj.jar"))
-
-;; Create javac wrapper from the template javac.in by
-;; replacing the @VARIABLES@ with paths.
-(copy-file javac target)
-(patch-shebang target)
-(substitute* target
-  (("@JAVA@")
-   (string-append jvm "/bin/java"))
-  (("@ECJ_JAR@")
-   (string-append gcj "/share/java/ecj.jar"))
-  (("@RT_JAR@")
-   (string-append jvm "/jre/lib/rt.jar"))
-  (("@TOOLS_JAR@")
-   (string-append jvm "/lib/tools.jar")))
-(chmod target #o755)
-#t)))
-   (add-after
-'install 'remove-broken-or-conflicting-files
-(lambda _
-  (let ((out (assoc-ref %outputs "out"

Re: Environment containers

[Ludovic Courtès]

Alex Vong  skribis:

> On 26/10/2015, Thompson, David  wrote:
>> On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
>>  wrote:
>>
>>> Also, for Debian 8 users and maybe others, this might help:
>>>
>>> sudo sysctl -w kernel.unprivileged_userns_clone=1
>>
>> Yes, user namespaces are a must-have for this to work.  I will prepare
>> patches that mention this in the manual and add a test to 'guix
>> environment' that can detect if user namespaces are unavailable and
>> display a more helpful error message.
>>
> I think the patch could be considered a fix for
>  as well. How do
> you think?

Do you still experience the test failures mentioned in that report?  If
not, could you email 21...@debbugs.gnu.org, specifying which commit
works for you?

I suspect 0e3cc31 helped.

Thanks,
Ludo’.

Re: [PATCH 14/15] scripts: environment: Add --container option.

[Ludovic Courtès]

Hello!

One thing I noticed is that ‘guix environment --container’ behaves
sub-optimally when ‘SHELL’ is set or set to the empty string:

--8<---cut here---start->8---
$ guix environment alta --pure --container

[...]

In execvp of /home/ludo/.guix-profile/bin/bash: No such file or directory
$ SHELL= guix environment alta --pure --container
In execvp of : No such file or directory
--8<---cut here---end--->8---

One has to explicitly ‘unset SHELL’ to sidestep the problem.  This may
be confusing to newcomers.

What about automatically mapping $SHELL in the container when it is set?


Also, ‘SHELL’ is overridden in the environment:

--8<---cut here---start->8---
$ echo $SHELL
/home/ludo/.guix-profile/bin/bash
$ guix environment alta --container --expose=$SHELL
bash-4.3# echo $SHELL
/bin/sh
# ls -l /proc/2/exe
lrwxrwxrwx 1 0 0 0 Oct 27 10:11 /proc/2/exe -> /home/ludo/.guix-profile/bin/bash
bash-4.3# ls -l /home/ludo/.guix-profile/bin/bash
-r-xr-xr-x 2 65534 65534 917320 Jan  1  1970 /home/ludo/.guix-profile/bin/bash
--8<---cut here---end--->8---

I’m not sure if ‘SHELL’ should be added to ‘%precious-variables’.

Thoughts?

Thanks,
Ludo’.

Re: [PATCH] gnu: Add xcompmgr

[Andreas Enge]

On Mon, Oct 26, 2015 at 11:30:40PM +0100, Ludovic Courtès wrote:
> http://cgit.freedesktop.org/xorg/app/xcompmgr/tree/COPYING, which is

As it is not part of xorg proper, I think it should go to xdisorg.scm.
Are you okay with me moving it there?

Andreas