Re: [PATCH 12/13] gnu: Add python2-pygtk.

[Eric Bavier]

On Sat, Nov 22, 2014 at 10:18 AM, Eric Bavier  wrote:

>
> On Sat, Nov 22, 2014 at 9:40 AM, Federico Beffa  wrote:
>
>> > Eric Bavier  skribis:
>> >
>> >> * gnu/packages/gtk.scm (python2-pygtk): New variable.
>> >
>>
>> I notice that most python packages are defined for python 3 and then a
>> python2 package is generated with the procedure 'package-with-python2'.
>> Is pygtk problematic with python 3?
>>
>
> It has been a while since I did the packaging work for this python2-pygtk,
> and I seem to recall that there was some sort of difficulty with python3.
>

It looks possible, but from what I can tell, it might require more work on
the packages that pygtk depends on, some of which aren't compatible with
python3 or would requires updates to work with python3.

`~Eric

-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: [PATCH] gnu: Add Nmap.

[Eric Bavier]

On Tue, Nov 25, 2014 at 5:25 PM, Taylan Ulrich Bayırlı/Kammer <
taylanbayi...@gmail.com> wrote:

>
> That being said, I still think it's wasteful that C code gets recompiled
> when there's an update to a dynamic component.
>
> A rough idea for the future: save some intermediate build output (say
> from the 'build' phase)
>

I added the ccache package a little while ago.  I had wondered whether it
would be possible to run all our builds through ccache so that updates to
core packages might not be as much of a time burden (at the cost of some
extra disk space).  Might be something interesting to try.

`~Eric

-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: [PATCH] gnu: Add Nmap.

[Taylan Ulrich Bayırlı/Kammer]

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

> [large snip]
>
> I hope this clarifies things.

Yes!  Thanks for your patience.  It now dawns on me that our primary aim
isn't byte-equal build process outputs (in terms of file contents); it's
"immutable run-time behavior" of a package.  That is to say, if
/gnu/store/...-foo/bin/foo works fine today, it should work fine any
day; it's unacceptable to let it load a different .so than its
designated one, unless we define some very strict criteria for the .so
and prove that a replacement satisfies them...  Similarly for some
Python module the program uses.  I was chasing a "reproducible builds"
red herring.

That being said, I still think it's wasteful that C code gets recompiled
when there's an update to a dynamic component.

A rough idea for the future: save some intermediate build output (say
from the 'build' phase), then when there's an update to a run-time
component such as a DSO or dynlang module, make a new package that
merely receives some tweaks to the saved intermediate output, such as
fixing RUNPATH, re-patching shebang lines, etc.  Users will still need
to download these new packages; that in turn could be improved via
binary diffs one day.

> So, where were we with this nmap patch?  :-)

Heh, indeed.

I thought I'd wait for feedback from the Nmap ML but I guess that's not
necessary.  I'll continue working on it tomorrow.

Taylan

Re: [PATCH] Hotfix (repeat)

[Ludovic Courtès]

Deck Pickard  skribis:

> On 23 Nov 2014 21:49, "Ludovic Courtès"  wrote:
>>
>> Deck Pickard  skribis:
>>
>> > From 8e297904d80b39cd510ba0cced37acdb9b1aeb89 Mon Sep 17 00:00:00 2001
>> > From: nebuli 
>> > Date: Sat, 22 Nov 2014 19:58:24 +0100
>> > Subject: [PATCH 2/4] guix build: Add --max-jobs option (without handling
>> >  code).
>> >
>> > * doc/guix.texi: Mention in the docs.
>> > * guix/scripts/build.scm: Extend (show-build-options-help) and
>> >   (%standard-build-options) functions.
>>
>> Actually I had overlooked that this patch does nothing.   :-)
>>
>> Could you send an updated version that passes the right option to
>> ‘set-build-options’?
>>
>
> No. Using '-c 0 -M 0' fails with cryptic message.

Setting max-jobs to 0 leads to:

--8<---cut here---start->8---
guix build: error: build failed: unable to start any build; either increase 
`--max-jobs' or enable distributed builds
--8<---cut here---end--->8---

That’s expected because it really asks for zero locally running build
jobs (something that is useful, for instance, on a Hydra front-end.)

Commit f6526eb addresses that in a simple way.

Thanks,
Ludo’.

Re: doc: Fix syntax errors.

[Taylan Ulrich Bayırlı/Kammer]

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

> I assume you’re using Texinfo 4?  Texinfo 5 is fine with the extra
> space.

Indeed; the one on Debian stable.

Taylan

Re: [PATCH] gnu: Add Nmap.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

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

[...]

>> The whole functional approach things means that bindings are static
>
> That's a neat analogy. :-)

It’s not just an analogy, it’s really what happens.

> However, we needn't recompile C code when there's an update to some
> dynlang library the program uses, do we?

Yes we do.

> Also, configure scripts that check for such dynlang libraries' presence
> might become a problem.  I imagine one could provide some for-building
> version of said library that's merely of the same major version, to
> "shut up" the configure script, since it only gets in the way in this
> case.  (Complaining about the lack of a run-time dependency, at
> build-time...  Yes, above I said *not* doing this is probably a bug in
> Nmap's build process, but for us it would become an annoyance.)
> Alternatively, the script might simply take a flag telling it to enable
> a feature even if it can't find a run-time dependency; I don't how many
> configure scripts have this.

Most of the time, packages check at configure-time whether their
perquisites are available.  Then, their test suite use these specific
dependencies.  Finally, in the case of DSOs, the RUNPATH makes sure that
these specific dependencies are used at run time.

Then there’s the case of dynamic languages with no RUNPATH equivalent.
In that case we arrange with ‘propagated-inputs’ or with wrappers to
make sure the “right” dependencies are used at run time.

I’m not sure if that answers your concerns, does it?

> Same thing as above really.  Until the ABI of a dylib changes, updates
> to it needn't ignite recompilation of C code which uses that lib; it
> won't affect the compiler output anyway.  (Tell me if I'm technically
> wrong; not an expert on C compilation etc.)

At the very least, the RUNPATH will be different.

But then, keep in mind we’re aiming for complete reproducibility.  So we
can’t rely on things like “oh, developers say this version is
ABI-compatible with the previous one.”

> It does sound like breaking functional purity, but is it really so when
> an input has *no* effect on a build process other than the test suite?

That’s an important effect: it means that the test suite is known to
work this particular input.

> Once the test suite is separated, the real package and for-building
> package become operationally equivalent under the given build process,
> so providing one in place of the other would be a correctness preserving
> optimization. :-)

Yeah, I see where you’re going.  :-)  Eelco Dolstra’s PhD thesis on Nix
had that idea of “equivalence classes”.  It’s not very practical, though.

> In that case, we should already be able to do at least this, no?  (The
> other ideas are sadly high up in the air.)  It could have prevented
> world-rebuilds upon the bash security patches, for example.  (Given it's
> acceptable to use a buggy (even security-holy) Bash for some ./configure
> scripts and the like, so long as it doesn't break specifically them.)

See “Security Updates” in the manual for that.

>>> "Runtime dependencies are found by scanning binaries for the hash
>>> parts of Nix store paths (such as r8vvq9kq…). This sounds risky, but
>>> it works extremely well."
>>>
>>> Perhaps we already do that?
>>
>> Yes.  That means that run-time dependencies are a strict subset of
>> build-time dependencies.
>
> I see.  One confusion remains: wouldn't that mean it would drop a
> dependency such as the Python GTK module in our case, because its hash
> doesn't appear anywhere, and instead it's only referenced by module name
> which is expected to be in some Python load path at run-time?

Correct.  That’s why we’d either use ‘propagated-inputs’ or
‘wrap-program’, depending on the situation.

I hope this clarifies things.

So, where were we with this nmap patch?  :-)

Ludo’.

Re: Root file system not cleanly unmounted

[Adam Pribyl]

On Tue, 25 Nov 2014, Ludovic Courtès wrote:


Eric Bavier  skribis:


Adam Pribyl writes:


On Tue, 25 Nov 2014, Ludovic Courtès wrote:


FYI, if you installed a system from 0.8, chances are that your root file
system is not cleanly unmounted (from what ext4 recovers without any
problems, but still.)

This is fixed by commit 1c27641, so consider running ‘guix pull’ and
‘guix system reconfigure’.


Not sure if this was meant also for those running guix 0.8 as this is my
result of guix pull:

# guix pull
starting download of `/tmp/guix-file.W6HuZ2' from
`http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
http://git.savannah.gnu.org/.../guix-master.tar.gz  6775.4 KiB
transferred
The following derivation will be built:
/gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv
building path(s) `/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'
copying and compiling to
'/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'...
compiling... 12.7% of 354 filesERROR: no binding `alsa-lib' in module
(gnu packages linux)


Commit 77c9286 broke this.


Yes, my bad.  The next one unbroke it.

Adam: could you try again?


Well if I found it right:

guix pull
starting download of `guix-file.Hd9WTS' from 
`http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...

...
ERROR: no code for module (json)
Backtrace:
In ice-9/boot-9.scm:
 157: 12 [catch #t # ...]
In unknown file:
   ?: 11 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 10 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 9 [eval # #]
In ice-9/boot-9.scm:
2401: 8 [save-module-excursion #ice-9/boot-9.scm:4045:3 ()>]

4050: 7 [#]
1724: 6 [%start-stack load-stack #ice-9/boot-9.scm:4041:10 ()>]

1729: 5 [#]
In unknown file:
   ?: 4 [primitive-load 
"/gnu/store/5mj3ppg03zid8yaxf4zy40bwqm2wi6cl-guix-latest-guile-builder"]

In ice-9/eval.scm:
 387: 3 [eval # ()]
In 
/gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/guix/build/pull.scm:
 121: 2 [build-guix 
"/gnu/store/lg0rmq4z3jp59pjn9f9v2rd11rpyd7pv-guix-latest" ...]
  75: 1 [p-for-each #/gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/gui

x/build/pull.scm:121:14 (file)> ...]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: process failed #/gnu/store/n2jjh4kzfv3hp4zhd0aflwq4i2jihnnq-module-import/g

uix/build/pull.scm:121:14 (file)> 256




Ludo’.


Adam

Re: doc: Fix syntax errors.

[Ludovic Courtès]

taylanbayi...@gmail.com ("Taylan Ulrich "Bayırlı/Kammer\"") skribis:

> Some .texi syntax errors seem to have sneaked in on commit 7fec52b.
>
> ===File /home/tub/media/src/guix/0001-doc-Fix-syntax-errors.patch===
> From 110e68f04cc9efb8d72d19a401a6ff1ca039c7d4 Mon Sep 17 00:00:00 2001
> From: Taylan Ulrich B 
> Date: Tue, 25 Nov 2014 14:41:02 +0100
> Subject: [PATCH] doc: Fix syntax errors.
>
> * doc/guix.texi (Package Naming):
> (Fonts): Remove space between '@foo' and '{'.

Applied, thanks.

I assume you’re using Texinfo 4?  Texinfo 5 is fine with the extra
space.

Ludo’.

Re: Root file system not cleanly unmounted

[Ludovic Courtès]

Eric Bavier  skribis:

> Adam Pribyl writes:
>
>> On Tue, 25 Nov 2014, Ludovic Courtès wrote:
>>
>>> FYI, if you installed a system from 0.8, chances are that your root file
>>> system is not cleanly unmounted (from what ext4 recovers without any
>>> problems, but still.)
>>>
>>> This is fixed by commit 1c27641, so consider running ‘guix pull’ and
>>> ‘guix system reconfigure’.
>>
>> Not sure if this was meant also for those running guix 0.8 as this is my
>> result of guix pull:
>>
>> # guix pull
>> starting download of `/tmp/guix-file.W6HuZ2' from
>> `http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
>> http://git.savannah.gnu.org/.../guix-master.tar.gz  6775.4 KiB
>> transferred
>> The following derivation will be built:
>> /gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv
>> building path(s) `/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'
>> copying and compiling to
>> '/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'...
>> compiling... 12.7% of 354 filesERROR: no binding `alsa-lib' in module
>> (gnu packages linux)
>
> Commit 77c9286 broke this.

Yes, my bad.  The next one unbroke it.

Adam: could you try again?

Ludo’.

utils: Improve docstrings.

["Taylan Ulrich Bayırlı/Kammer"]

I just spend half an hour trying to find the bug in the following:

(substitute* "Makefile.in"
  (("^(prefix=[[:blank:]]*)/usr/local$" all prefix)
   (string-append prefix (assoc-ref outputs "out"

until I realized the lines of the file are represented as newline
terminated strings and a $ in the regexp won't match a newline by
default.

The behavior could be changed, but it seems like it was explicitly
programmed to work this way, and does make sense in a way, so I
decided to add a warning about this into the docstrings of
`substitute' and `substitute*'.

WDYT?


===File
/home/tub/media/src/guix/0001-utils-Improve-docstrings.patch===
>From 3f472e56c3fd9482e42fe8eecee5a857dbd2b8cc Mon Sep 17 00:00:00 2001
From: Taylan Ulrich B 
Date: Tue, 25 Nov 2014 21:25:16 +0100
Subject: [PATCH] utils: Improve docstrings.

* guix/build/utils.scm (substitute): Clarify first sentence of
  docstring and add warning to the docstring about using '$' to match
  an end of line.
  (substitute*): Add warning to the docstring about using '$' to match
  an end of line.
---
 guix/build/utils.scm | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index cda4fb1..d93366d 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -365,10 +365,11 @@ PROC's result is returned."
 (false-if-exception (delete-file template))
 
 (define (substitute file pattern+procs)
-  "PATTERN+PROCS is a list of regexp/two-argument procedure.  For each line
-of FILE, and for each PATTERN that it matches, call the corresponding PROC
-as (PROC LINE MATCHES); PROC must return the line that will be written as a
-substitution of the original line."
+  "PATTERN+PROCS is a list of regexp/two-argument-procedure pairs.  For each
+line of FILE, and for each PATTERN that it matches, call the corresponding
+PROC as (PROC LINE MATCHES); PROC must return the line that will be written as
+a substitution of the original line.  Be careful about using '$' to match the
+end of a line; by itself it won't match the terminating newline of a line."
   (let ((rx+proc  (map (match-lambda
 (((? regexp? pattern) . proc)
  (cons pattern proc))
@@ -428,7 +429,10 @@ When one of the MATCH-VAR is `_', no variable is bound to 
the corresponding
 match substring.
 
 Alternatively, FILE may be a list of file names, in which case they are
-all subject to the substitutions."
+all subject to the substitutions.
+
+Be careful about using '$' to match the end of a line; by itself it won't
+match the terminating newline of a line."
 ((substitute* file ((regexp match-var ...) body ...) ...)
  (let ()
(define (substitute-one-file file-name)
-- 
2.1.2

Re: Root file system not cleanly unmounted

[Eric Bavier]

Adam Pribyl writes:

> On Tue, 25 Nov 2014, Ludovic Courtès wrote:
>
>> FYI, if you installed a system from 0.8, chances are that your root file
>> system is not cleanly unmounted (from what ext4 recovers without any
>> problems, but still.)
>>
>> This is fixed by commit 1c27641, so consider running ‘guix pull’ and
>> ‘guix system reconfigure’.
>
> Not sure if this was meant also for those running guix 0.8 as this is my
> result of guix pull:
>
> # guix pull
> starting download of `/tmp/guix-file.W6HuZ2' from
> `http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
> http://git.savannah.gnu.org/.../guix-master.tar.gz  6775.4 KiB
> transferred
> The following derivation will be built:
> /gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv
> building path(s) `/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'
> copying and compiling to
> '/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'...
> compiling... 12.7% of 354 filesERROR: no binding `alsa-lib' in module
> (gnu packages linux)

Commit 77c9286 broke this.

-- 
Eric Bavier

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: [PATCH] gnu: Add pyparsing.

[Federico Beffa]

On Tue, Nov 25, 2014 at 6:21 PM, Eric Bavier  wrote:
>
> Perhaps:
>
> (for-each
>   (lambda (dir tgt)
> (for-each (lambda (file)
> (copy-file file
>(string-append tgt "/" (basename file
>   (find-files dir ".*")))
>   (list "docs" "htmldoc" "examples")
>   (list doc html-doc exmples)
>
> Not tested of course ;)

Definitely less boilerplate :-)

Thanks,
Fede
From 10f16ec3d3cca44c89e33df81e050dff5ea8c7f1 Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Tue, 25 Nov 2014 16:27:33 +0100
Subject: [PATCH] gnu: Add pyparsing.

* gnu/packages/python.scm (python-pyparsing, python2-pyparsing): New
  variables.
---
 gnu/packages/python.scm | 49 +
 1 file changed, 49 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 7967201..c0eea3c 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1932,3 +1932,52 @@ capabilities.")
 
 (define python2-numpy-bootstrap
   (package-with-python2 python-numpy-bootstrap))
+
+(define-public python-pyparsing
+  (package
+(name "python-pyparsing")
+(version "2.0.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://sourceforge/pyparsing"
+   "/pyparsing-" version ".tar.gz"))
+   (sha256
+(base32
+ "01lasib0n2fp2k99c988qhz16lm9hcwmnmrmhybdb3jq2xmkvr0p"
+(build-system python-build-system)
+(outputs '("out" "doc"))
+(arguments
+ `(#:tests? #f ; no test target
+   #:modules ((guix build python-build-system)
+  (guix build utils))
+   #:phases
+   (alist-cons-after
+'install 'install-doc
+(lambda* (#:key outputs #:allow-other-keys)
+  (let* ((doc (string-append (assoc-ref outputs "doc") 
+ "/share/doc/" ,name "-" ,version))
+ (html-doc (string-append doc "/html"))
+ (examples (string-append doc "/examples")))
+(mkdir-p html-doc)
+(mkdir-p examples)
+(for-each 
+ (lambda (dir tgt)
+   (map (lambda (file) 
+  (copy-file file (string-append tgt "/" (basename file
+(find-files dir ".*")))
+ (list "docs" "htmldoc" "examples")
+ (list doc html-doc examples
+%standard-phases)))
+(home-page "http://pyparsing.wikispaces.com";)
+(synopsis "Python parsing class library")
+(description
+ "The pyparsing module is an alternative approach to creating and
+executing simple grammars, vs. the traditional lex/yacc approach, or the use
+of regular expressions.  The pyparsing module provides a library of classes
+that client code uses to construct the grammar directly in Python code.")
+(license expat)))
+
+(define-public python2-pyparsing
+  (package-with-python2 python-pyparsing))
+
-- 
1.8.4

Re: Root file system not cleanly unmounted

[Adam Pribyl]

On Tue, 25 Nov 2014, Ludovic Courtès wrote:


FYI, if you installed a system from 0.8, chances are that your root file
system is not cleanly unmounted (from what ext4 recovers without any
problems, but still.)

This is fixed by commit 1c27641, so consider running ‘guix pull’ and
‘guix system reconfigure’.


Not sure if this was meant also for those running guix 0.8 as this is my
result of guix pull:

# guix pull
starting download of `/tmp/guix-file.W6HuZ2' from
`http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
http://git.savannah.gnu.org/.../guix-master.tar.gz  6775.4 KiB
transferred
The following derivation will be built:
   /gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv
building path(s) `/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'
copying and compiling to
'/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest'...
compiling... 12.7% of 354 filesERROR: no binding `alsa-lib' in module
(gnu packages linux)
Backtrace:
In ice-9/boot-9.scm:
 157: 11 [catch #t # ...]
In unknown file:
   ?: 10 [apply-smob/1 #]
In ice-9/boot-9.scm:
  63: 9 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 8 [eval # #]
In ice-9/boot-9.scm:
2401: 7 [save-module-excursion #]
4050: 6 [#]
1724: 5 [%start-stack load-stack ...]
1729: 4 [#]
In unknown file:
   ?: 3 [primitive-load
"/gnu/store/wschzj6qf16y7nibnav2cwsv40b7inss-guix-latest-builder"]
In
/gnu/store/d4vmrl5kvprwbblrg5m44sf4az5lbha3-module-import/guix/build/pull.scm:
 151: 2 [build-guix
"/gnu/store/cnfxfvzsiphhhr6igjkaqzbfazh0afyk-guix-latest" ...]
  97: 1 [loop # 2 45]
In unknown file:
   ?: 0 [scm-error misc-error #f ...]

ERROR: In procedure scm-error:
ERROR: process failed # 256
builder for `/gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv'
failed with exit code 1
killing process 1095
guix pull: error: build failed: build of
`/gnu/store/haam2bdcnzqmbyscaxmn7ixgm3bbygba-guix-latest.drv' failed



Thanks,
Ludo’.


Adam Pribyl

Re: [PATCH] gnu: Add pyparsing.

[Federico Beffa]

Cyril Roelandt  writes:

>
> Maybe you could add the PyPI mirror here.
>

I'm not sure I understand. Do you mean replace or really add? A second
uri field? Could you give an example? The sourceforge download site is
the one mentioned on the homepage.

>
> There is a "unitTests.py" that can be run manually, if I'm not mistaken.
> Maybe you could replace the check phase ?
>

I do not think so.  I do not see any reference to tests in the README
and other source files and I can't find a file called "unitTests.py".

>
> I trust you on the doc thing :) Is it something that could somehow be
> part of the python build system?
>

I'm not a python expert :-) From the few packages that I prepared
lately, I have the impression that each python library does something
different with the documentation.

>
> Do not start the synopsis by "a". You may want to run "guix lint" on
> your package to find such issues.
>

Ooops, forgot to run that.

Thanks for the review,
Fede

Re: [PATCH] gnu: Add pyparsing.

[Eric Bavier]

Federico Beffa writes:

> Please find attached a pyparsing package for review.
[...]
> +(with-directory-excursion "docs"
> +  (map (lambda (file) 
> + (copy-file file (string-append doc "/" file)))
> +   (find-files "." ".*")))
> +(with-directory-excursion "htmldoc"
> +  (map (lambda (file) 
> + (copy-file file (string-append html-doc "/" file)))
> +   (find-files "." ".*")))
> +(with-directory-excursion "examples"
> +  (map (lambda (file) 
> + (copy-file file (string-append examples "/" file)))
> +   (find-files "." ".*")

Perhaps:

(for-each
  (lambda (dir tgt)
(for-each (lambda (file)
(copy-file file
   (string-append tgt "/" (basename file
  (find-files dir ".*")))
  (list "docs" "htmldoc" "examples")
  (list doc html-doc exmples)
   
Not tested of course ;)

Also, try running the package through `guix lint`.

-- 
Eric Bavier

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: [PATCH] gnu: Add pyparsing.

[Cyril Roelandt]

On 11/25/2014 05:55 PM, Federico Beffa wrote:
> Please find attached a pyparsing package for review.
>

Review inlined.

> Regards,
> Fede
> 
> 
> 0001-gnu-Add-pyparsing.patch
> 
> 
> From edebe9d7663932912c6245abd690795fc02c1d02 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Tue, 25 Nov 2014 16:27:33 +0100
> Subject: [PATCH] gnu: Add pyparsing.
> 
> * gnu/packages/python.scm (python-pyparsing, python2-pyparsing): New
>   variables.
> ---
>  gnu/packages/python.scm | 54 
> +
>  1 file changed, 54 insertions(+)
> 
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 7967201..d9715c0 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -1932,3 +1932,57 @@ capabilities.")
>  
>  (define python2-numpy-bootstrap
>(package-with-python2 python-numpy-bootstrap))
> +
> +(define-public python-pyparsing
> +  (package
> +(name "python-pyparsing")
> +(version "2.0.2")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "mirror://sourceforge/pyparsing"
> +   "/pyparsing-" version ".tar.gz"))

Maybe you could add the PyPI mirror here.

> +   (sha256
> +(base32
> + "01lasib0n2fp2k99c988qhz16lm9hcwmnmrmhybdb3jq2xmkvr0p"
> +(build-system python-build-system)
> +(outputs '("out" "doc"))
> +(arguments
> + `(#:tests? #f ; no test target

There is a "unitTests.py" that can be run manually, if I'm not mistaken.
Maybe you could replace the check phase ?

> +   #:modules ((guix build python-build-system)
> +  (guix build utils))
> +   #:phases
> +   (alist-cons-after
> +'install 'install-doc
> +(lambda* (#:key outputs #:allow-other-keys)
> +  (let* ((doc (string-append (assoc-ref outputs "doc") 
> + "/share/doc/" ,name "-" ,version))
> + (html-doc (string-append doc "/html"))
> + (examples (string-append doc "/examples")))
> +(mkdir-p html-doc)
> +(mkdir-p examples)
> +(with-directory-excursion "docs"
> +  (map (lambda (file) 
> + (copy-file file (string-append doc "/" file)))
> +   (find-files "." ".*")))
> +(with-directory-excursion "htmldoc"
> +  (map (lambda (file) 
> + (copy-file file (string-append html-doc "/" file)))
> +   (find-files "." ".*")))
> +(with-directory-excursion "examples"
> +  (map (lambda (file) 
> + (copy-file file (string-append examples "/" file)))
> +   (find-files "." ".*")
> +%standard-phases)))

I trust you on the doc thing :) Is it something that could somehow be
part of the python build system?


> +(home-page "http://pyparsing.wikispaces.com";)
> +(synopsis "A Python parsing module")

Do not start the synopsis by "a". You may want to run "guix lint" on
your package to find such issues.

> +(description
> + "The pyparsing module is an alternative approach to creating and
> +executing simple grammars, vs. the traditional lex/yacc approach, or the use
> +of regular expressions. The pyparsing module provides a library of classes
> +that client code uses to construct the grammar directly in Python code.")
> +(license expat)))
> +
> +(define-public python2-pyparsing
> +  (package-with-python2 python-pyparsing))
> +

Thanks!
Cyril.

Re: [PATCH] gnu: Add pyparsing.

[Ludovic Courtès]

Federico Beffa  skribis:

> From edebe9d7663932912c6245abd690795fc02c1d02 Mon Sep 17 00:00:00 2001
> From: Federico Beffa 
> Date: Tue, 25 Nov 2014 16:27:33 +0100
> Subject: [PATCH] gnu: Add pyparsing.
>
> * gnu/packages/python.scm (python-pyparsing, python2-pyparsing): New
>   variables.

[...]

> +(synopsis "A Python parsing module")

Please remove “A”.  Perhaps “Python parsing class library” would be more
descriptive?

OK to push with a change along these lines.

Thank you,
Ludo’.

Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks.

[Ludovic Courtès]

Eric Bavier  skribis:

> Ludovic Courtès writes:
>
>> Eric Bavier  skribis:
>>
>>> The culprit, I think, is a small difference in behavior of bash.  If PATH
>>> is unset (such as within svn's hook environment), then `bash -c 'echo
>>> $PATH'` on an FHS system prints something like
>>> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", but Guix's
>>> bash prints "/no-such-path".  In the first case, `ls` will resolve to
>>> "/bin/ls", but will not be found in the second.
>>
>> OK.  The /no-such-path comes from the compile-time settings of our Bash,
>> in (gnu packages bash).
>>
>> We could perhaps fix it to refer to Coreutils, but that’s a bit
>> tricky.
>
> I'll fix our subversion, but we'll need to keep this option in mind in
> the future.  It doesn't look like it would be *too* tricky ;)

OK.

What would make it tricky is the fact that the “final” packages built in
(gnu packages commencement) must not retain references to the bootstrap
tools.  So the final Bash must refer to the final Coreutils, not to the
bootstrap Coreutils.

>>> I was able to get the tests to pass by simply patching the references to ls
>>> that libtool emits in its wrappers.  I think this might be the way to go
>>> for now,
>>
>> Yes, sounds good.
>>
>>> while also submitting a bug to libtool.
>>
>> I don’t think so.  Often, the problem is when such scripts contain
>> absolute file names, like /usr/bin/file, which we need to patch.  This
>> time they’re “doing it right”, so let’s not suggest the evil thing.
>> :-)
>
> My thought was that libtool could get the absolute file name to ls
> during configure, as it does already with a number of the other tools it
> uses.

Oh right, I had misunderstood your proposal.  That’s a good idea.

Thanks,
Ludo’.

[PATCH] gnu: Add pyparsing.

[Federico Beffa]

Please find attached a pyparsing package for review.

Regards,
Fede
From edebe9d7663932912c6245abd690795fc02c1d02 Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Tue, 25 Nov 2014 16:27:33 +0100
Subject: [PATCH] gnu: Add pyparsing.

* gnu/packages/python.scm (python-pyparsing, python2-pyparsing): New
  variables.
---
 gnu/packages/python.scm | 54 +
 1 file changed, 54 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 7967201..d9715c0 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1932,3 +1932,57 @@ capabilities.")
 
 (define python2-numpy-bootstrap
   (package-with-python2 python-numpy-bootstrap))
+
+(define-public python-pyparsing
+  (package
+(name "python-pyparsing")
+(version "2.0.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://sourceforge/pyparsing"
+   "/pyparsing-" version ".tar.gz"))
+   (sha256
+(base32
+ "01lasib0n2fp2k99c988qhz16lm9hcwmnmrmhybdb3jq2xmkvr0p"
+(build-system python-build-system)
+(outputs '("out" "doc"))
+(arguments
+ `(#:tests? #f ; no test target
+   #:modules ((guix build python-build-system)
+  (guix build utils))
+   #:phases
+   (alist-cons-after
+'install 'install-doc
+(lambda* (#:key outputs #:allow-other-keys)
+  (let* ((doc (string-append (assoc-ref outputs "doc") 
+ "/share/doc/" ,name "-" ,version))
+ (html-doc (string-append doc "/html"))
+ (examples (string-append doc "/examples")))
+(mkdir-p html-doc)
+(mkdir-p examples)
+(with-directory-excursion "docs"
+  (map (lambda (file) 
+ (copy-file file (string-append doc "/" file)))
+   (find-files "." ".*")))
+(with-directory-excursion "htmldoc"
+  (map (lambda (file) 
+ (copy-file file (string-append html-doc "/" file)))
+   (find-files "." ".*")))
+(with-directory-excursion "examples"
+  (map (lambda (file) 
+ (copy-file file (string-append examples "/" file)))
+   (find-files "." ".*")
+%standard-phases)))
+(home-page "http://pyparsing.wikispaces.com";)
+(synopsis "A Python parsing module")
+(description
+ "The pyparsing module is an alternative approach to creating and
+executing simple grammars, vs. the traditional lex/yacc approach, or the use
+of regular expressions. The pyparsing module provides a library of classes
+that client code uses to construct the grammar directly in Python code.")
+(license expat)))
+
+(define-public python2-pyparsing
+  (package-with-python2 python-pyparsing))
+
-- 
1.8.4

Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks.

[Eric Bavier]

Ludovic Courtès writes:

> Eric Bavier  skribis:
>
>> The culprit, I think, is a small difference in behavior of bash.  If PATH
>> is unset (such as within svn's hook environment), then `bash -c 'echo
>> $PATH'` on an FHS system prints something like
>> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", but Guix's
>> bash prints "/no-such-path".  In the first case, `ls` will resolve to
>> "/bin/ls", but will not be found in the second.
>
> OK.  The /no-such-path comes from the compile-time settings of our Bash,
> in (gnu packages bash).
>
> We could perhaps fix it to refer to Coreutils, but that’s a bit
> tricky.

I'll fix our subversion, but we'll need to keep this option in mind in
the future.  It doesn't look like it would be *too* tricky ;)

>> I was able to get the tests to pass by simply patching the references to ls
>> that libtool emits in its wrappers.  I think this might be the way to go
>> for now,
>
> Yes, sounds good.
>
>> while also submitting a bug to libtool.
>
> I don’t think so.  Often, the problem is when such scripts contain
> absolute file names, like /usr/bin/file, which we need to patch.  This
> time they’re “doing it right”, so let’s not suggest the evil thing.
> :-)

My thought was that libtool could get the absolute file name to ls
during configure, as it does already with a number of the other tools it
uses.  I agree that we don't want a "fix" that leaves us with yet more
things to patch.

-- 
Eric Bavier

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html

Re: Gluglug X60 Guix howto

[Ludovic Courtès]

Amirouche Boubekki  skribis:

> The wireless card is showing up in iwconfig and lspci (driver ath9k).
> Still, I can't connect using it because wpa_supplicant is missing. So it
> will wait that the system is finished installing.

Indeed.  I’ve just added wpa-supplicant to the image, so that’ll be
doable on the next release.

Thanks,
Ludo’.

Re: Installing the system from another distro

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-11-24 20:21 +0300) wrote:
>> Could it be an ABI issue that vanishes after “make clean-go && make”?
>
> That's it!  It was very unexpected for me as I did "make clean-go" not so
> long ago, but anyway it works now.  Thank you very much for such a
> verbose answer and even testing (!)

Good news.  :-)

> I have another question.  I used "--no-grub" option, so I don't have a
> proper grub.cfg.  I expected to see “/boot” directory with symlinks to
> the linux and initram images but there is no such dir.  Do I understand
> it right that “/gnu/store/…-linux-libre-3.17.4/bzImage” and
> “/gnu/store/…-base-initrd/initrd” are hardcoded in the "grub.cfg"?

Yes, that’s correct.

Actually, when passing --no-grub, ‘guix system’ doesn’t even bother
generating grub.cfg (see ‘perform-action’ in (guix scripts system).)

So if you really want to use --no-grub, you should retrieve the kernel
and initrd file names, and manually add them to your bootloader’s
config.

One way to do that is to run:

  guix system build my-system-config.scm

The returned directory name contains the initrd and kernel, among other
things.

Note that you’ll also need to pass --root= and --system= on the kernel
command line (see the ‘operating-system-grub.cfg’ procedure.)

As you see, passing --no-grub is not an optimized use case.  :-)

Ludo’.

Re: Howto run guix.el correctly?

[Alex Kost]

Ludovic Courtès (2014-11-24 23:42 +0300) wrote:

> Alex Kost  skribis:
>
>> No need to fiddle with ‘geiser-scheme-dir’: it should be set properly if
>> you have ‘(require 'geiser-install)’ in your emacs config.
>
> Oops, indeed, PEBKAC: I was just unaware of ‘geiser-install’, and
> everything was fine when I used Geiser from ELPA because that happens
> automagically.

Yes, that's the point: if you install Emacs packages using the Emacs
package system, everything should work out of the box.  If a package is
installed manually or with some distro's package manager, a user needs
to figure out what he should put in his config to "complete" the
installation.

> It would be nice if guix.el somehow had that works-out-of-the-box
> property when installing Emacs extensions.  :-)

As I wrote at
, I
see the only way to achieve that:

- to modify emacs package recipes so that they will provide some files
  with all required initial configuration (and to name such file
  "…-autoloads.el", for example);

- to modify “guix-init.el” so that (require 'guix-init) will load those
  autoloads files;

- to write some elisp code for auto-loading "…-autoloads.el" on the fly
  — i.e., to make it possible to install an Emacs package using
  "guix.el" and to use "M-x " immediately.

So if it's acceptable, what about modifying the current recipes
step-by-step.  With geiser it's easy: as "geiser-install.el" provides
all required setup (including autoloads for "M-x …" commands),
"geiser-autoloads.el" may just be a symlink to "geiser-install.el".  I'm
attaching the patch for that.

I'm going to send patch(es) for the elisp code later.

>From 49faffe688c53e9d9197ac9e07511ba0de501840 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Tue, 25 Nov 2014 16:50:11 +0300
Subject: [PATCH] gnu: emacs: Add "geiser-autoloads.el".

* gnu/packages/emacs.scm (geiser): Add 'post-install' phase for creating
  "geiser-autoloads.el".
---
 gnu/packages/emacs.scm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 119c613..bde707d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -135,6 +135,15 @@ editor (without an X toolkit)" )
  (sha256
   (base32 "1mrk0bzqcpfhsw6635qznn47nzfy9ps7wrhkpymswdfpw5mdsry5"
 (build-system gnu-build-system)
+(arguments
+ '(#:phases (alist-cons-after
+ 'install 'post-install
+ (lambda* (#:key outputs #:allow-other-keys)
+   (symlink "geiser-install.el"
+(string-append (assoc-ref outputs "out")
+   "/share/emacs/site-lisp/"
+   "geiser-autoloads.el")))
+ %standard-phases)))
 (inputs `(("guile" ,guile-2.0)
   ("emacs" ,emacs)))
 (home-page "http://nongnu.org/geiser/";)
-- 
2.1.3

Root file system not cleanly unmounted

[Ludovic Courtès]

FYI, if you installed a system from 0.8, chances are that your root file
system is not cleanly unmounted (from what ext4 recovers without any
problems, but still.)

This is fixed by commit 1c27641, so consider running ‘guix pull’ and
‘guix system reconfigure’.

The bug probably appeared as a side-effect of commit cd4a3cb3.
Basically, when rebooting, the devtmpfs file system on /dev would fail
to be unmounted, thus preventing / itself to be properly unmounted.

Thanks,
Ludo’.

PS: Thanks to David for raising it on IRC yesterday.

doc: Fix syntax errors.

["Taylan Ulrich Bayırlı/Kammer"]

Some .texi syntax errors seem to have sneaked in on commit 7fec52b.

===File /home/tub/media/src/guix/0001-doc-Fix-syntax-errors.patch===
>From 110e68f04cc9efb8d72d19a401a6ff1ca039c7d4 Mon Sep 17 00:00:00 2001
From: Taylan Ulrich B 
Date: Tue, 25 Nov 2014 14:41:02 +0100
Subject: [PATCH] doc: Fix syntax errors.

* doc/guix.texi (Package Naming):
(Fonts): Remove space between '@foo' and '{'.
---
 doc/guix.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index ec48f4a..a88b774 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4889,7 +4889,7 @@ already part of the official project name.  But 
@pxref{Python
 Modules} and @ref{Perl Modules} for special rules concerning modules for
 the Python and Perl languages.
 
-Font package names are handled differently, @pxref {Fonts}.
+Font package names are handled differently, @pxref{Fonts}.
 
 
 @node Version Numbers
@@ -4999,7 +4999,7 @@ under a common name, we prefer to package them together as
 In the case where several formats of the same font family or font collection
 are packaged separately, a short form of the format, prepended by a dash,
 is added to the package name.  We use @code{-ttf} for TrueType fonts,
-@code {-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
+@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
 fonts.
 
 
-- 
2.1.2

Re: Gluglug X60 Guix howto

[Amirouche Boubekki]

2014-11-25 13:42 GMT+01:00 Ludovic Courtès :

> Alex Sassmannshausen  skribis:
>
> > I received a request for instructions on how to get Guix running as
> > standalone on the Gluglug X60 — my work is ongoing (I haven't
> > reconfigured the Grub BIOS, nor have I got wireless working yet), but
> > a first draft may help other owners.
>
> Nice job!
>
> Do you know what WiFi chipset is included?  If it’s an Atheros thing,
> for which we have the free firmware, it shouldn’t be too hard.
>

I also have a gluglug x60. I'm doing the installation right now.

The wireless card is showing up in iwconfig and lspci (driver ath9k).
Still, I can't connect using it because wpa_supplicant is missing. So it
will wait that the system is finished installing.

Re: Installing the system from another distro

[Alex Kost]

Ludovic Courtès (2014-11-24 20:21 +0300) wrote:

> Alex Kost  skribis:
>
>> Hello, I've tried to install the Guix system from my current system
>> ("Arch Linux") where I use the Guix package manager:
>>
>>   ./pre-inst-env guix system init /path/to/my-os-config.scm /mnt/guix
>
> That should definitely work: it’s the same command that one runs from
> the installation image, nothing special.
>
>> Unfortunately it failed (os-config and the backtrace are attached).
>
> [...]
>
>> In gnu/system.scm:
>>  702: 3 [# #]
>>  449: 2 [# #]
>>  455: 1 [# (# # # # 
>> ...)]
>> In unknown file:
>>?: 0 [concatenate (() () () () () () () () () ...)]
>>
>> ERROR: In procedure concatenate:
>> ERROR: In procedure append: Wrong type argument in position 19 (expecting 
>> empty list): #f
>
> Believe it or not ;-), I cannot reproduce this bug.
>
> I tried with the very same configuration on current ‘master’:
>
> $ ./pre-inst-env guix system init alex.scm $PWD/t/
> La jena derivo estos esti konstruata:
>/gnu/store/h141fwh5mcjn6zq5192ff12hrxb9x9nn-system.drv
>/gnu/store/w18dn1ilngzip9yb9bk8dc34igidihsn-grub.cfg.drv
>/gnu/store/8p0m7kj666r0hv56r4b3a38556h1b8wf-dmd.conf.drv
>/gnu/store/0hdpjmmvgby0i194wf3hjs56nfn511sd-activate.drv
>/gnu/store/x2m84jd8w2x17ikq6qslb5argkg71bas-boot.drv
>/gnu/store/53320875lhrp11bvdjg47r2sqs3x32sz-linux-modules.drv
>/gnu/store/8j8z5nm2xkzjrr4mh7hf17dcvsxrxrjn-init.drv
>
> [...]
>
> /gnu/store/2bjpb39finn5rw006rrh4xxcqbzdij94-system
> /gnu/store/a3k9dx6i1w44qff2n9s99xlx2rlsmwq8-grub-2.00
> /gnu/store/sjcj2k78qalfzm799b06hf6hixh8mfwv-grub.cfg
>
> ni ekigas la operaci-sistemon sub '/home/ludo/src/guix/t/'...
> copying '/gnu/store/64sqqj8pbhff0w80x0gbliqirkcimy1k-glibc-2.20-locales'...
> copying '/gnu/store/4k20pkxgvfc22wpcvh6xr26ma4b619ad-glibc-2.20'...
>
> [...]
>
> Then I ran out of space on that partition, and the command wasn’t
> running as root, so it would have failed to install GRUB anyway.
>
> The backtrace you should suggests things failed before even files were
> copied to the store under /mnt/guix, right?

Yes, it failed before “La jena derivo estos esti konstruata:” message :-)

> Could it be an ABI issue that vanishes after “make clean-go && make”?

That's it!  It was very unexpected for me as I did "make clean-go" not so
long ago, but anyway it works now.  Thank you very much for such a
verbose answer and even testing (!)

I have another question.  I used "--no-grub" option, so I don't have a
proper grub.cfg.  I expected to see “/boot” directory with symlinks to
the linux and initram images but there is no such dir.  Do I understand
it right that “/gnu/store/…-linux-libre-3.17.4/bzImage” and
“/gnu/store/…-base-initrd/initrd” are hardcoded in the "grub.cfg"?

-- 
Alex

Re: Gluglug X60 Guix howto

[Ludovic Courtès]

Alex Sassmannshausen  skribis:

> I received a request for instructions on how to get Guix running as
> standalone on the Gluglug X60 — my work is ongoing (I haven't
> reconfigured the Grub BIOS, nor have I got wireless working yet), but
> a first draft may help other owners.

Nice job!

Do you know what WiFi chipset is included?  If it’s an Atheros thing,
for which we have the free firmware, it shouldn’t be too hard.

Ludo’.

Re: Gluglug X60 Guix howto

[白熊]

On 2014年11月23日 20:22:24 GMT+03:00, Alex Sassmannshausen 
 wrote:
>Hello,
>
>I received a request for instructions on how to get Guix running as
>standalone on the Gluglug X60 — my work is ongoing (I haven't
>reconfigured the Grub BIOS, nor have I got wireless working yet), but
>a first draft may help other owners.

I hope you can get the wireless working! Especially during Guix install...

If you make progress on this, definitely share as this would be enough for me 
to purchase the Gluglug X60 to experiment with Guix on it. 
--
白熊@相撲道

Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks.

[Ludovic Courtès]

Eric Bavier  skribis:

> The culprit, I think, is a small difference in behavior of bash.  If PATH
> is unset (such as within svn's hook environment), then `bash -c 'echo
> $PATH'` on an FHS system prints something like
> "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", but Guix's
> bash prints "/no-such-path".  In the first case, `ls` will resolve to
> "/bin/ls", but will not be found in the second.

OK.  The /no-such-path comes from the compile-time settings of our Bash,
in (gnu packages bash).

We could perhaps fix it to refer to Coreutils, but that’s a bit tricky.

(Similarly, ‘getconf PATH’ with our libc returns something non-sensical,
but I’m not sure what can be done about it.)

> Given that behavior, people have nothing to work around.  Does Nix's bash
> behave differently?

No.

> I'm not sure that our bash needs to be changed in any way.  It's current
> behavior seems in line with Guix's way of things.

Yes.

> I was able to get the tests to pass by simply patching the references to ls
> that libtool emits in its wrappers.  I think this might be the way to go
> for now,

Yes, sounds good.

> while also submitting a bug to libtool.

I don’t think so.  Often, the problem is when such scripts contain
absolute file names, like /usr/bin/file, which we need to patch.  This
time they’re “doing it right”, so let’s not suggest the evil thing.  :-)

Thanks,
Ludo’.