bug#68841: guix pack -f squashfs silently ignores symlinks

[Konrad Hinsen]

Let's make a basic Singularity file system containing certificates at
the place many programs expect them to be, i.e. /etc/ssl:

$ guix pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs
/gnu/store/mxyc56nsrcgcclvm5qsz5c9fkqwdswpw-bash-nss-certs-squashfs-pack.gz.squashfs

There is no error message concerning the symlink, but it's not recorded
either:

$ guix shell squashfs-tools -- unsquashfs -l 
/gnu/store/mxyc56nsrcgcclvm5qsz5c9fkqwdswpw-bash-nss-certs-squashfs-pack.gz.squashfs
 | grep -v /gnu/store
squashfs-root
squashfs-root/.empty
squashfs-root/.empty_1
squashfs-root/.singularity.d
squashfs-root/.singularity.d/actions
squashfs-root/.singularity.d/env
squashfs-root/.singularity.d/env/90-environment.sh
squashfs-root/bin
squashfs-root/dev
squashfs-root/gnu
squashfs-root/gnu/.empty
squashfs-root/home
squashfs-root/proc
squashfs-root/sys

What *does* work is:

$ guix pack -S /etc=etc --format=squashfs bash nss-certs

which makes me suspect that linking /etc/ssl fails because there is no
/etc in the file system, but I don't much about squashfs, so maybe I am
wrong.

Cheers,
  Konrad

bug#68794: git-annex accesses /etc/protocols

[Konrad Hinsen]

As packaged in Guix, git-annex reads the file /etc/protocols,
e.g. for accessing Web remotes. This requires sharing this
file from the host when running git-annex in a container.
Other software in Guix is patched to use the protocols file
from "net-base" instead. This should be done for git-annex
as well.

A quick scan of the source code shows no obvious reference to
/etc/protocols. It is possible that the access actually
happens in some dependency.

Cheers,
  Konrad.

bug#53258: Python unable to find modules within a Singularity container created with guix pack

[Konrad Hinsen]

Konrad Hinsen  writes:

> Patch at https://issues.guix.gnu.org/68241

If you want to test it without rebuilding tons of packages, here is a
version that grafts a patched Python onto the existing ones (as substitutes):

https://codeberg.org/khinsen/guix/src/branch/graft-fix-python-sitecustomize

Cheers,
  Konrad

bug#53258: Python unable to find modules within a Singularity container created with guix pack

[Konrad Hinsen]

Konrad Hinsen  writes:

> I will submit a patch for this.

Patch at https://issues.guix.gnu.org/68241

Cheers,
  Konrad

bug#53258: Python unable to find modules within a Singularity container created with guix pack

[Konrad Hinsen]

Hi everyone,

I found this issue while investigating a related one (the error
message). It looks like the core problem discussed here has been solved
in the meantime:

   Singularity> python3 -m numpy
   Error in sitecustomize; set PYTHONVERBOSE for traceback:
   ValueError: 
'/gnu/store/kx98dz2vc3gdpjficy4nbd7rscnkvz4s-profile/bin/../../h855kddqbay0pcbwr8a7i8m6ilz67cfn-python-3.10.7/lib/python3.10/site-packages'
 is not in list
   /gnu/store/kx98dz2vc3gdpjficy4nbd7rscnkvz4s-profile/bin/python3: No module 
named numpy.__main__; 'numpy' is a package and cannot be directly executed

This error message is to be expected, and NumPy can be imported:

   Singularity> python3
   Error in sitecustomize; set PYTHONVERBOSE for traceback:
   ValueError: 
'/gnu/store/kx98dz2vc3gdpjficy4nbd7rscnkvz4s-profile/bin/../../h855kddqbay0pcbwr8a7i8m6ilz67cfn-python-3.10.7/lib/python3.10/site-packages'
 is not in list
   Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0] on linux
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import numpy
   >>> 

What remains is the error message, which comes from a bug in Guix'
sitecustomize.py. It compares a raw path (sys.prefix) with paths that
have been normalized (os.path.normpath). That comparison fails if
sys.prefix contains "../", as it does when run from a Singularity
container. I will submit a patch for this.

Cheers,
  Konrad

bug#54350: Profile collisions in "guix shell"

[Konrad Hinsen]

Konrad Hinsen  writes:

> I run everything that is part of a research project in containers,
> meaning "guix shell -C".

Related: HPC users on clusters using NFS are also advised to use
"guix shell" rather than profiles:

  https://lists.gnu.org/archive/html/guix-science/2023-12/msg7.html
  https://lists.gnu.org/archive/html/guix-science/2023-12/msg8.html

Cheers,
  Konrad.

bug#54350: Profile collisions in "guix shell"

[Konrad Hinsen]

Hi everyone,

I ran into this issue when I was trying to turn a much-used shell
environment into a profile for persisting the binaries in the store.
I had been using it for several months, believing it to be OK.
Fortunately it was easy to fix.

Background: as part of a reproducible computation workflow (see my talk
at the ten-year meeting,
https://10years.guix.gnu.org/program/#guix-as-a-tool-for-computational-science),
I run everything that is part of a research project in containers,
meaning "guix shell -C". Since I rely on Python 2 software, I end up
using package transformations frequently to get old software to work. As
it turns out now, package transformations are also an excellent way to
create profile collisions: three out of five of my commonly used
containers have collisions, which I wasn't aware of until a few days
ago.

>From that perspective, the current behavior of "guix shell" is... let's
say "suboptimal".

I do understand the motivation, as explained in this thread, but I don't
quite understand (1) why profile collisions are so frequent in
development environments and (2) why ignoring them in that use case
doesn't cause any trouble.

When I run "guix shell -D inkscape", I expect to have, as much as
possible, the same environment as the one the daemon uses when build
inkscape. Does the daemon also switch off collision detection?

Cheers,
  Konrad.

bug#57878: Emacs native compilation on startup can crash the system

[Konrad Hinsen]

Ludovic Courtès  writes:

> Konrad, Emacs team: is this bug still happening today?
>
>   https://issues.guix.gnu.org/57878

I did some quick tests, and at least for my usage of Emacs, there are no
more problems with native compilation in current Guix (including Emacs
29.1). Great!

Konrad

bug#41394: java-testng: again nondeterministic test-failures?

[Konrad Hinsen]

During today's regular "guix pull", I ran into this problem: java-testng
failed to build twice (the failures comes from the test suite), but
built correctly the third time. That's for commit:
39fa1ef033fda82cb1d122e0d1675b51acb1db34

Cheers,
  Konrad.

bug#63726: time-machine without options does not get the latest commit

[Konrad Hinsen]

Hi Ludo,

> I had forgotten about this issue (my apologies…) and stumbled upon it
> again recently, which led me to approach it a bit differently:
>
>   https://issues.guix.gnu.org/65229
>
> Let me know what you think!

This looks good to me. In practice, I doubt anyone would use -q with
time-machine, because it makes more sense to specify an explicit channel
file every time. But for pull, I can well imaging using it in a
reproducibility-oriented setting.

Cheers,
  Konrad

bug#63726: time-machine without options does not get the latest commit

[Konrad Hinsen]

Hi Simon,

> What about this patch?

That's a good start! But I didn't quite understand what "as defined by the 
previous
+@dfn{channels} file" means, so I did some more research and some more
rewriting, and came up with the attached patch. That one is clear for
me, but maybe not for others...

In the course of this research, I noticed that channel files are used in
Guix in two varieties for rather different purposes, but this doesn't
seem to be explained anywhere. "guix describe -f channels" produces
channel files with a pinned commit for each repository. That's what we
usually give to time-machine. That feature of channel files seems even
undocumented. The chapter on channels discusses the channel files we
typically use with "guix pull", and which refer to a branch and thus its
last commit, rather than to a pinned commit.

Cheers,
  Konrad.
>From cbe372191a2daea7b62d8558422f08bc6ed0e047 Mon Sep 17 00:00:00 2001
From: Konrad Hinsen 
Date: Thu, 1 Jun 2023 16:55:33 +0200
Subject: [PATCH] doc: Reword guix time-machine without option.

* doc/guix.texi (Invoking guix time-machine): Reword the behaviour in the
absence of any option.
---
 doc/guix.texi | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 7f8d8d66e9..e4daffe4dd 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -4959,16 +4959,25 @@ Invoking guix time-machine
 @xref{Channels} for more information.
 @end table
 
-As for @command{guix pull}, the absence of any options means that the
-latest commit on the master branch will be used.  The command
+In the absence of any options, the target revision will be determined as
+for @command{guix pull}, i.e. from the user's
+@file{~/.config/guix/channels.scm} file, or, if no such file exists,
+from the system-wide @file{/etc/guix/channels.scm} file, or, if that
+file does not exist either, from the built-in default channels specified
+in the @code{%default-channels} variable.  Note that these three
+fallbacks are usually channel definitions pointing to @i{branches} in
+git repositories, rather then to specific @i{commits}, as the channel
+definitions produced by @command{guix describe} do. A branch-based
+channel definition refers to the latest commit on that branch. The
+command
 
 @example
 guix time-machine -- build hello
 @end example
 
-will thus build the package @code{hello} as defined in the master branch,
-which is in general a newer revision of Guix than you have installed.
-Time travel works in both directions!
+will thus build the package @code{hello} as defined by the current state
+of the default channels. In general, it builds a @i{newer} revision of
+Guix than you have installed.  Time travel works in both directions!
 
 Note that @command{guix time-machine} can trigger builds of channels and
 their dependencies, and these are controlled by the standard build
-- 
2.40.1

bug#63726: time-machine without options does not get the latest commit

[Konrad Hinsen]

Hi,

> Should we fix the doc or should we fix the code?…

I vote for fixing the doc. Two reasons:

 1. Having "guix time-machine" and "guix pull" behave in the same way
is desirable. Less cognitive load for users.

 2. What the doc says cannot be implemented in general. "The latest
commit on the master branch" makes no sense for a setup with
multiple channels, some of which may not even have a branch called
"master".

Cheers,
  Konrad.

bug#57878: Some further investigation

[Konrad Hinsen]

Hi everyone,

On the occasion of a "guix pull", I looked into this issue again,
because magit without ido-completing-read+ is less fun.

Loading this package runs lots of compilation threads, but it does
ultimately terminate, with an error:

  Debugger entered--Lisp error: (native-compiler-error (lambda (arg3  
arg4 arg5) (let ((f #'call-interactively)) (funcall f arg3 arg4 arg5))) 
"Debugger entered--Lisp error: (native-compiler-err...")
signal(native-compiler-error ((lambda (arg3  arg4 arg5) (let ((f 
#'call-interactively)) (funcall f arg3 arg4 arg5))) "Debugger entered--Lisp 
error: (native-compiler-err..."))
comp--native-compile((lambda (arg3  arg4 arg5) (let ((f 
#'call-interactively)) (funcall f arg3 arg4 arg5))) nil 
"/home/hinsen/.emacs.d/eln-cache/28.2-16da12a1/subr...")
comp-trampoline-compile(call-interactively)
comp-subr-trampoline-install(call-interactively)
advice--add-function(:around (#f(compiled-function () #) . #f(compiled-function (gv--val) #)) call-interactively@ido-cr+-record-current-command nil)
advice-add(call-interactively :around 
call-interactively@ido-cr+-record-current-command)

load-with-code-conversion("/gnu/store/abvhh3kcdpbg9vm2jz5q6zqhmfdpr4m7-emacs-..."
 "/gnu/store/abvhh3kcdpbg9vm2jz5q6zqhmfdpr4m7-emacs-..." nil nil)
load("/gnu/store/abvhh3kcdpbg9vm2jz5q6zqhmfdpr4m7-emacs-...")
(progn (load "/gnu/store/abvhh3kcdpbg9vm2jz5q6zqhmfdpr4m7-emacs-..."))
(setq elisp--eval-defun-result (progn (load 
"/gnu/store/abvhh3kcdpbg9vm2jz5q6zqhmfdpr4m7-emacs-...")))
elisp--eval-defun()
eval-defun(nil)
funcall-interactively(eval-defun nil)
command-execute(eval-defun)

What I notice here is "advice-add". It makes me wonder whether the
problem is perhaps not native-compiling ido-completing-read+, but
native-compiling the ido code that is getting adviced here.

Cheers,
  Konrad.

bug#57878: Minimal reproducible setup

[Konrad Hinsen]

Hi David and Liliana,

Thanks David for the added observations. This does indeed look like an
upstream bug, but it also seems to have a context dependence because the
Debian bug reports list some packages are affected that cause no problem
under Guix (e.g. git-timemachine).

As for Liliana's idea of disabling deferred compilation : shouldn't it
be sufficient to have all Emacs Lisp packages in Guix AOT-compiled?
There would be nothing left to compile in deferred mode. A quick scan of
the relevant page on Emacs Wiki
(https://www.emacswiki.org/emacs/GccEmacs) suggests that some package
manager do this.

Cheers,
  Konrad.

bug#57878: Minimal reproducible setup

[Konrad Hinsen]

I did one more test: run native-compile by hand on each elisp file in
the package ido-completing-read+. Works fine.

The next question that I consider relevant: is this an upstream (Emacs)
issue, or an issue created by packaging in Guix? That's not easy to
answer.

A related question: what are appropriate debugging techniques?

Cheers,
  Konrad.

bug#57878: Minimal reproducible setup

[Konrad Hinsen]

Liliana Marie Prikler  writes:

>> I think you can prevent native-compilation entirely by setting no-
>> native-compile to t in your early-init.el (I'm playing with the idea
>> of doing this anyway, because I'm annoyed by the clutter that falls
>> through the cracks).
>
> Okay, it turns out that disabling native compilation is not so simple
> after all.  Other ideas are welcome.

That's what I discovered as well. What you can do is set
native-comp-speed to -1, reducing native compilation to byte code
compilation. But that doesn't deactivate the machinery.

Cheers,
  Konrad.

bug#57878: Minimal reproducible setup

[Konrad Hinsen]

Konrad Hinsen  writes:

> Here is a minimal containerized example that
> creates a process avalanche:
>
> guix shell -C emacs emacs-ido-completing-read+ \
>-- emacs --batch --eval="(print load-path)"

I went through all my emacs packages. The only one that starts
the process avalanche is emacs-ido-completing-read+.

Cheers
  Konrad.

bug#57878: Minimal reproducible setup

[Konrad Hinsen]

My understanding of site-start.el is that it actually loads all the
Emacs packages that are listed in my Guix profile. Which means that my
package list matters. Here is a minimal containerized example that
creates a process avalanche:

guix shell -C emacs emacs-ido-completing-read+ \
   -- emacs --batch --eval="(print load-path)"

ido-completing-read+ is a rather small Emacs package, and I don't see
anything obvious in it that could cause trouble with native compilation.
But more importantly, I think no package should be able to cause the
behavior that I observe.

Cheers
  Konrad.

bug#57878: Emacs native compilation on startup can crash the system

[Konrad Hinsen]

After updating to a commit after the introduction of native compilation
in Emacs, I cannot start Emacs any more. It launches an ever increasing
number of async processes for native compilation, which rapidly makes
kswapd the main CPU user on my machine, and ultimately crashes the
kernel.

Some experiments showed that it's loading the site-lisp/site-start.el  that
causes this avalanche of processes:

  emacs -Q --batch --eval="(print load-path)"

works fine. As does:

  emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/guix-emacs.el 
--eval="(print load-path)"

But not:

  emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/site-start.el 
--eval="(print load-path)"

which starts the avalanche of compilation.

Possibly related: in my user-dir (~/.emacs.d/) I have a directory
"eln-cache" containing a directory "28.1-f1a30909", but that directory
remains empty. Perhaps all native compilation attempts fail and that's
what causes the problem. Just guessing!

Cheers,
  Konrad.

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

The bug is fixed via the patch referenced above in commit 
5831155175614726685edab7efa60ce48e4da1f5.

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

The other problem that Matthieu pointed out (but which is
unrelated to the initial bug report) is fixed by the following
two patches for snakemake-6 and snakemake-7:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57414
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57415

Cheers,
  Konrad

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

I have submitted a patch that fixes this problem:

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57413

This is the patch that Matthieu referred to, and which he tested in a
cluster environment.

Cheers,
  Konrad

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

The execution of Snakemake workflows fails on a cluster because the
script that Snakemake executes remotely does not reference Python
correctly.

This is due to a patch applied in the Guix package
definition (build phase call-wrapper-not-wrapped-snakemake, 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-xyz.scm#n9713)
which is outdated. The corresponding code in Snakemake was changed
significantly in the following commit:

  
https://github.com/snakemake/snakemake/commit/e87cc979bea0567e1cd97722d385f472857df83c#diff-438f3317205fd7130727d0589d2fc1a6c2e1f6fc48c2c04d354a8a09b91ba2f4

Cheers,
  Konrad

bug#29736: i686: webkit not usable

[Konrad Hinsen]

Leo Famulari  writes:

> We can use the gst-plugins/selection procedure to avoid propagating all
> of gst-plugins-bad.

That sounds interesting. But we'd first have to know which plugins are
actually important to have. Is there a way to trace plugin loading?

Konrad

bug#29736: i686: webkit not usable

[Konrad Hinsen]

Am 05/01/2022 um 08:41 schrieb zimoun:

Since the last message was from 2018 and, to my knowledge*, nothing
related was reported recently, I am closing.


For information, here's a lengthy discussion of WebKit crashes in the 
Nyxt browser when built under Guix:



https://github.com/atlas-engineer/nyxt/issues/1883


TL;DR: you have to add the packages gst-plugins-good and gst-plugins-bad 
if you want WebKit-based browsers to work in Guix. Otherwise WebKit 
complains about lack of WebVTT handling on many Web sites and just gives 
up. Adding both packages as a propagated input to WebKit should work - 
but maybe some people would not be happy to have gst-plugins-bad as a 
dependency, and prefer to have crashes on some Web sites.


I have no idea if this is related to the 2018 bug of course!


Cheers,

  Konrad.

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

[Konrad Hinsen]

Tobias Geerinckx-Rice  writes:

> Konrad Hinsen 写道：
>> So... how did I overlook this when searching for "texlive" in 
>> the issue
>> tracker? Answer: it doesn't sort correctly by "date submitted" 
>> when that
>> column is selected. Issue 52797 is way down on the list.
>
> Hah!  It seems to be a simple alphabetical sort :-D

Ah. April is always the most recent !

In the meantime, I confirm my problem goes away after updating the
daemon.

Thanks,
  Konrad

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

[Konrad Hinsen]

Hi Tobias,

> Is this ?

Yes, same problem!

So... how did I overlook this when searching for "texlive" in the issue
tracker? Answer: it doesn't sort correctly by "date submitted" when that
column is selected. Issue 52797 is way down on the list.

Anyway, thanks for the pointer! I will try to update my daemon and see
what happens!

Cheers,
  Konrad

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

[Konrad Hinsen]

With

   $ guix describe
   Generation 11déc. 27 2021 11:45:02   (current)
 guix 879a5cb
   repository URL: https://git.savannah.gnu.org/git/guix.git
   branch: master
   commit: 879a5cb7c45779ddd62699ae2d75a9e785d608ec

do:

   $ guix shell texlive
   hint: Consider passing the `--check' option once to make sure your shell 
does not clobber environment variables.

   substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
   The following derivations will be built:
  /gnu/store/6z9arnfp3c51iq99wddcbcal9zbbayav-profile.drv
  /gnu/store/js6cv4h83n60k8kh9vcgy2k0syfqm5yv-texlive-texmf-20210325.drv
  
/gnu/store/z5r60zy9vmydf44fdyyc7hgc6q93aahm-texlive-20210325-texmf.tar.xz.drv

   0,7 MB will be downloaded
   guix shell: error: integer expected from stream

The same error is shown for other attempts to access "texlive",
e.g. "guix package". Disabling substitutes solves the problem, for those
who have the patience to wait for texlive to build locally.

Cheers,
  Konrad.

bug#52093: Incorrect argument handling in "guix shell"

[Konrad Hinsen]

The following session illustrates that the -D option to "guix shell" is
erroneously applied to *two* package arguments rather than just one if
the first package argument takes the form of a file.

The file "empty-package.scm" is attached, it defines an empty package
with no inputs. The environment defined by the command below should thus
contain only "hello" and "bash", plus the run-time dependencies of
"bash". Instead, it contains the build dependencies of "hello".

$ guix shell --container -D -f empty-package.scm hello
[env]$ cat $GUIX_ENVIRONMENT/manifest
;; This file was automatically generated and is for internal use only.
;; It cannot be passed to the '--manifest' option.
;; Run 'guix package --export-manifest' if you want to export a file
;; suitable for '--manifest'.

(manifest
  (version 3)
  (packages
(("tar"
  "1.32"
  "out"
  "/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("gzip"
  "1.10"
  "out"
  "/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("bzip2"
  "1.0.8"
  "out"
  "/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("xz"
  "5.2.4"
  "out"
  "/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("file"
  "5.38"
  "out"
  "/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("diffutils"
  "3.7"
  "out"
  "/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("patch"
  "2.7.6"
  "out"
  "/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("findutils"
  "4.7.0"
  "out"
  "/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("gawk"
  "5.0.1"
  "out"
  "/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("sed"
  "4.8"
  "out"
  "/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("grep"
  "3.4"
  "out"
  "/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("coreutils"
  "8.32"
  "out"
  "/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("make"
  "4.3"
  "out"
  "/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("bash-minimal"
  "5.0.16"
  "out"
  "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16"
  (propagated-inputs ())
  (search-paths
(("BASH_LOADABLES_PATH"
  ("lib/bash")
  ":"
  directory
  #f)))
  (properties))
 ("ld-wrapper"
  "0"
  "out"
  "/gnu/store/mpa04aq8lblbcviyxywxcsb1zbi0mf39-ld-wrapper-0"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("binutils"
  "2.34"
  "out"
  "/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34"
  (propagated-inputs ())
  (search-paths ())
  (properties))
 ("gcc"
  "7.5.0"
  "out"
  "/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0"
  (propagated-inputs ())
  (search-paths
(("C_INCLUDE_PATH" ("include") ":" directory #f)
 ("CPLUS_INCLUDE_PATH"
  ("include/c++" "include")
  ":"
  directory
  #f)
 ("LIBRARY_PATH" ("lib" "lib64") ":" directory #f)))
  (properties))
 ("glibc"
  "2.31"
  "out"
  "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31"
  (propagated-inputs
(("linux-libre-headers"
  "5.4.20"
  "out"
  
"/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20"
  (propagated-inputs ())
  (search-paths ())
  (properties
  (search-paths
(("GUIX_LOCPATH" ("lib/locale") ":" directory #f)))
  (properties))
 ("glibc"
  "2.31"
  "static"
  "/gnu/store/s3dcqzwqaakv1yx37by9chksdbkgih17-glibc-2.31-static"
  (propagated-inputs
(("linux-libre-headers"
  "5.4.20"
  "out"
  
"/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20"
  (propagated-inputs ())
  (search-paths ())
  (properties
   

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Hi Maxim,

> I agree!  We don't want people to send bug reports every time their
> network is flaky, if this is indeed what has happened.  Would you be
> interested at surveying if that's the case in the current code?  Perhaps
> the right change would then become apparent.

Interested, maybe, but I am already overcommitted until the end of June.
If nobody else works on this before, I can have a look in summer.

Cheers,
  Konrad

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Hi Maxim,

Thanks for your reply!

> Indeed.  I note that the error message that leads to a request to the
> bug report mention it could be due to a network failure, which could
> explain the transient nature of the problem we see here.
>
> Had you tried multiple times in a row with the same failure on that
> commit?

Yes, I tried again later on two different machines, without any problem.

The reason I submitted a bug report is because Guix told me so. I
assumed that even if the root cause was a network issue, something had
then happened that shouldn't happen. If that's not the case, then the
error message should be improved. A minimal improvement would be to say
"Please report unless you see a comment about networking issues above.".

Cheers,
  Konrad.

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Trying the "guix pull" a short while (and one commit to Guix) later, the
error is gone. Which is a bit strange: whatever the cause of the error
was, it's hard to believe that adding the package
"python-sqlalchemy-stubs" (which is what commit
f8a4724c101880892640dcc2fe3438dc2a26b624 did) could fix it.

Konrad.

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Today's "guix pull" resulted in an error message that ends with a
request for a bug report. So here it comes:

===
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: warning: moving channel 'guix' from 
3e4f6d2bbc6f0f81c1487eb1bb69d8e9fe9bdbd7 to unrelated commit 
34985fb6ae7deffd40443766f5408649a0cbbff2
Authenticating channel 'guix', commits 9edb3f6 to 34985fb (777 new commits)...
Building from these channels:
  guix  https://git.savannah.gnu.org/git/guix.git   34985fb
  guix-past https://gitlab.inria.fr/guix-hpc/guix-past  0f892e4
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 module-import  2KiB   25KiB/s 00:00 [##] 100.0%

 module-import-compiled  1.4MiB   1.7MiB/s 00:01 [##] 100.0%

 compute-guix-derivation  1005B 9KiB/s 00:00 [##] 100.0%

Computing Guix derivation for 'x86_64-linux'... |Backtrace:
  13 (primitive-load 
"/gnu/store/jbz265j88niryci4f80zfwq92vjy2xam-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2076:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1910:8  7 (_ _)
In ./guix/gexp.scm:
   256:18  6 (_ _)
   1137:2  5 (_ _)
   1003:2  4 (_ _)
849:4  3 (_ _)
In ./guix/store.scm:
  1958:12  2 (_ #)
   1372:5  1 (map/accumulate-builds # _ _)
  1383:15  0 (_ # _ _)

./guix/store.scm:1383:15: ERROR:
  1. :
  message: "some substitutes for the outputs of derivation 
`/gnu/store/8kj83zhzcfpp7df9jxsyarnkrbvglwri-guile-json-3.5.0.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source "
  status: 1
guix pull: error: You found a bug: the program 
'/gnu/store/jbz265j88niryci4f80zfwq92vjy2xam-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"34985fb6ae7deffd40443766f5408649a0cbbff2"; system: "x86_64-linux";
host version: "3e4f6d2bbc6f0f81c1487eb1bb69d8e9fe9bdbd7"; pull-version: 1).
Please report it by email to .
===

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

[Konrad Hinsen]

zimoun  writes:

> For the record, ’tests/publish.scm’ pass on Debian but not on Ubuntu.

One more data point: the tests pass under Ubuntu 18.04, but fail under
Ubuntu 20.04.

Cheers,
  Konrad.

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

[Konrad Hinsen]

Hi Ludo,

> Is it reproducible?  (You can run “make check TESTS=tests/publish.scm”.)

Yes.

> If it is, could you add ‘pk’ calls here and there to see which of the
> sub-expressions in (and …) returns false?

'pk' shows nothing, but I rolled my own version using plain old
"display" and found that 

   (stat:perms (lstat nar))

is #o664 rather than the expected #o644.

Cheers,
  Konrad.

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

[Konrad Hinsen]

Dear Guix Gurus,

I am trying to compile Guix (commit
1955ef93b76e51cab5bed4c90f7eb9df7035355a) from source, on a computer
running Ubuntu 20.04 with Guix added via a binary installation.  I get
one test failure, whose test-suite.log is attached.

Cheers,
  Konrad.

   GNU Guix UNKNOWN: ./test-suite.log


# TOTAL: 28
# PASS:  27
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/publish
===


;;; (wait-for-file 
"/tmp/guix-directory.nlpLZB/gzip/892j9b0gqgbj4a7sv40jif3yyv25sm90-item.narinfo")
test-name: with cache
location: /home/hinsen/src/guix/tests/publish.scm:417
source:
+ (test-equal
+   "with cache"
+   (list #t
+ `(("StorePath" unquote %item)
+   ("URL"
+unquote
+(string-append "nar/gzip/" (basename %item)))
+   ("Compression" . "gzip"))
+ 200
+ #t
+ #t
+ 404)
+   (call-with-temporary-directory
+ (lambda (cache)
+   (let ((thread
+   (with-separate-output-ports
+ (call-with-new-thread
+   (lambda ()
+ (guix-publish
+   "--port=6797"
+   "-C2"
+   (string-append "--cache=" cache)
+   "--cache-bypass-threshold=0"))
+ (wait-until-ready 6797)
+ (let* ((base "http://localhost:6797/;)
+(part (store-path-hash-part %item))
+(url (string-append base part ".narinfo"))
+(nar-url
+  (string-append base "nar/gzip/" (basename %item)))
+(cached
+  (string-append
+cache
+"/gzip/"
+(basename %item)
+".narinfo"))
+(nar (string-append
+   cache
+   "/gzip/"
+   (basename %item)
+   ".nar"))
+(response (http-get url)))
+   (and (= 404 (response-code response))
+(match (assq-ref
+ (response-headers response)
+ 'cache-control)
+   quote max-age) . ttl)) (< ttl 3600)))
+(wait-for-file cached)
+(= 420 (stat:perms (lstat cached)))
+(= 420 (stat:perms (lstat nar)))
+(let* ((body (http-get-port url))
+   (compressed (http-get nar-url))
+   (uncompressed
+ (http-get
+   (string-append base "nar/" (basename %item
+   (narinfo (recutils->alist body)))
+  (list (file-exists? nar)
+(filter
+  (lambda (item)
+(match item
+   (("Compression" . _) #t)
+   (("StorePath" . _) #t)
+   (("URL" . _) #t)
+   (_ #f)))
+  narinfo)
+(response-code compressed)
+(= (response-content-length compressed)
+   (stat:size (stat nar)))
+(= (string->number (assoc-ref narinfo "FileSize"))
+   (stat:size (stat nar)))
+(response-code uncompressed)
expected-value: (#t (("StorePath" . 
"/home/hinsen/src/guix/test-tmp/store/892j9b0gqgbj4a7sv40jif3yyv25sm90-item") 
("URL" . "nar/gzip/892j9b0gqgbj4a7sv40jif3yyv25sm90-item") ("Compression" . 
"gzip")) 200 #t #t 404)
actual-value: #f
result: FAIL


;;; (wait-for-file 
"/tmp/guix-directory.8sKoZA/gzip/892j9b0gqgbj4a7sv40jif3yyv25sm90-item.narinfo")

;;; (narinfo/gzip+lzip (("StorePath" . 
"/home/hinsen/src/guix/test-tmp/store/892j9b0gqgbj4a7sv40jif3yyv25sm90-item") 
("URL" . "nar/gzip/892j9b0gqgbj4a7sv40jif3yyv25sm90-item") ("Compression" . 
"gzip") ("FileSize" . "86") ("URL" . 
"nar/lzip/892j9b0gqgbj4a7sv40jif3yyv25sm90-item") ("Compression" . "lzip") 
("FileSize" . "99") ("NarHash" . 
"sha256:1xngcmsdkdvaycaqjfzvq4gr3gib56p2l8illglnsqzhpss47pxz") ("NarSize" . 
"120") ("References" . "yfwmjazc6d4grdr7gd05a088s5zi46fr-ref") ("Signature" . 

bug#47190: Building git fails because of a hash mismatch

[Konrad Hinsen]

Léo Le Bouter  writes:

> Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply
> "guix pull", there's nothing we can do to the older commits.

Thanks for the quick fix, this works fine indeed!

Konrad

bug#47190: Building git fails because of a hash mismatch

[Konrad Hinsen]

With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building
git fails because of a hash mismatch when downloading the man pages (see
log below). I'd be happy to submit a patch that updates the hash, but
it's perhaps worth figuring out first what went wrong here.

Konrad.


building 
/gnu/store/lml7vf4rqr9g08bkfwbs3hrchv90zvpb-git-manpages-2.31.0.tar.xz.drv...
downloading from 
http://linux-kernel.uio.no/pub/software/scm/git/git-manpages-2.31.0.tar.xz ...
-sha256 hash mismatch for 
/gnu/store/cp276zg8yn1v0psi49d8ivib41cv99ya-git-manpages-2.31.0.tar.xz:
  expected hash: 1aiabqbc6mg23r19g2cwd4iajf55cpkxqylwn14hgpg64piaqr2y
  actual hash:   1v40wwj130k76xf2w6vwhvfpkk765q1gcy5bqcrqssxf66ydqp8q
hash mismatch for store item 
'/gnu/store/cp276zg8yn1v0psi49d8ivib41cv99ya-git-manpages-2.31.0.tar.xz'
build of 
/gnu/store/lml7vf4rqr9g08bkfwbs3hrchv90zvpb-git-manpages-2.31.0.tar.xz.drv 
failed

bug#26981: Bug report follow up

[Konrad Hinsen]

Hi Robert,

> Konrad, is this bug report still relevant? I suspect not, since it
> seems to have been solved by switching to a more recent version
> of guix 3 years ago.
> The bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26981
> If I don't hear back I'll assume it's safe to close this.

Yes, it is. Thanks for doing a cleanup!

Konrad.

bug#43331: guix repl doesn't find the script to execute

[Konrad Hinsen]

Hi Simon,

> It sounds similar to the recent #42543 [1].  I proposed the fix [2]
> using 'canonicalize-path' but Ludo was not fine with it and then
> committed d10474c38d58bdc676e64336769dc2e00cdfa8ed [3].

Thanks for the references, all that happened while I was on vacation.

There is indeed some parallel, but also an important difference:
the -L option requires searching LOADPATH plus following local relative
filenames. "guix repl" does not search LOADPATH.

But I am happy I didn't use 'canonicalize-path' in my patch ;-)

Cheers,
  Konrad.

bug#43331: Patch

[Konrad Hinsen]

The patch that I just submitted fixes the problem. However,
I don't really know what the cause of the bug is, given
that load-in-vicinity is undocumented and I don't fully
understand its implementation. So maybe there is a better
way to fix this.

Konrad.

bug#43331: [PATCH] repl: Look for script files in (getcwd).

[Konrad Hinsen]

* guix/scripts/repl.scm (guix-repl): Replace "." by (getcwd)
---
 guix/scripts/repl.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm
index 3c79e89f8d..80bf1460e9 100644
--- a/guix/scripts/repl.scm
+++ b/guix/scripts/repl.scm
@@ -178,7 +178,7 @@ call THUNK."
(lambda ()
  (set-program-arguments script)
  (set-user-module)
- (load-in-vicinity "." (car script)
+ (load-in-vicinity (getcwd) (car script)
 
 (when (null? script)
   ;; Start REPL
-- 
2.28.0

bug#43331: guix repl doesn't find the script to execute

[Konrad Hinsen]

Example:

$ guix repl moocrr_guix_jupyter/installed-dependencies.scm
Backtrace:
   1 (primitive-load-path "./moocrr_guix_jupyter/installed-d…")
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure primitive-load-path: Unable to find file 
"./moocrr_guix_jupyter/installed-dependencies.scm" in load path

But the file is there:

$ ls -l moocrr_guix_jupyter/installed-dependencies.scm
-rw-r--r-- 1 hinsen users 783 Sep 11 12:43 
moocrr_guix_jupyter/installed-dependencies.scm

And when given the absolute path, guix finds it as well:

$ guix repl `pwd`/moocrr_guix_jupyter/installed-dependencies.scm
122 packages:
cairo@1.16.0
expat@2.2.9
...

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

[Konrad Hinsen]

Pierre Neidhardt  writes:

> Which "ldd" did you use?  Ubuntu's or Guix'?
> Where did you run it?

Good suggestion. My expectation is that Evan used Ubuntu's ldd, and that
using Guix' will show different results.

> Try exporting LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu in the
> environment in which you run SBCL. 

Guix' ldd has been patched to ignore LD_LIBRARY_PATH, so my prediction
is that this won't change anything.

Cheers,
  Konrad.

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

[Konrad Hinsen]

Pierre Neidhardt  writes:

> Konrad Hinsen  writes:
>
>> Note that this is a feature, not a bug, so if that's the cause of the 
>> problem, there is nothing to do about it. You'd have to compile sbcl 
>> with the toolchain of the foreign distro.
>
> You don't have to use another SBCL.  If you look at how we package
> cffi-based libraries (e.g. sbcl-cl-sqlite), you'll see that we set the
> path to the .so manually to the store location.  This should not raise
> any issue.

Not with shared libraries in Guix, I agree. But the problem was with
shared libraries from the foreign distros. Guix actually tries hard
*not* to make them accessible (in order to ensure reproducibility),
so I wonder if this bug should be closed as "not a bug".

Cheers,
  Konrad.

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

[Konrad Hinsen]

Hi Pierre and Evan,

This seems to be a red herring, as Guix does not change how CFFI loa > libraries.  The only thing that changes is where the libraries are 

found> with Guix packages.
I don't know about the details of SBCL and its CFFI, but there is a 
difference in how Guix handles shared libraries that I discovered 
recently and which might be related.


Programs compiled under Guix don't use the search path feature for 
shared libraries (via Guix' own copy of ldd.so). All references to 
shared libraries use the full path to the store. So if you compile sbcl 
under Guix, it will never look for libraries that are referenced by name 
only (without the full path). The foreign distro probably relies on that 
lookup, as most Linux distros do.


Note that this is a feature, not a bug, so if that's the cause of the 
problem, there is nothing to do about it. You'd have to compile sbcl 
with the toolchain of the foreign distro.


Cheers,
  Konrad.

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Konrad Hinsen]

Hi Ricardo,

> I wonder if we should simply bump the version number to indicate that
> this is a breaking change?

That's a possibility, but who ever looks at Guix version numbers?

> Another more difficult option would be to do what responsible API
> developers on the web do: to version their API and to make the API
> version selectable.  I don’t know *how* to do this elegantly, and

That's an interesting idea which would also take care of similar
situations in the future.

One way to implement this is to have executables "guix1", "guix2"
etc. Most users would then define an alias "guix" for interactive use,
but hopefully script authors would use the versioned executables.

Cheers,
  Konrad.

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Konrad Hinsen]

Hi Simon,

> Assuming "guix environment" would stay and following the proposed
> plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top
> of your script. In this would not be a problem for travelling back in
> time.

The problem is not how I update my scripts - I can manage that, no
matter what it takes.

The problem is scripts circulating in public repositories, tutorials,
etc. New users will find them and use them for inspiration. It's very
discouraging to see examples from tutorials fail or do something weird.

The main precedent is the Python 2->3 transition. There are tons of
GitHub repositories with Python code but no indication if it's 2, 3, or
both. I even had to use one that executed with either 2 or 3, but gave
different results. It takes a lot of motivation to persist.

For guix, there's the additional issue that we use the reproducibility
of builds as an argument. Non-reproducible examples are then a bit of a
credibility problem.

Cheers,
  Konrad.

bug#38529: Deprecating ‘guix environment’?

[Konrad Hinsen]

Hi Ludo,

> Clearly there’s a tension between that and keeping Guix open to changes.

That's indeed the main problem and here as elsewhere, it is often a
topic of heated arguments.

My point of view (long form:
https://hal.archives-ouvertes.fr/hal-02117588)
is that software projects should adopt a backwards compatibility policy
early on, state it clearly in their documentation, and stick to it. That
prevents misunderstandings, bad surprises, and heated debates.

As for what that policy should be for Guix, that's a more difficult
story. For projects with versioned releases, I like the principles
of semantic versioning, but Guix is more of a rolling-release
project. (Test question: does anyone know what the current Guix version
number is? Does anyone care?) I am not aware of any good precedents
in terms of policy for such projects.

> The hard question then becomes: what do we call it?  I vote against
> abbreviations.  :-)
>
> Also, what other goals would we set for that command?  How would we
> frame it in the set of commands?

I vote for discussing the second point before the first one. Names
should reflect the functionality behind them.

How about a unified command for constructing environments and profiles
declaratively? In other words, combine "guix environment" and the
declarative parts of "guix package". We could probably get rid of
the somewhat obscure "guix environment -r" in the process.

Cheers,
  Konrad.

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Konrad Hinsen]

Hi Simon,

> Maybe I miss a point. It is not: "watch out, this will do something
> else in the future" but "watch out, this was doing something else in
> the past and the change happened the  in ".

Concrete example: I am writing a tutorial about using Guix for
reproducible research. It shows several uses of "guix environment", some
of them without '–add-hoc' or '–inputs-of'. I know my examples will
cease to work in a few months. What am I supposed to do about this?

> First, I am not convinced that there is not so much scripts that will
> be broken. And second, I am not convinced neither that these very
> scripts need time-traveling.

Perhaps it's just me, but I use "guix environment" quite a lot in
scripts, in order to make them more reproducible. Here's a simple
example:

   #!/usr/bin/env bash
   guix environment --container --ad-hoc gcc-toolchain <> The first rule of backwards-compatibility is: never change the meaning
>> of an existing valid command/API. Add new valid syntax, deprecate old
>> valid syntax, but don't change the meaning of something that was and
>> will be valid.
>
> I agree on the rule.
> But it is mitigated but the number of users and the popularity of the tool. 
> ;-)

Indeed!

> Yes, it is probably the most adequate to do. But it is sad to loose
> the good name "guix environment"... and we know that naming is hard.
> ;-)

I definitely agree. As a lesson for the future, maybe we should use
not-so-nice names for new commands during a kind of beta-testing phase.

Cheers,
  Konrad

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[Konrad Hinsen]

On 16/12/2019 23:09, Ludovic Courtès wrote:

So in a more algorithmic manner:

1. if ad-hoc and inputs-of is present at the same invocation: fail
hard. (With an error like incompatible options present)
2. if only ad-hoc is present, then print a deprecation warning (yes,
we could make this suspendable with an environment variable, like you
described)
3. if only inputs-of present, then do the new behaviour.
4. if neither ad-hoc nor inputs-of present then
   a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour,
   b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
new behaviour.

That sounds like a good plan to me.

#4 is the trickiest, and I think it’d be good to give users a bit of
time so they can start adjusting before deprecation is in effect.


#4 is trickiest for another reason: there is no future-proof use of 
"guix environment" that works right now and will continue to work. Nor 
is there any way to see, when looking at a command line, whether it's 
old-style or new-style, if neither --ad-hoc nor --inputs-of are present. 
This means that all existing documentation (tutorials etc.) will become 
misleading in the future. Worse, even documentation written today, in 
full awareness of a coming change, can't do better than saying "watch 
out, this will do something else in the future".


The first rule of backwards-compatibility is: never change the meaning 
of an existing valid command/API. Add new valid syntax, deprecate old 
valid syntax, but don't change the meaning of something that was and 
will be valid.


How about a more drastic measure: deprecate "guix environment" and 
introduce a new subcommand with the desired new behaviour?



Cheers,

  Konrad.

bug#30961: Byte compilation problem with emacs-org

[Konrad Hinsen]

Hi Maxim,

> Does this still occur on latest master?

No, the bug disappeared with the update to Emacs 26.3, which comes with
org-mode 9. So this bug report can be closed (which I'd have done
already if I knew how to do it).

Cheers,
  Konrad

bug#38277: biber 2.12 fails to build

[Konrad Hinsen]

Hi Guix,

There is a build failure with biber 2.12 in current Guix
(commit 7b40d59114e1462d6d8140f325a66b12e91db667). The build
log is attached, it shows that several tests fail.

Note that I tried to update to biber 2.13, which builds without
problems, but I then discovered that it is not compatible with the
texlive version we currently have.

Cheers,
  Konrad.



m8crca2ykfvfdd96xv8yn4cvq02cny-biber-2.12.drv.bz2
Description: Binary data

bug#37989: python2-numpy v0.17.3 fails to build

[Konrad Hinsen]

Hi Josh,

Lots of packages including libreoffice transitively depend on
python2-numpy, so this needs some sort of resolution — perhaps simply
pinning python2-numpy to a previous version?


That would be my preferred solution - pin python2-numpy to the last 
NumPy version that supports Python 2, which is most likely 1.16.



However, Python 2 will not
be maintained after the end of 2019, and I'm not sure if there is an
overall Guix-wide migration plan for python2-* packages.


Not that I know, but no matter how this will be handled, Guix is the 
perfect platform for people still depending on Python 2 because they can 
always install packages from an earlier release. Which is a good reason 
to end Python 2 support in Guix by an as up to date package set as possible.



Cheers.

  Konrad.

bug#37505: "make check" fails on a fresh Guix checkout

[Konrad Hinsen]

Konrad Hinsen  writes:

> Konrad Hinsen  writes:
>
>> Unfortunately, a very similar error still blocks compiling a fresh Guix
>> checkout:
>
> Sorry, false alarm. I have been typing in the wrong terminal window.

OK, I triple-checked: there still is a problem. There are two places in
pull.scm that used '~*'. The attached patch removes the second one.

Konrad.

>From 370579d7ac4e01fd66bdf4518d31f7d3bc17a65a Mon Sep 17 00:00:00 2001
From: Konrad Hinsen 
Date: Tue, 1 Oct 2019 17:06:58 +0200
Subject: [PATCH] pull: Do not use '~*', which 'msgfmt' fails to interpret.

Really fixes <https://bugs.gnu.org/37505>.
---
 guix/scripts/pull.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index e018985469..04970cf503 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -314,7 +314,7 @@ to display."
(removed
 (let ((count (length removed)))
   (format (current-error-port)
-  (N_ "  ~*One channel removed:~%"
+  (N_ "  ~a channel removed:~%"
   "  ~a channels removed:~%" count)
   count)
   (for-each display-channel removed
-- 
2.23.0

bug#37505: "make check" fails on a fresh Guix checkout

[Konrad Hinsen]

Konrad Hinsen  writes:

> Unfortunately, a very similar error still blocks compiling a fresh Guix
> checkout:

Sorry, false alarm. I have been typing in the wrong terminal window.
Too many Guix installations in my life ;-)

Konrad.

bug#37505: "make check" fails on a fresh Guix checkout

[Konrad Hinsen]

Ludovic Courtès  writes:

> Konrad Hinsen  skribis:
>
>> e...@boldquot.po:2849: format specifications in 'msgstr[0]' are not a subset 
>> of those in 'msgid_plural'
>> e...@boldquot.po:2856: format specifications in 'msgstr[0]' are not a subset 
>> of those in 'msgid_plural'
>> /gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/msgfmt: found 2 
>> fatal errors
>
> Fixed in 43f7fd8783af1e824904a76115a8ae8ccbb19f06, thanks!

Thanks!

Unfortunately, a very similar error still blocks compiling a fresh Guix
checkout:

   make[5]: Entering directory '/home/hinsen/guix/guix/po/guix'
   sed -e '/^#/d' -e 's/HEADER/en@boldquot.header/g' ./insert-header.sin > 
en@boldquot.insert-header
   en@boldquot:
   en@boldquot:
   msgmerge  --lang=en@boldquot e...@boldquot.po guix.pot -o 
e...@boldquot.new.po
   

 done.
   make[5]: Leaving directory '/home/hinsen/guix/guix/po/guix'
   make[4]: Leaving directory '/home/hinsen/guix/guix/po/guix'
   rm -f e...@boldquot.gmo && 
/gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/msgfmt -c --statistics 
--verbose -o e...@boldquot.gmo e...@boldquot.po
   e...@boldquot.po:2864: format specifications in 'msgstr[0]' are not a subset 
of those in 'msgid_plural'
   /gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/msgfmt: found 1 
fatal error

Cheers,
  Konrad.

bug#37357: Is there a workaround?

[Konrad Hinsen]

Konrad Hinsen  writes:

> I suspect that I am a victim of this bug as well. Is there a workaround?
> I tried removing next, doing another gc to get a clean slate, and then
> re-installed next. But it still complains that it can't find the
> next-gtk-webkit executable.

This actually does work, if you remove older generations of your profile
first that still contain next. So this is a workaround, but a somewhat
radical one because it requires throwing away a lot of stuff.

Konrad.

bug#37357: Is there a workaround?

[Konrad Hinsen]

I suspect that I am a victim of this bug as well. Is there a workaround?
I tried removing next, doing another gc to get a clean slate, and then
re-installed next. But it still complains that it can't find the
next-gtk-webkit executable.

Konrad.

bug#37505: "make check" fails on a fresh Guix checkout

[Konrad Hinsen]

Hi everyone,

on a fresh checkout of today's Guix master branch (commit
b150e83bef766ca67a3931afce36b6cb6c7f8c10), "make check" fails due to problems
with the po files. Log below.

Konrad.

  GEN  doc/os-config-bare-bones.texi
  GEN  doc/os-config-desktop.texi
  GEN  doc/os-config-lightweight-desktop.texi
  PO4A doc/contributing.de.texi
Your input po file po/doc/guix-manual.de.po seems outdated (The amount of 
entries differ between files: 7994 is not 228
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.de.texi
mv "doc/contributing.de.texi.tmp" "doc/contributing.de.texi"
  PO4A doc/guix.de.texi
Your input po file po/doc/guix-manual.de.po seems outdated (The amount of 
entries differ between files: 7994 is not 8111
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.de.texi" | sed 's|texi$|info|')|" 
"doc/guix.de.texi.tmp"
echo 'org_babel_sh_eoe'
  POXREF doc/guix.de.texi
mv "doc/guix.de.texi.tmp" "doc/guix.de.texi"
  PO4A doc/contributing.es.texi
Your input po file po/doc/guix-manual.es.po seems outdated (The amount of 
entries differ between files: 7994 is not 228
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.es.texi
mv "doc/contributing.es.texi.tmp" "doc/contributing.es.texi"
  PO4A doc/guix.es.texi
Your input po file po/doc/guix-manual.es.po seems outdated (The amount of 
entries differ between files: 7994 is not 8111
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.es.texi" | sed 's|texi$|info|')|" 
"doc/guix.es.texi.tmp"
  POXREF doc/guix.es.texi
mv "doc/guix.es.texi.tmp" "doc/guix.es.texi"
  PO4A doc/contributing.fr.texi
Your input po file po/doc/guix-manual.fr.po seems outdated (The amount of 
entries differ between files: 7994 is not 228
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.fr.texi
mv "doc/contributing.fr.texi.tmp" "doc/contributing.fr.texi"
  PO4A doc/guix.fr.texi
Your input po file po/doc/guix-manual.fr.po seems outdated (The amount of 
entries differ between files: 7994 is not 8111
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.fr.texi" | sed 's|texi$|info|')|" 
"doc/guix.fr.texi.tmp"
  POXREF doc/guix.fr.texi
mv "doc/guix.fr.texi.tmp" "doc/guix.fr.texi"
  PO4A doc/contributing.ru.texi
Your input po file po/doc/guix-manual.ru.po seems outdated (The amount of 
entries differ between files: 7994 is not 228
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.ru.texi
mv "doc/contributing.ru.texi.tmp" "doc/contributing.ru.texi"
  PO4A doc/guix.ru.texi
Your input po file po/doc/guix-manual.ru.po seems outdated (The amount of 
entries differ between files: 7994 is not 8111
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.ru.texi" | sed 's|texi$|info|')|" 
"doc/guix.ru.texi.tmp"
  POXREF doc/guix.ru.texi
mv "doc/guix.ru.texi.tmp" "doc/guix.ru.texi"
  PO4A doc/contributing.zh_CN.texi
Your input po file po/doc/guix-manual.zh_CN.po seems outdated (The amount of 
entries differ between files: 7994 is not 228
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.zh_CN.texi
mv "doc/contributing.zh_CN.texi.tmp" "doc/contributing.zh_CN.texi"
  PO4A doc/guix.zh_CN.texi
Your input po file po/doc/guix-manual.zh_CN.po seems outdated (The amount of 
entries differ between files: 7994 is not 8111
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.zh_CN.texi" | sed 's|texi$|info|')|" 
"doc/guix.zh_CN.texi.tmp"
  POXREF doc/guix.zh_CN.texi
mv "doc/guix.zh_CN.texi.tmp" "doc/guix.zh_CN.texi"
  GEN  nix/libstore/schema.sql.hh
echo 1.0.1.3746-b150e > ".version-t" && mv ".version-t" ".version"
make  check-recursive
make[1]: Entering directory '/home/hinsen/guix-from-source/guix'
Making check in po/guix
make[2]: Entering directory '/home/hinsen/guix-from-source/guix/po/guix'
make guix.pot-update
make[3]: Entering directory '/home/hinsen/guix-from-source/guix/po/guix'
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
if LC_ALL=C grep 'GNU guix' ../../* 2>/dev/null | grep -v 'libtool:' 
>/dev/null; then \
  package_gnu='GNU '; \
else \
  package_gnu=''; \
fi; \
if test -n 'l...@gnu.org' || test 'bug-guix@gnu.org' = '@'PACKAGE_BUGREPORT'@'; 
then \
  msgid_bugs_address='l...@gnu.org'; \
else \
  msgid_bugs_address='bug-guix@gnu.org'; \
fi; \
case `/gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/xgettext 
--version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
  '' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].* | 0.16 | 0.16.[0-1]*) \
/gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/xgettext 
--default-domain=guix --directory=../.. \
  --add-comments=TRANSLATORS: --from-code=UTF-8 --keyword=G_ 
--keyword=N_:1,2 --keyword=message 

bug#34998: "guix pull" fails because it cannot build a derivation

[Konrad Hinsen]

Hi Ricardo,

>> Today's "guix pull" ended in a failure that I am supposed to report, so
>> here I do!
>
> This has already been fixed.  Please try again!

I had done so after reading Ludo's comment, and it works fine now!

Thanks,
 Konrad.

bug#34998: "guix pull" fails because it cannot build a derivation

[Konrad Hinsen]

Dear guix team,

Today's "guix pull" ended in a failure that I am supposed to report, so
here I do!

Konrad.



$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   6c177f6
The following derivations will be built:
   /gnu/store/y899zgjln4qdqliwlmrnpwlhljagpzcp-module-import.drv
   /gnu/store/w8c6is708k9cb87fc0kap13y9jf5h76m-module-import-compiled.drv
   /gnu/store/8w23bahr7kj61w222x9iai9m0vagz58l-compute-guix-derivation.drv
building /gnu/store/y899zgjln4qdqliwlmrnpwlhljagpzcp-module-import.drv...
building 
/gnu/store/w8c6is708k9cb87fc0kap13y9jf5h76m-module-import-compiled.drv...
building 
/gnu/store/8w23bahr7kj61w222x9iai9m0vagz58l-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... -Backtrace:
  10 (primitive-load "/gnu/store/5fqbbg0wr2b71azi5n8k0iqfsls?")
In ice-9/eval.scm:
155:9  9 (_ _)
159:9  8 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ./guix/store.scm:
  1737:24  7 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In ./guix/self.scm:
988:2  6 (_ _)
In ./guix/packages.scm:
  1309:17  5 (_ #)
   934:16  4 (cache! # # ?)
  1255:22  3 (thunk)
   934:16  2 (cache! # # ?)
  1039:46  1 (thunk)
In ./gnu/packages/bootstrap.scm:
150:4  0 (inputs)

./gnu/packages/bootstrap.scm:150:4: In procedure inputs:
Wrong number of arguments to #
guix pull: error: You found a bug: the program 
'/gnu/store/5fqbbg0wr2b71azi5n8k0iqfslsiwwi8-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"6c177f6140cba250ad68c5a83c312f395b6e48b4"; system: "x86_64-linux";
host version: "f347fb79df1b174c37a1d277b1c1de36684ed1e7"; pull-version: 1).
Please report it by email to .

bug#33368: "guix archive" fails because of guix-authenticate

[Konrad Hinsen]

Hi Ludo and Ricardo,

> Could you strace the daemon and then re-run the command?
>
>   sudo strace -p $(pidof guix-daemon) -f -o daemon.log -s 234
>   guix archive --export sed > /dev/null
>
> I tested and it works for me, so we’ll have to see what’s going wrong
> behind the scenes.

With the strace log (see below) that's pretty obvious: the daemon
doesn't find the guix-authenticate binary. But where should it be, and
why is it missing on my machine?

> Is the guix-daemon also recent?

A bit less than the rest of guix, but I did update it after the Great
Pull Revolution. The first line of the strace log contains the path in
the store, which should say all there is to know about my daemon.

Cheers,
  Konrad.




15629 
execve("/gnu/store/lm2zy00ciq5pb6gfibvakps7aa1hgz68-guix-daemon-0.15.0-6.f9a8fce/libexec/guix-authenticate",
 ["guix-authenticate", "rsautl", "-sign", "-inkey", 
"/etc/guix/signing-key.sec", "-in", "/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 
vars */) = -1 ENOENT (No such file or directory)
15629 execve("/usr/local/sbin/guix-authenticate", ["guix-authenticate", 
"rsautl", "-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/local/bin/guix-authenticate", ["guix-authenticate", 
"rsautl", "-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/sbin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/usr/bin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/sbin/guix-authenticate", ["guix-authenticate", "rsautl", 
"-sign", "-inkey", "/etc/guix/signing-key.sec", "-in", 
"/tmp/nix-15338-0/hash"], 0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or 
directory)
15629 execve("/bin/guix-authenticate", ["guix-authenticate", "rsautl", "-sign", 
"-inkey", "/etc/guix/signing-key.sec", "-in", "/tmp/nix-15338-0/hash"], 
0x11542d0 /* 17 vars */) = -1 ENOENT (No such file or directory)
15629 openat(AT_FDCWD, 
"/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo",
 O_RDONLY) = -1 ENOENT (No such file or directory)

bug#33365: Package 'direnv' fails to build

[Konrad Hinsen]

Am 13.11.18 um 17:29 schrieb Leo Famulari:


Fixed in commit 978d59737acaadbb0d2aa02ed071bb5d3f555973, which
specifies that Go 1.9 should be used.


Wow, that was quick!

Thanks,
  Konrad.

bug#33368: "guix archive" fails because of guix-authenticate

[Konrad Hinsen]

Dear Guix maintainers,

With guix current as of today (commit
d5401375099f6e4562b849121265bb1c3e85874f), I cannot produce nar archives
because of a failure of guix-authenticate.

Demonstration:

  $ guix archive --export git > git.nar
  guix archive: error: build failed: program `guix-authenticate' failed with 
exit code 1

Note: I did run "guix archive –generate-key" earlier on that machine,
and I do have the public/private keys under /etc/guix.

Cheers,
  Konrad

bug#33365: Package 'direnv' fails to build

[Konrad Hinsen]

Dear Guix maintainers,

after today's "guix pull", I could not update my profile because the
tests of package "direnv" fail. The relevant part of the build log is
attached below. This looks like it might be related to the recent update
of Go to 1.11.

Cheers,
  Konrad.


starting phase `check'
go test
go: disabling cache (/homeless-shelter/.cache/go-build) due to initialization 
failure: mkdir /homeless-shelter: permission denied
# _/tmp/guix-build-direnv-2.11.3.drv-0/direnv-2.11.3
./cmd_stdlib.go:17: Printf format %/ has unknown verb /
FAIL_/tmp/guix-build-direnv-2.11.3.drv-0/direnv-2.11.3 [build failed]
make: *** [Makefile:49: test] Error 2

Test suite failed, dumping logs.
Backtrace:
   4 (primitive-load "/gnu/store/cp8sfpkmpj2wa9wc39bz1hgkwmd…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
640:9  2 (for-each # …)
In 
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:
   799:31  1 (_ _)
369:6  0 (check #:target _ #:make-flags _ #:tests? _ # _ # _ # _)

/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/gnu-build-system.scm:369:6:
 In procedure check:
Throw to key `srfi-34' with args `(#)'.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

[Konrad Hinsen]

Hi Ludo,

> To work around it, you can pull from an older generation, along these
> lines:
>
>   ~/.config/guix/current-42-link/bin/guix pull
>
> (This will work because this older guix won’t attempt to move your
> generations to /var/guix/profiles, so it allows you to “jump over” the
> bug.)
>
> Let me know how it goes!

I cannot try any more because I already used another workaround, meaning
that my profiles are properly migrated.

> It’s terrible that a function like this that looks trivial has been
> causing so much trouble.  Sorry about that.  :-/

Lesson learned: avoid messing around with mutable state. How about
creating a functional package manager?  ;-)

Konrad.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

[Konrad Hinsen]

Hi Ludo,

> If you’re familiar with Dired in Emacs, I’d suggest opening
> /var/guix/profiles/per-user/root and fixing the symlink targets from
> there (with C-c C-q).

Done. And after rebooting, guix seems to work fine for root, including
the download phase. Meaning that I consider this bug fixed.

But there still seems to be some collateral damage, since I could not
use "guix pull" any more on my standard user account:

  $ guix pull
  Migrating profile generations to '/var/guix/profiles/per-user/hinsen'...
  guix pull: error: rename-file: Invalid cross-device link

This looks like guix is trying to use a hard link instead of a symbolic
link somewhere. I found a way around which I describe here for the
benefit of others who might find themselves in the same situation:

 - check out a local copy of the Guix repository 
 - configure and make as described in the manual
 - ./pre-inst-env guix pull

That does the profile migration using the very latest code. After that
the standard guix command seems to work fine again.

Konrad.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

[Konrad Hinsen]

Hi Ludo,


Hmm you might need to run, say, ‘guix pull -l’, to make this script
magically appear.  :-)

Concretely, the new ‘guix pull’ migrates things from ~/.config/guix to
/var/guix/profiles the first time you run it, but it may be that you
haven’t yet run the *new* ‘guix pull’.


That looks like the right direction, since running "guix pull -l" starts 
by saying


   Migrating profile generations to '/var/guix/profiles/per-user/root'...

Unfortunately, its next statement is just as magic but less pleasant:

Backtrace:
   6 (primitive-load "/root/.config/guix/current/bin/guix")
In guix/ui.scm:
  1583:12  5 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9  4 (catch srfi-34 # …)
    829:9  3 (catch system-error # …)
    829:9  2 (catch git-error # …)
    829:9  1 (catch system-error # …)
In unknown file:
   0 (raise #)

ERROR: In procedure raise:
Wrong type (expecting exact integer): # [profile: 
"/var/guix/profiles/per-user/root/current-guix"] 338b460>



This looks like an error in an error-raising procedure, something like  
a meta-error ;-)


Looking at

  ~# ls -l /var/guix/profiles/per-user/root/current-guix
   lrwxrwxrwx 1 root root 14 oct.  15 13:51 
/var/guix/profiles/per-user/root/current-guix -> current-4-link


yields  a link that is indeed missing. What I do have is 
current-guix-4-link, but not a plain current-4-link.


Konrad.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

[Konrad Hinsen]

Hi Ludo,

I believe commit ed9d7cb4d95f8f4776e6fee2778ab52bc2852969 fixes it.

That is, if you run ‘guix pull’ as root and then start
~/.config/guix/current/bin/guix-daemon, everything should be fine.

Let's say the bug seems to be elsewhere now ;-)

When I try to build something after following your instructions, I get 
the error message


/gnu/store/bkkf11ixn67cwcw05nw9w9yd68i4jf23-guix-daemon-0.15.0-5.1d0be47/libexec/guix/download: 
line 8: /var/guix/profiles/per-user/root/current-guix/bin/guix: No such 
file or directory


And indeed there is no guix at that place. I guess it should be

/var/guix/profiles/per-user/root/guix-profile/bin/guix

I can try fixing the download script and testing again, but not before 
next week, sorry!


Konrad.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

[Konrad Hinsen]

Hi Ludo,

> I don’t think you’re doing anything wrong.  Could anyone of you who
> experience this problem strace guix-daemon?  I’ve thought about this and
> don’t understand where that EACCES (“Permission denied”) comes from.
>
> Specifically, you’d have to run something along these lines as root:
>
>   strace -f -p $(pidof guix-daemon) -o log
>
> and then, as root or non-root (it doesn’t matter), run, say:
>
>   guix build curl -S --no-substitutes

The log file (compressed) is attached.

In doing this I noticed that I have two guix-daemon processes running:

root  1583  0.0  0.0  33156  2412 ?Ss   08:55   0:00 
/root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild
root 13003  0.0  0.0  36028  6256 ?Ss   11:28   0:00 
/root/.config/guix/current/bin/guix-daemon 12770

I ran strace on the first one.

Konrad.



guix-daemon-strace.log.gz
Description: application/gzip

bug#32183: Me too!

[Konrad Hinsen]

Hi Ludo and Pjotr,

I just ran into this bug as well:

   ./pre-inst-env guix build python-matplotlib
   @ build-started 
/gnu/store/33hf690qiwrvr0y59g9xwz6rpf3mmbj6-matplotlib-2.2.3.tar.gz.drv - 
x86_64-linux 
/var/log/guix/drvs/33//hf690qiwrvr0y59g9xwz6rpf3mmbj6-matplotlib-2.2.3.tar.gz.drv.bz2
   
/gnu/store/1w41y8q12r3dw8iphl5rpkr508881y50-guix-daemon-0.15.0-2.8bbb79c/libexec/guix/download:
 line 8: /root/.config/guix/current/bin/guix: Permission denied
   
/gnu/store/1w41y8q12r3dw8iphl5rpkr508881y50-guix-daemon-0.15.0-2.8bbb79c/libexec/guix/download:
 line 8: exec: /root/.config/guix/current/bin/guix: cannot execute: Permission 
denied
  ...
  (resulting build failure etc., nothing interesting)

This is on recent source code checkout (commit
fefe17b0888b467383ea91fed73a9586295c49f0) with a small modification
(update of hdf5 to 1.10.3).

My guix-daemon is started via systemd at boot time, so it should run as
root. It's from root's guix, which is about two weeks old and has not
caused any trouble before.

Konrad.

bug#22629: “Stable” branch

[Konrad Hinsen]

Hi Ludo,

> What do you mean by “limit it to channels”?  ‘%default-channels’ is an
> alias for the official Guix channel (IOW, Guix itself.)

Fine, but I rarely care about all of Guix, or all of any other channel.
I care about the small subset of packages that I actually use.

Better yet, with a per-manifest/profile approach, I could put my most
critical packages in a special profile and get updates for them more
quickly, while still working only with substitutes.

BTW, just out of curiosity: for how many commits in Guix history all
packages could be built successfully? Is that the rule of the exception?

> Yes, we could do that, and even maybe more sophisticated things (e.g.,
> looking at the commit log to determine whether security fixes are
> available, and adjusting the strategy accordingly.)

Nice!

> What I find interesting is that we can provide the tools to support such
> policies, and then users can choose or implement the policy they want
> directly in ~/.config/guix/channels.scm.

I agree, it's nice to give people the tools they need to implement their
own policy.

Konrad.

bug#32022: bug#22629: “Stable” branch

[Konrad Hinsen]

Hi Ludo,

> I just had a bright idea (yes!): this can be addressed by writing
> something like this in ~/.config/guix/channels.scm:
>
>   (map latest-commit-with-substitutes-available
>%default-channels)
>
> The hypothetical ‘latest-commit-with-substitutes-available’ would use
> (git) and (guix ci) to find the latest commit for which substitutes of
> interest are available, and would return:

I really like that idea, but it's a pity to limit it to channels.
Two scenarii I'd like to see covered are:

 1) Find the latest commit with all substitutes required by a given
manifest.

 2) Find the latest commit with all substitutes required for updating a
given profile.

This is in fact only one problem with two user interfaces.

Konrad.

bug#22629: “Stable” branch

[Konrad Hinsen]

Hi Ludo and Alex,


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

> These are all things that very rarely, if ever, changed over the last 5
> years.  I expect the change rate to remain the same.  :-)

That's reassuring!

> You seem to be arguing of a “stable” branch in the sense that the Guix
> tools (the CLI in particular) wouldn’t change much, is that correct?
>
> I’m asking because there are several ways to define “stable.”  Initially
> I thought what you had in mind was like the “stable” branch in Debian,
> meaning that packages only get security updates.  To me that’s a
> different thing.

What I have in mind is whatever it takes to build a stable software
system. That includes stable ingredients (packages) but also stable
glue, meaning the package definitions and the build system that produces
the binaries from them.  Stability of the Guix CLI is much less relevant
from my point of view.


Alex Sassmannshausen  writes:

> I don't know if this is what Konrad desires, but from my perspective, a
> desirable part of the definition of stable would be a that the build
> farms have produced a set of binaries/substitutes for a given Guix
> revision that is "good enough".

That's another very practically relevant notion of stability. Mine goes
beyond that though. For example, I'd require all packages to build and
pass tests at all times.

Konrad.

bug#22629: Channels not needed for a stable branch

[Konrad Hinsen]

Hi Mark,

> I'm not sure what you're trying to argue above.  To me, it looks like an
> argument in favor of my position, namely that a stable version of Guix
> should include _all_ of Guix, not just the packages.

All, probably not, some, probably yes. What I am arguing is that the
productive coexistence of a stable version with the bleeding-edge
version requires agreement on a stable foundation. Where exactly the
borderline lies between this foundation and what is built on top of it
is not a question I am sufficiently qualified to answer.

The minimal stable foundation would have to include the file system
layout of profiles, to make sure that users can mix packages from both
versions safely. It would also be highly desirable to share the store,
whose layout would then have to be part of the foundation as well.

Moreover, I suspect it would be preferable or even necessary to have
only one daemon running - if that's true, then the daemon's
communication protocol would have be part of the foundation as well.

Without a common foundation, a stable version would have to be a
completely autonomous fork, which should then probably adopt a different
name as well. I don't think this is desirable, in particular for GuixSD
which would lose most of its interest if it required multiple package
managers.

Konrad.

bug#22629: Channels not needed for a stable branch (was: Channels!)

[Konrad Hinsen]

Hi Ricardo,

> I also agree with you that we don’t need channels for providing a stable
> branch.  The biggest obstacle to providing a stable branch is not
> technical, but it requires people maintaining it.

Look at this from the opposite end: if you were interested in
maintaining a stable software distribution, would you choose a quickly
evolving package manager such as Guix as the basis? I'd say no, and I am
speaking from experience because I did actually maintain stable software
installations for a couple of years. You want to concentrate on critical
bug fixes and avoid anything else that could perturb the stability of
your system.

For me this whole discussion isn't about technicalities. Channels are
just a convenience layer on top of what can already be done with
GUIX_PACKAGE_PATH and manifest files. The real issue is how such
features are advertised: as a way to bolt on your own developments,
following Guix evolution closely, or as a way to provide decoupled
autonomous branches such as stable software.

So I agree with Ludo that a communication along the lines of

> I had this example in mind too: the kernel technically supports
> out-of-tree modules, but kernel developers have always resisted pressure
> to freeze APIs.
>
> Because this policy has been stated upfront very clearly and has
> remained unchanged, out-of-tree module developers know that that the
> compatibility burden is on them.  There’s flexibility, along with a
> strong incentive to get things in the mainline kernel.

should be sufficient to avoid the issue that Mark has raised here.
But it also discourages people interested in stable software
installations from using or contributing to Guix.

Konrad.

bug#22629: Channels!

[Konrad Hinsen]

Hi Ludo,

> Mark’s concern is not about whether packages are the latest version,
> etc.  It’s about the constraints that could result from widespread
> development of channels outside Guix proper: technically all of Guix is

That's how I understood it as well. If/when Guix becomes somebody else's
dependency, then there will be pressure on stability in Guix itself.

My point is that this will happen anyway if Guix is adopted more widely.
Every manifest file, personal or shared as part of a software package
("guix.scm"), relies on the same technical details as a
channel. Introducing channels only makes the issue more visible.

And this is really the same issue as with the stability of the packages
themselves, Guix being a kind of superpackage. Most people want agility
for the software layer they are most concerned with, and stability for
all layers below it. For Mark (and certainly others here), Guix happens
to be the layer they are most concerned with.

> I’d rather not build fancy mechanisms just for the sake of external
> channels, and I certainly don’t want to commit to API stability.  We

At this point, certainly not. But I agree with Mark that, if channels
"take off", there will be pressure in that direction.

Konrad.

bug#22629: Channels!

[Konrad Hinsen]

Hi Mark,

I'd like to say again that I have grave concerns that this could be the > death-knell for long-term innovation in Guix.  It's likely that 
whenever> a change is proposed that will break these third-party 
channels, there> will be resistance, and efforts to preserve backward 
compatibility.
I understand your point, but the problem you mention is, in my opinion, 
not so much due to channels but due to different priorities of different 
users. Which means that it will come up even without channels as the 
Guix user base grows.


Look at the wider Linux world: there are people who want to live on the 
bleeding edge and run Arch Linux, and there are others who value 
stability and run CentOS. Today's Guix is more on the bleeding edge 
side. My understanding of your commment is that you would like to make 
sure it stays there. But that also means severely limiting Guix' 
potential user base.


I see channels as an opportunity to have Guix "dialects" addressing 
different needs and yet remain interoperable, although I am the first to 
admit that I have no clear idea of how this would work out in practice, 
more from the social than the technical point of view. But the goal 
looks very attractive. Looking at my own use of Guix, I am happy with 
its bleeding edge approach for the software I use for research, but I'd 
much prefer a slower pace and more stability for stuff like Emacs and 
TeX that are "boring infrastructure" for me.



Even things as seemingly innocuous as moving a package from one module
to another will impact these third-party channels, not to mention
changing our internal APIs or making fundamental changes to the way
packages are specified.


So... could we reduce the dependence of package specifications on such 
things? Package definitions use a small DSL that could be versioned, 
allowing change while maintaining compatibility. Module dependencies are 
more annoying, but do we need them? Package definitions are grouped into 
modules mostly for convenience. All packages have globally unique names, 
so could we use those to specify inputs?


Konrad.

bug#32316: Thanks!

[Konrad Hinsen]

Hi Julien,

I missed your reply because it arrived while I was on vacation, so I was
made aware of it only by the message about the bug being closed.

Thanks for your clear explanation, I will uninstall guix from my
profile!

Konrad.

bug#30680: [PATCH] Patch Racket to fix bug #30680

[Konrad Hinsen]

Timothy Sample  writes:

> Oops!  My fault.  The patch is attached here.  *crosses fingers*

I have ported the patch to Racket 7.0, the modified version is attached.
It gets rid of all the store-related error messages I got when
installing packages with raco, so as far as I am concerned the bug
is indeed fixed.

BTW, the patch (to Guix) for updating Racket to 7.0 is at

 https://debbugs.gnu.org/32355

(but does not yet include this patch to Racket).

Thanks a lot for resolving this issue!

Konrad.

>From da6defb46b69dfb55e5188ed851f5c1443f748ba Mon Sep 17 00:00:00 2001
From: Konrad Hinsen 
Date: Mon, 13 Aug 2018 14:50:37 +0200
Subject: [PATCH] Patch for compilation under Guix

(Port to Racket 7.0 of Timothy Sample's patch for Racket 6.12)

Racket uses checksums to test if it needs to recompile its source
files to bytecode.  If Racket is updated by grafting, the source and
bytecode files get updated, but the checksum stays the same.  Since
the checksum no longer matches the source file, Racket tries to
regenerate the bytecode and write it to the store, causing errors
because the store is immutable.  This patch makes Racket ignore
checksums for files in the store.

See <https://debbugs.gnu.org/30680> for details.
---
 collects/compiler/private/cm-minimal.rkt | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/collects/compiler/private/cm-minimal.rkt b/collects/compiler/private/cm-minimal.rkt
index a5a5407..15af6b8 100644
--- a/collects/compiler/private/cm-minimal.rkt
+++ b/collects/compiler/private/cm-minimal.rkt
@@ -7,6 +7,7 @@
  racket/list
  racket/path
  racket/promise
+ racket/string
  openssl/sha1
  setup/collects
  compiler/compilation-path
@@ -543,6 +544,10 @@
   #f
   (list src-hash recorded-hash)))
 
+(define (store-reference? path)
+  (let ([store-prefix (or (getenv "NIX_STORE") "/gnu/store")])
+(string-prefix? (path->string path) store-prefix)))
+
 (define (rkt->ss p)
   (if (path-has-extension? p #".rkt")
   (path-replace-extension p #".ss")
@@ -595,7 +600,8 @@
   (trace-printf "newer src... ~a > ~a" path-time path-zo-time)
   ;; If `sha1-only?', then `maybe-compile-zo' returns a #f or thunk:
   (maybe-compile-zo sha1-only? deps path->mode roots path orig-path read-src-syntax up-to-date collection-cache new-seen)]
- [(different-source-sha1-and-dep-recorded path deps)
+ [(and (not (store-reference? path))
+   (different-source-sha1-and-dep-recorded path deps))
   => (lambda (difference)
(trace-printf "different src hash... ~a" difference)
;; If `sha1-only?', then `maybe-compile-zo' returns a #f or thunk:
-- 
2.18.0

bug#32316: Build failure with installed guix that does not happen with pre-inst-env

[Konrad Hinsen]

Hi Björn,

> thanks for the precise error report.

Thanks for your quick reply!

> Could it be the case that in your `guix build ...` you are not using
> the guix you pulled?
>
> What does `guix --version` say?
>
> Where does `which guix` point to?
>
> It should point to
>
> ~/.config/guix/current/bin/guix

It points to $HOME/.guix-profile/bin/guix, and since I have the package
"guix" installed in my profile, that looks OK to me. At the very least I
am used to it: guix has always been in my profile, and has always worked
well that way.

But I do see how this could cause various failures after a guix pull,
because the guix in my profile has to work with the updated stuff the
pull has placed under ~/.config. So perhaps the real mystery is that I
haven't had any trouble before. And I wonder what strategy to adopt to
avoid it - remove guix from my profile? There was a good reason to
install it last year, but I don't remember what it was. If installing
guix into a profile is not a good idea, perhaps the guix package should
disappear or be renamed to something that indicates its true purpose?

BTW, since I updated my profile with the pre-inst-env guix, I now also
have a new guix in my profile and the build failure has disappeared.

Konrad.

bug#30921: Jupyter uses the wrong Python.

[Konrad Hinsen]

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

>> Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
>> A standard installation of Jupyter via PyPI also installs a kernel for
>> the same Python interpreter that is used for Jupyter. Additional kernels
>> can then be installed afterwards.
>
> So my understanding is that there’s no bug on our side, right?

That depends on what you call a bug.

The current behavior of the Guix package for Jupyter is not in conflict
with any written documentation for Jupyter, but does not respect a
convention that standard installations (via pip, for example) do
respect. This convention says that the default Python kernel for Jupyter
uses the same Python installation as Jupyter itself.

I'd vote for respecting this convention, and I'd be happy to work on an
implementation, but don't count on me for this before August.

Konrad.

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Konrad Hinsen]

Hi Ludo,

>> Fine, so if I run update-guix-package.scm and then do the install, I get
>> what I expect, right?
>
> Yes (even with current ‘master’), but it’s quite heavyweight since you
> end up recompiling all of Guix.

Not great, but doable from time to time.

>> I am looking for a reasonably straightforward way to have everything in
>> my Guix universe (the guix command line tool, emacs-guix, guile, geiser,
>> ...) consistently use my personal version of the package definitions.
>
> Would ‘guix package --manifest’ suffice?  Perhaps along with ‘guix pull
> --commit=XXX’?

'guix pull --commit=XXX' would be of use if it works with an URL
pointing to a local repository (haven't tried yet). I'd also
have to point GUILE_LOAD_PATH to wherever 'guix pull' stores the source
code tree, which looks doable as well if that's a stable location.

> In the not-too-distant future I think we can add some sort of manifest
> support for ‘guix pull’ such that you can store the list of channel URLs
> and commit IDs in one file and instantiate that.

That sounds really nice :-)

Thanks for all the good stuff BTW!

Konrad.

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Konrad Hinsen]

Hi Ludo,

>> Just wondering: does this mean that I could substitute Guix from my local
>> source tree simply by doing
>>
>>./pre-inst-env guix package -p ~/.config/guix/current -i guix
>
> That would just install the snapshot that the ‘guix’ package refers to
> (it’s defined in (gnu packages package-management)).)

Fine, so if I run update-guix-package.scm and then do the install, I get
what I expect, right?

I am looking for a reasonably straightforward way to have everything in
my Guix universe (the guix command line tool, emacs-guix, guile, geiser,
...) consistently use my personal version of the package definitions.

> Now, installing Guix in your main profile is probably not a good idea.
> Since Guix it what allows you to manage the profile in question, it’s
> probably better to keep it separate.  That way, ‘guix’ is managed

Yes, that makes sense.

Konrad.

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

[Konrad Hinsen]

Hi Ludo,

> The major difference is that instead of just building a bunch of modules
> and putting them under ~/.config/guix/latest, it now produces a
> standalone package (with bin/guix, share/info/guix.info, etc.) and puts
> it in a profile under ~/.config/guix/current.  Quoth the manual:

This sounds like a very nice improvement, thanks!

Just wondering: does this mean that I could substitute Guix from my local
source tree simply by doing

   ./pre-inst-env guix package -p ~/.config/guix/current -i guix

Or, in fact, not use ~/.config/guix/current at all and just install
"guix" into my main profile?

Konrad.

bug#30961: Byte compilation problem with emacs-org

[Konrad Hinsen]

Konrad Hinsen <konrad.hin...@fastmail.net> writes:

> I tried to remove the old org-mode from load-path during byte
> compilation of the new version by manipulating EMACSLOADPATH, so far
> without success. If Emacs' basic "lisp" dir is not on EMACSLOADPATH,

I managed to do this in the end, and it does solve the problem. So it
seems that merely having the old version on load-path, without ever
loading it, is sufficient to break byte compilation of the new version.

I will try to prepare a patch for fixing this.

Konrad.

bug#30961: Byte compilation problem with emacs-org

[Konrad Hinsen]

An Emacs installation that includes package emacs-org exhibits a
well-documented bug: certain uses of org-babel, such as using the
R language, lead to the error message

   Invalid function: org-babel-header-args-safe-fn

For a discussion of this bug in other contexts, see for example:

   https://lists.gnu.org/archive/html/emacs-orgmode/2016-02/msg00415.html

I do not claim to fully understand the cause of this bug, but the
explanations mention a conflict between the org-mode version shipped
with Emacs and the later one being installed afterwards. This conflict
happens when the newer org-mode is byte-compiled, and leads to wrong
.elc files.

It is easy to verify that the Guix version also suffers from this
byte-compilation problem. Removing the "build" step, and thus byte
compilaion, by adding

(arguments
 `(#:phases
   (modify-phases %standard-phases
 (delete 'build

to the definition of emacs-org removes the error message.

What I do not understand yet is why this happens within Guix. The
explanations for the bug concentrate on the built-in org-mode version
having been initialized before byte compilation of the new one, and
recommend starting Emacs with the –quick option for the byte compilation
session. This is what Guix does as well, so the problem should not
exist.

I tried to remove the old org-mode from load-path during byte
compilation of the new version by manipulating EMACSLOADPATH, so far
without success. If Emacs' basic "lisp" dir is not on EMACSLOADPATH,
Emacs fails to do anything, but if it is, Emacs automatically adds
"lisp/org" via lisp/subdir.el.

Konrad.

bug#30921: Jupyter uses the wrong Python.

[Konrad Hinsen]

Ricardo Wurmus  writes:

> I wonder if that’s by design.  As far as I understand Jupyter can be
> used with many different kernels, including different versions of
> Python.  This means that we may not limit it to just a single version of
> Python at build time.
>
> Is this correct?

Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
A standard installation of Jupyter via PyPI also installs a kernel for
the same Python interpreter that is used for Jupyter. Additional kernels
can then be installed afterwards.


Fis Trivial  writes:

> Actually the only command I know about jupyter is how to open a
> notebook :) . But it asks me to restart the kernel again and again in
> browser. And according to the console, it seems that jupyter couldn't

You could run

   jupyter kernelspec list

to see which kernels Jupyter actually uses.

Konrad.

bug#30680: Installation of Racket packages tries to write to the store

[Konrad Hinsen]

Hi everyone,

After installing Racket:

   guix package -i racket

I tried to install a Racket package:

   raco pkg install sxml

I'd expect this to install the package "sxml" into $HOME/.racket, as it
does when Racket is installed via Debian.

It actually does this, and the package is usable and looks complete
(when comparing with an installation on another machine). However, for
bigger packages some compilation results are missing from $HOME/.racket.

There is a long list of errors (full log below) due to Racket trying to
write to locations in the store. The paths suggest that these are
temporary files, and that the location they are written to is completely
bogus (it's the directory that holds the openssl module).

I traced this back as far as I could by looking at the Racket compiler
source code. Compilation generates a temporary file in the same
directory where the result is supposed to go. If no errors occur, the
temporary file is then renamed to become the output. The partial stack
traces point to locations in the code that do a recursive traversal of
a library in order to compile everything. Unfortunately, the part that
decides where the output goes is not referenced in the stack trace.

Konrad.




$ raco pkg install sxml
Resolving "sxml" via https://download.racket-lang.org/releases/6.11/catalog/
Resolving "sxml" via https://pkgs.racket-lang.org
Downloading repository github://github.com/jbclements/sxml/master
raco setup: version: 6.11
raco setup: platform: x86_64-linux [3m]
raco setup: installation name: 6.11
raco setup: variants: 3m
raco setup: main collects: 
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects
raco setup: collects paths: 
raco setup:   /home/hinsen/.racket/6.11/collects
raco setup:   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects
raco setup: main pkgs: 
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/pkgs
raco setup: pkgs paths: 
raco setup:   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/pkgs
raco setup:   /home/hinsen/.racket/6.11/pkgs
raco setup: links files: 
raco setup:   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/links.rktd
raco setup:   /home/hinsen/.racket/6.11/links.rktd
raco setup: main docs: 
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/doc/racket
raco setup: --- updating info-domain tables ---
raco setup: updating: /home/hinsen/.racket/6.11/share/info-cache.rktd
raco setup: --- pre-installing collections ---
raco setup: --- installing foreign libraries ---
raco setup: --- installing shared files ---
raco setup: --- compiling collections ---
raco setup: --- parallel build using 4 jobs ---
raco setup: 3 making: /sxml/sxml (sxml)
open-output-file: cannot open output file
  path: 
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/openssl/compiled/tmp15200075491520007549081
  system error: Permission denied; errno=13
  compilation context...:
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/access-remote.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/id.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ssax/multi-parser.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/xpath-context_xlink.rkt
   /home/hinsen/.racket/6.11/pkgs/sxml/sxml/ddo-axes.rkt
  context...:
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/private/more-scheme.rkt:261:28
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/racket/file.rkt:199:0:
 call-with-atomic-output-file20
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:363:0:
 compile-zo*
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:572:26
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:564:42
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0:
 compile-root
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0:
 ormap-strict
   [repeats 1 more time]
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0:
 compile-root
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0:
 compile-root
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:688:15
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:723:0:
 ormap-strict
   
/gnu/store/wnqdzv3f0i86nk3nq15aavpb7kg7fbwx-racket-6.11/share/racket/collects/compiler/cm.rkt:635:0:
 compile-root
   

bug#25296: fully functional desktop installation

[Konrad Hinsen]

Hi,


Hmm, OK.  Do you think it’s too much to ask, given the current audience
(tinkerers), to add those packages to their config, or to install them
with “guix package -i”?

Admittedly this is a very subjective issue.


How about organizing Guix in a layered way, with the core distribution 
containing narrow-purpose packages (mostly one piece of software), and 
another layer (in a distinct module, perhaps with a distinct naming 
convention) containing collections of software that works well together 
or is useful for a specific application domain? I see other use cases 
than just desktop stuff.


The main rationale for distinct layers is that assembling software at 
different levels requires different competences and different ways of 
documenting the assemblies. In the long run, I'd expect different people 
to be in charge of each layer.


Konrad.

bug#30121: python-matplotlib broken.

[Konrad Hinsen]

On 15/01/2018 17:41, Konrad Hinsen wrote:


After a quick look at the definition of python-matplotlib, I suspect
that python-pyqt should be a propagated-input, not a plain input.
I will try this out as soon as possible.


That was indeed the cause of the bug. I have submitted a patch:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30135

Konrad.

bug#30121: python-matplotlib broken.

[Konrad Hinsen]

Fis Trivial  writes:

>> Do you have a matplotlibrc file that sets a Qt-based backend? The default 
>> backend is TkAgg, which does not require Qt. (Note that PySide is a Qt 
>> interface for Python.)
>> 
> I myself have never created such a file.
>
> I searched home with `find . -iname "*matplotlib*"`, didn't find the rc file
> you mentioned except in some virtualenvs. But that should not be related.
>
> By searching /etc as root, didn't find it either.

After some more checks, I can confirm your bug report. Matplotlib
actually does use Qt by default under Python 3. I still use Python 2
for most of my work, and under Python 2 matplotlib uses TkAgg as its
default backend.

After a quick look at the definition of python-matplotlib, I suspect
that python-pyqt should be a propagated-input, not a plain input.
I will try this out as soon as possible.

Konrad.

bug#30121: python-matplotlib broken.

[Konrad Hinsen]

On 15/01/2018 14:04, Fis Trivial wrote:


* Steps to reproduce:

$ python

from matplotlib import pyplot


Do you have a matplotlibrc file that sets a Qt-based backend? The 
default backend is TkAgg, which does not require Qt. (Note that PySide 
is a Qt interface for Python.)


Konrad.

bug#27080: ¨make install" fails because of missing gawk

[Konrad Hinsen]

Hi Ludo,


Next, I replaced this line by

  AWK = /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/gawk

and re-ran "make install". Success!


Could it be that there was a cache file here (‘config.cache’, as created
by “./configure -C”)?


There is no config.cache, and I never used -C. Plus I do "make 
distclean" all the time.


> In that case
> 


> should be helpful if you haven’t seen it already!

Just did. Looks like what I need.

Thanks,
  Konrad.

bug#27080: ¨make install" fails because of missing gawk

[Konrad Hinsen]

Ricardo Wurmus  writes:

> You are correct, however, that building from source and running “make
> install” *will* install Guix to the specified prefix.  What I’m pretty
> sure does *not* happen, though, is that this *overwrites* any files that
> Ubuntu (or any other system) uses.  It is well-behaved in that it
> installs things into the expected directories under the given prefix.

It does put everything into the correct directories, but that doesn't
prevent version conflicts with my Ubuntu installation. If I remember
correctly it was the locale definitions that were not compatible.

> (With the “pre-inst-env” script it’s possible to run Guix without
> installing it, so you don’t even have to run “make install” at all if
> you just want to bootstrap Guix.)

That's a useful suggestion, thanks! All I want to do is develop my own
package definitions, and eventually contribute them to the official
distribution. All I need is a way to run Guix-from-source under my user
account.

Konrad.

bug#27080: ¨make install" fails because of missing gawk

[Konrad Hinsen]

On 26/05/2017 18:44, Ricardo Wurmus wrote:


I don’t think it ever behaved like that, because it hardly has anything
to install.  Hence I don’t think there have been any changes.  Without
additional details it’s not very productive to talk about this, though.


I am beginning to wonder if this is part of the anomalies I observe, 
because I agree that guix shouldn´t need to install anything beyond its 
entry point, the executable /usr/local/bin/guix. But on my system, it 
installs 1877 files under /opt/guix, and all those would probably go to 
/usr/local by default.


Proof:

> find /opt/guix -type f | wc -l
1877

1273 of these files are under share:

> find /opt/guix/share -type f | wc -l
1273
> ls /opt/guix/share/
guile  guix  info  locale  man  zsh



No, the configure script is probably okay.  Maybe something’s up with
your environment.  Have you tried “guix environment --pure guix”?


I just did. No difference. Same config.log, same Makefile, same error
messages.


Could you share the output of “env” within the pure guix environment?


Sure:

CPLUS_INCLUDE_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/include
GUIX_LOCPATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/lib/locale
TERM=dumb
LIBRARY_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/lib
USER=hinsen
LS_COLORS=
GUILE_LOAD_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/share/guile/site/2.2
GUIX_ENVIRONMENT=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile
GUILE_LOAD_COMPILED_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/lib/guile/2.2/site-ccache:/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/share/guile/site/2.2
PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin:/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/sbin
C_INCLUDE_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/include
PWD=/home/hinsen/Development/guix
SHLVL=1
HOME=/home/hinsen
BASH_LOADABLES_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/lib/bash
LOGNAME=hinsen
PKG_CONFIG_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/lib/pkgconfig
INFOPATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/share/info
ACLOCAL_PATH=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/share/aclocal
DISPLAY=:0
_=/gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/env


Konrad.

bug#27080: ¨make install" fails because of missing gawk

[Konrad Hinsen]

On 26/05/2017 16:56, Ricardo Wurmus wrote:


in order to prevent Guix from overwriting some of Ubuntu's system files.


Guix will not overwrite any system files.  It only writes to /gnu,
/var/guix, and /etc/guix.


It did when I first tried install-from-source a few months ago, and it 
took me a while to clean up the mess. More precisely, it put a lot of 
stuff into /usr/local, overwriting files in /usr/local/share that 
Ubuntu-installed software depended on. If that has changed in the 
meantime, that's great.



No, the configure script is probably okay.  Maybe something’s up with
your environment.  Have you tried “guix environment --pure guix”?


I just did. No difference. Same config.log, same Makefile, same error 
messages.


Konrad.

bug#27080: ¨make install" fails because of missing gawk

[Konrad Hinsen]

I am trying to build/install Guix 0.13 from sources (git checkout), 
using a binary installation of a slightly earlier Guix in a Ubuntu 16.04 
host system. Basically I am doing


  git checkout v0.13.0
  guix environment guix
  make check
  make install

I have also tried with this the most recent commit on master, with the 
same failure.


The trouble starts here:

...
Compiling Scheme modules...
guile: warning: failed to install locale
 /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/mkdir -p 
'/opt/guix/share/man/man1'
 /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/install -c -m 
644 ./doc/guix.1 ./doc/guix-archive.1 ./doc/guix-build.1 
./doc/guix-challenge.1 ./doc/guix-download.1 ./doc/guix-edit.1 
./doc/guix-environment.1 ./doc/guix-gc.1 ./doc/guix-hash.1 
./doc/guix-import.1 ./doc/guix-lint.1 ./doc/guix-package.1 
./doc/guix-publish.1 ./doc/guix-pull.1 ./doc/guix-refresh.1 
./doc/guix-size.1 ./doc/guix-system.1 ./doc/guix-daemon.1 
'/opt/guix/share/man/man1'
 /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/mkdir -p 
'/opt/guix/share/guile/site/2.2'

/bin/bash: line 5: gawk: command not found
sed: couldn't write 47 items to stdout: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
...

I get lots of copies of these "Broken pipe" lines. Then:

...
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
 /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/mkdir -p 
'/opt/guix/share/guile/site/2.2'

/bin/bash: line 5: gawk: command not found
sed: couldn't flush stdout: Broken pipe
 /gnu/store/2kgp5d4wh40b49gp4qwqh2b4il29gq6g-profile/bin/mkdir -p 
'/opt/guix/lib/guile/2.2/site-ccache'

/bin/bash: line 5: gawk: command not found
sed: couldn't write 47 items to stdout: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
/bin/bash: line 5: echo: write error: Broken pipe
...

and another round of broken pipes. But the initial problem seems to be 
that gawk is not found. It is available in my build environment, but 
apparently that's not where it is looked for.


Konrad.

bug#26981: Test failure in guix (commit 872a6fd98868d345443f04efdfd974d148c57f9d)

[Konrad Hinsen]

Hi Ludo,


What does “uname -r” report on your system?

4.4.0-78-generic

It's an up-to-date Ubuntu 16.04 installation.


(This functionality is used only by the container facilities of ‘guix
environment’ and ‘guix system’, so you shouldn’t take it as a blocker.)


OK, then I will just go ahead and switch to "guix from git".

Thanks,
 Konrad.