Re: Listing the files of a package output

[Konrad Hinsen]

Hi Guillaume,

> As the directory of the "out" output will have a shorter name, you could
> sort the names by size and take the first one:
>
> --8<---cut here---start->8---
> for name in $(guix build coreutils); do printf "%d\t%s\n" "${#name}" 
> "${name}"; done | sort -n | head -n 1 | cut -f 2
> --8<---cut here---end--->8---

Indeed, thanks! A but lengthy by my taste, but it does the job!

Cheers,
  Konrad.

Listing the files of a package output

[Konrad Hinsen]

Hi Guix,

this looks like a beginner's question, but I can't figure out how to do
this: list the files in a given package output, from the command line (I
do know how to do this in Guile).

For a package with a single output, I can do

  ls -R $(guix build hello)

For a package output other than "out", I can do

  ls -R $(guix build coreutils | grep debug)

But what about coreutils:out?

Cheers,
  Konrad

Re: Permanently available environments

[Konrad Hinsen]

Hi Ludo,

> Another option is to rely on the ‘time-machine’ and ‘shell’ LRU caches.
> That is, you can run:

That's what I did in the past, until the first time I hit an expired
cache. In conformance with Murphy's law, I was in a train, with a bad
Internet-by-phone connection, and Guix started downloading texlive.

So...

> Would it work for you?

No. I tend to keep project-specific environments unchanged for long
times, longer than Guix keeps its caches.

Cheers,
  Konrad

Re: Permanently available environments

[Konrad Hinsen]

Konrad Hinsen  writes:

> 1. Containers can only be generated using "guix shell" or the older
>"guix environment". There is no way to generate a container based
>on a profile. Correct me if I am wrong!

Thanks to Ricardo and Guillaume, who pointed out the –profile option to
"guix shell", which does exactly what I need. I missed it because it is
not mentioned in the manual. I just submitted a patch.

> 4. In practice, I often work with a bad or non-existing network
>connection, so I must be sure to have all my packages in the store.
>And if I use "time-machine", I must also keep the required Guix
>version locally available. But there is no option for that in
>"time-machine". The Guix versions it downloads are garbage-collected
>after a while. So I can find myself in the situation of having all
>the packages for my environment in the store, but unable to access
>it without a network connection, because "time-machine" first needs
>to fetch an old Guix version again.

Thanks to Vagrant for pointing out that "guix pull" has a –profile
option as well (which I wasn't aware of). This can indeed serve as a
workaround, although it looks a bit clumsy.

Cheers,
  Konrad.

Permanently available environments

[Konrad Hinsen]

Hi Guix,

I would like to migrate more of my software use to Guix-based
containers, but I haven't yet found a way to handle them that fully
suits my needs. The root issue is the volatility of environments, and I
wonder if I am missing some feature to handle them better. Here is my
current reasoning:

1. Containers can only be generated using "guix shell" or the older
   "guix environment". There is no way to generate a container based
   on a profile. Correct me if I am wrong!

2. I have been using a plain "guix shell" for a while, but my
   environments break too often after a "guix pull" to continue this
   way. Most of my containerized environments contain no
   security-critical software, so I'd be happy not to update them
   very often (or not at all). That would be trivial with profiles,
   but... point 1.

3. There's the –root option to "guix shell" to protect my environment
   from the garbage collector. But there is no way to say "use the
   environment pointed to by that root, no matter when and how it was
   created". I have to specify the packages with respect to the current
   Guix version (last "pull"). So if I want to protect against updates,
   I have to use "guix time-machine" with "guix shell". Which is fine
   in theory.

4. In practice, I often work with a bad or non-existing network
   connection, so I must be sure to have all my packages in the store.
   And if I use "time-machine", I must also keep the required Guix
   version locally available. But there is no option for that in
   "time-machine". The Guix versions it downloads are garbage-collected
   after a while. So I can find myself in the situation of having all
   the packages for my environment in the store, but unable to access
   it without a network connection, because "time-machine" first needs
   to fetch an old Guix version again.

Did I overlook anything?

Cheers,
  Konrad

Re: Certificates in pure and containerized environments

[Konrad Hinsen]

Hi Maxim,

> I agree that managing certs with Guix has many benefits, and having
> GnuTLS honor an SSL_CERTS_DIRS environment variable would enable that.

Yes, but it would also make it hard to avoid non-Guix-managed
certificates from being used, be it through user (configuration)
error or malice.

> Remember that installing nss-certs or your certs of choice package to a
> profile is not enough to have them discovered; something such as en
> environment variable and a search path specification is also necessary.

That's exactly what I'd like to change (ideally, I don't know if that is
even possible). Configuration via Guix and nothing but
Guix. The only certificates being used are those defined in a Guix
profile or environment.

Cheers,
  Konrad.

Re: Certificates in pure and containerized environments

[Konrad Hinsen]

Wiktor Żelazny  writes:

> Would it make sense to define a minimal package that includes only
> nss-certs input and use it for this purpose, then? A package that
> inherits from "hello" with nss-certs input added, for instance?

That would be a quick fix. Could it become an obstacle to a better
long-term solution? Otherwise I like the idea.

Cheers,
  Konrad

Re: Certificates in pure and containerized environments

[Konrad Hinsen]

Hi Maxim,

> The key thing here is whether the certs are required by OpenSSL vs
> GnuTLS.  The former honors SSL_CERT_DIR, while the later does not (I
...

> I hope that helps!

Thanks, that certainly helps to understand the issues.

My preferred approach would be to manage all certificates as Guix
packages, and not have any environment variables.  That would be the
opposite of your proposal to make GnuTLS honor SSL_CERT_DIRS. It's
always a mess to have multiple uncoordinated environment managers.

I do see the difficulty for those who need personal certificates and
don't know how to package them in Guix, but that could be solved by a
dedicated tool.

Cheers,
  Konrad

Re: Certificates in pure and containerized environments

[Konrad Hinsen]

Hi Wiktór and Simon,

thanks for shedding some light on this strange behavior. After some more
exploration, the fundamental issue seems to be that many packages use
certificates but only a very small number declare a dependence on
nss-certs. In fact, nss-certs has only three direct dependents (icedtea,
ldns, and pypy) and 115 additional indirect dependents.  That includes
r-reqon from Simon's example, which depends on icedtea via r-rjava and
openjdk.

A radical fix would be to make openssl dependent on nss-certs. But
openssl really depends on the availability of some collection of
certificates, not on any specific one. Nor do icedtea, ldns, or pypy.

Some packages (e.g. openssl or curl) have a `native-search-paths`
declaration that also seems to have the desired effect. The following
environment contains SSL_CERT_DIR as well:

   guix environment --pure --ad-hoc python nss-certs openssl

Python actually lists openssl as a dependency, but that is apparently
not sufficient to propagate the environment variables.

Anyway, this looks like the best workaround for me for now: adding
openssl to my environment. It adds no software package to my
environment, only environment variables and an executable on $PATH.

Thanks again,
  Konrad

Certificates in pure and containerized environments

[Konrad Hinsen]

Dear Guix experts,

I am trying to move the execution of a Python script into a pure
environment, but it fails because of certificate issues for which I am
looking for a good fix.

The minimal example I came up with is:

   guix environment --pure \
   --ad-hoc python -- \
   python3 -c 'import urllib.request; 
print(urllib.request.urlopen("http://wwwbis.sidc.be/DATA/uset/Wlight/2003/11/UPH20031109112104.FTS;))'

This fails with the error message

urllib.error.URLError: 

I have no idea why Python's urllib checks a certificate chain for a http
URL, but that's not my subject now. A variant that works fine is

   guix environment --pure --preserve=^SSL_CERT \
   --ad-hoc python -- \
   python3 -c 'import urllib.request; 
print(urllib.request.urlopen("http://wwwbis.sidc.be/DATA/uset/Wlight/2003/11/UPH20031109112104.FTS;))'

which adds two environment variables to the temporary environment:

   SSL_CERT_DIR=/home/hinsen/.guix-profile/etc/ssl/certs
   SSL_CERT_FILE=/home/hinsen/.guix-profile/etc/ssl/certs/ca-certificates.crt

Since all the certificates come from Guix, I expect that I should also
be able to use

   guix environment --pure \
   --ad-hoc python nss-certs -- \
   python3 -c 'import urllib.request; 
print(urllib.request.urlopen("http://wwwbis.sidc.be/DATA/uset/Wlight/2003/11/UPH20031109112104.FTS;))'

but this doesn't work - same error as initially.

I am not happy with exposing an environment variable from my personal
account, as I want my run to be reproducible and portable to any machine
running Guix, Ideally, I'd even move on to a containerized environment.
Is there any way to achieve this?

Thanks in advance,
  Konrad

Re: Problems with McCLIM (Common Lisp)

[Konrad Hinsen]

Hi Pierre,


Another approach could be not to use ASDF bundles at all, and just use
the regular compilation operation of ASDF, except the fasl files would
be put it "/gnu/store/..." instead of "$HOME/.cache/common-lisp/...",
and our asdf-build-system would indicate to ASDF where to search for the
files.

Good ideas.

In my opinion, the fasls (pre-built binaries) should go to their
respective package outputs.


That sounds good, as does getting rid of ADSF bundles. I have more or 
less given up on numcl, for example, which fails to compile to a bundle 
in recent versions but seems to work find via fasls (at least it works 
fine with quicklisp).


Konrad.

Re: Building packages in REPL

[Konrad Hinsen]

Anthony Quizon  writes:

> Is there a way that I can build a package via the repl?

As far as I know, no. I have been looking for this as well,
in order to make package development more interactive.

> For example,
> If I had a channel with a custom package in it, can I do:
>
> `$ guix repl -L .`
> `> ,use (my-channel packages base) `
> `> (build-package my-package) ;; this is the example imaginary command `

I'd even want more: access to the individual build steps.

Konrad

Re: Appropriate way to use Guix API from a Guile program

[Konrad Hinsen]

Konrad Hinsen  writes:

> Unfortunately, it doesn't look as straightforward as I thought.
> A standard Guile script retrieves command line arguments using
> (command-line). "guix repl" should ideally manipulate the return
> value of (command-line) to make things just work, but I haven't
> found a way to do this.

Reading the Guile manual helps, of course, once you know where to look.
It's (set-program-arguments ...), which starts to make sense once you
figure out that (program-arguments) is a synonym for (command-line).
I'll see if I can do something with that.

Cheers,
  Konrad

Re: Appropriate way to use Guix API from a Guile program

[Konrad Hinsen]

Hi everyone,

zimoun  writes:

>> Thanks for the reminder that my "guix repl" patch needs more work - it
>> should accept command line arguments for the script. Something like
>>
>>guix repl foo.scm –- [ARGS]
>>
>> should be easily doable, and fits in with existing conventions.
>
> It could be really cool! :-)

Unfortunately, it doesn't look as straightforward as I thought.
A standard Guile script retrieves command line arguments using
(command-line). "guix repl" should ideally manipulate the return
value of (command-line) to make things just work, but I haven't
found a way to do this.

The other solution is to define a command-line interface specifically
for scripts run using "guix repl", which looks like a lot of effort
for a less-than-optimal result.


Alex Sassmannshausen  writes:

> I can't help but think that it would be really useful to have a way to
> inject these load paths into the general user environment, in a way
> similar to `guix package --search-paths', so that the currently pulled
> guix can be just another guile library to be used on the system like
> any other.

I don't see any other way to do this than to shell out to "guix", parse
the return value, and modify load-path. Certainly doable, but I am not
sure it's worth the effort.

The problem with Guix is that are so many of it. Most users have a
single Guix version that they update using "guix pull", but others also
use development branches compiled locally and invoked via the preᵢnstₑnv
script. In the end it's the user who picks the right Guix for the job at
the command line. Any Guile script referring to Guix should offer the
same flexibility.

sirgazil  writes:

> And if you wanted to run the script without typing "guix repl", what would be
> the first line of the script. This?
>
> #!~/.config/guix/current/bin/guix repl
> !#

I'd go for 

> #!/bin/env guix repl
> !#

or something like that. I suspect it requires some more incantation
magic to work.

Cheers,
  Konrad

Re: Appropriate way to use Guix API from a Guile program

[Konrad Hinsen]

zimoun  writes:

> If you feel in an experimental mood, you can try the Konrad's patch
> [1].  It sets up the PATH accordingly and hides all the internals.

In particular it hides implementation details that are likely to
change. A look at the path in

  ~/.config/guix/current/share/guile/site/3.0

should be sufficient to suggest that not very long ago, this was

  ~/.config/guix/current/share/guile/site/2.2

and scripts have no way to figure out which one of the two is
appropriate on a given system.

> Well, if it is a script without command-line argument, then "guix repl
> foo.scm" is the thing that you would want, I guess.
> If it is a script with command-line argument, then extend
> "GUILE_LOAD_PATH" by '~/.config/guix/current/share/guile/site/3.0' and
> run "guile foo.scm arg1 arg2" is the thing that you would want, I
> guess.

Thanks for the reminder that my "guix repl" patch needs more work - it
should accept command line arguments for the script. Something like

   guix repl foo.scm –- [ARGS]

should be easily doable, and fits in with existing conventions.

Cheers,
  Konrad

Re: Emacs not seeing newer packages after pull

[Konrad Hinsen]

Hi Ivan,

> and behold, the files are under my pulled Guix.  Yay!  However, `guix-pull` in
> Emacs still fails with a bunch of "incompatible bytecode kind" errors then
> "guix: pull: command not found".

The "incompatible byte code" messages are due to emacs-guix using Guile
2.2 whereas Guix is using Guile 3. They will disappear in the ongoing
transition of everything to Guile 3. And they don't signal any real
problem. It's the last message that is critical.

> So I guess the proper way to go now is to report why `emacs-guix` on a foreign
> distro doesn't really work.  I'll look at the archives and open a new thread
> if needed.

Emacs-guix is a project separate from Guix, so it's best to open an
issue at https://gitlab.com/emacs-guix.

Cheers,
  Konrad

Re: Emacs not seeing newer packages after pull

[Konrad Hinsen]

Hi Ivan,

> My variable is `t` as defined at emacs-guix's `guix-repl.el`.  It is used in
> the `guix-repl-guile-args` to set the command line args for Guile.  According
> to `ps` in my system, I see these arguments:
...

Interesting. That looks very different for me on Guix System! But then,
I don't have "guix" in my profile. Not sure it's a good idea.

> If I run `guix package -s guix`, the version of the `guix` package (which I
> assume is the same that I got after the last `guix pull`, but I may be wrong)
> is `1.0.1-15…`.

If you have "guix" in your profile, you'd have to update your profile
after a pull to run the latest version.

> Maybe I should just `guix package -u` this time and check if the problem
> repeats with the next pull…

That sounds like a good experiment to do.

Cheers,
  Konrad

Re: Emacs not seeing newer packages after pull

[Konrad Hinsen]

Konrad Hinsen  writes:

> No, and yes. Meaning that I most definitely didn't expect it, but I
> confirm your observations. And I am running Guix System, so it's not
> related to your Guix-under-Debian installation.

I did some experiments in the Guix REPL created by emacs-guix, but
I don't understand what's happening. Here I am exploring
emacs-caps-lock, a package that I got with today's pull:

scheme@(emacs-guix)> (%search-load-path "gnu/packages/emacs-xyz")
$4 = 
"/home/hinsen/.config/guix/current/share/guile/site/3.0/gnu/packages/emacs-xyz.scm"

Looks OK. Let's look at the module and its filename:

scheme@(emacs-guix)> (resolve-module '(gnu packages emacs-xyz))
$5 = #
scheme@(emacs-guix)> (module-filename (resolve-module '(gnu packages 
emacs-xyz)))
$6 = "gnu/packages/emacs-xyz.scm"

A relative filename, but relative to what? Why isn't this an absolute
one? As for the package:

scheme@(emacs-guix)> (module-variable (resolve-module '(gnu packages 
emacs-xyz)) 'emacs-caps-lock)
$7 = #f

It's not in there (but it is in the source code). And now for the real
surprise:

scheme@(emacs-guix)> (reload-module (resolve-module '(gnu packages emacs-xyz)))
$8 = #
scheme@(emacs-guix)> (module-filename (resolve-module '(gnu packages 
emacs-xyz)))
$9 = 
"/home/hinsen/.config/guix/current/share/guile/site/3.0/gnu/packages/emacs-xyz.scm"
scheme@(emacs-guix)> (module-variable (resolve-module '(gnu packages 
emacs-xyz)) 'emacs-caps-lock)
$10 = #>

What the heck has Guile been loading the first time???

Cheers,
  Konrad

Re: Emacs not seeing newer packages after pull

[Konrad Hinsen]

Hi Ivan,

> Hi everyone!  Recently it caught my attention that emacs-guix seems to
> always be on the *previous* generation of Guix, i.e. the one before
> the latest pull.  That is, when I do a `guix pull` and check for new
...

> Is this behavior expected?  Does it also happen to you?  

No, and yes. Meaning that I most definitely didn't expect it, but I
confirm your observations. And I am running Guix System, so it's not
related to your Guix-under-Debian installation.

In fact, when I saw your mail, it reminded me of similar issues I had
noticed in the past but never taken the time to explore in more depth.

When trying to analyze this in more detail, I noticed that emacs-guix
runs guile 2.2, whereas guix itself used guile 3.0. That shouldn't make
a difference (my understanding is that the current Guix source code
works with both Guile releases), but it's a bit surprising as well.

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Guillaume Le Vaillant  writes:

> I pushed the fix as 47a2306415cf19270cb398590be3d95a92a0e73b.

Thanks a lot - this works just fine!

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Pierre Neidhardt  writes:

> Thanks for investigating this!
> Can you send a patch?  Or maybe Guillaume?

Not me, sorry. I haven't figured out yet how the asdf-build-system
works. Nor build systems in general.

Cheers,
  Konrad

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Pierre Neidhardt  writes:

> You could also try playing with the
> `--dynamic-space-size` command line flag, e.g.
>
>   sbcl --dynamic-space-size 2048 ...

That was a good idea. It turns out that 1024 is just a bit too low to do
program-op, though load-system works. With 1280 I can do program-op on
numcl.

So it looks like SBCL 2.0.2 just needs a bit of extra memory compared to
older versions. Guillaume's suggestion of increasing the limit should
thus be sufficient.

Cheers,
  Konrad.

Re: Heap space when building SBCL packages

[Konrad Hinsen]

Hi Pierre,

>>  2. Building binaries with SBCL takes more heap space than merely
>> loading a system from source via ASDF.
>
> I think probably not.  However there are different ASDF operation.  In the
> Guix build system we use "program-op" which does not behave like the
> default operation when loading a package.  This could be a factor here.

Worth testing, if only to have a non-Guix way to illustrate the issue
for reporting upstream if necessary.

Is there a way to get the exact ASD file plus command line that is used
by the build system?

>>  3. Guix' build systems does something that either limits heap space
>> or causes SBCL to require more of it.
>>
>> Does anyone have an idea on how to proceed to fix the problem?
>
> Can you reproduce with SBCL 2.0 or SBCL 1.5?

Building sbcl-numcl works fine with 1.5 and 2.0. It's only with 2.0.2
that there is this heap issue.

> Maybe report this issue to the SBCL issue tracker, they will probably
> know what's going on.

If it's not a Guix issue, then yes, that's the way to proceed.

Cheers,
  Konrad.

Heap space when building SBCL packages

[Konrad Hinsen]

Hi Guix,

I am trying to figure out why sbcl-numcl fails to build since the update
to SBCL 2.0.2. See here for a typical build log:

   http://ci.guix.gnu.org/build/2339924/details

What happens is that SBCL runs out of heap space and stops. However, I
can load numcl into SBCL 2.0.2 perfectly well when I load it via ASDF
under my own user account.

Therefore I suspect one of the following three possible causes:

 1. The build daemon runs with memory restrictions that are too severe
for building binaries for numcl.

 2. Building binaries with SBCL takes more heap space than merely
loading a system from source via ASDF.

 3. Guix' build systems does something that either limits heap space
or causes SBCL to require more of it.

Does anyone have an idea on how to proceed to fix the problem?

Cheers,
  Konrad.

Re: Lazy users and updates

[Konrad Hinsen]

Am 27.12.19 um 14:29 schrieb Todor Kondić:


Given the user-centric approach of Guix, it feels like it should be up to 
individual users of a shared system to deal with installations and the system 
updates. But, what to do when they are lazy, or too novice for fiddling with 
the command line?

Do I use the admin's prerogative and set their own crontabs to pull and "package 
-u" once in a while? I feel like this is overriding their free will for their own 
good.

Note that the question is ethical, as much as technical :)


Ask your users what they prefer. I'd want to handle this myself, but 
many of my colleagues would prefer an admin to take care of all 
updating. We are all different :-)


Cheers,
  Konrad.

Re: gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Konrad Hinsen  writes:

>> Maybe a "gfortran-toolchain" package with all the battery included?
>
> That sounds like a very good idea! And I even volunteer to
> implement it. Except if someone comes up with a better
> solution of course.

Here it comes:

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

Cheers,
  Konrad

error: failed to load 'gnu/tests/install.scm': No such file or directory

[Konrad Hinsen]

Hi Guix,

Today I have again been blocked by an error that I get occasionally when
trying to run Guix from source. I follow the usual steps:

 - ./bootstrap
 - ./configure –localstatedir=/var
 - make

until I see

   [ 48%] LOAD gnu/tests/guix.scm
   [ 48%] LOAD gnu/tests/monitoring.scm
   [ 48%] LOAD gnu/tests/nfs.scm
   [ 49%] LOAD gnu/tests/install.scm
   error: failed to load 'gnu/tests/install.scm': No such file or directory

It always happens at the same point, it's always
'gnu/tests/install.scm', and yet there is nothing obviously
wrong with that file (which definitely exists).

>From experience, I know that in a few days, after updating Guix, it will
work again, and then one day I'll run into the same bug once more.

Is this a known problem? Better yet, with known solutions or
workarounds?

Cheers,
  Konrad.

Why does installing texlive download that 2 GB file twice?

[Konrad Hinsen]

Hi Guix,

I am building an environment containing texlive. I was prepared for a
huge download, but not for it to happen twice! Here's the log
(with some comments):

  The following derivations will be built:
 /gnu/store/mp6v3nngryf58l74l1j4y32dv60rp6qn-profile.drv
 /gnu/store/5bv2w5k8lgjwpzgyh31cyp8vxfg0rrnr-texlive-texmf-20180414.drv

OK.
  2,640.0 MB will be downloaded:
 /gnu/store/w02vdgqimzrby3yab4062yq34hjxz6nr-libyaml-0.1.7
 /gnu/store/byhjm99aabwh91csyjsaja83m7xlbln6-python-pyyaml-3.13
 /gnu/store/5aq60gx42sfs5drigb5g7fpa7fh1pq4z-texlive-20180414
 /gnu/store/jl8jj8d1s2ldvazylyfgmz7ga7rvcgxx-module-import-compiled
 /gnu/store/mj40l554qxw15acz0h018gk5c9mxzfgn-texlive-20180414-texmf.tar.xz
 /gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import
 /gnu/store/dch016c5w3zijqrpkhsky89s81jk7p41-cairo-1.16.0
 /gnu/store/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0
 /gnu/store/xypzclmh2i1nkzyyb1crmhpbngx3pcmw-ruby-2.5.3
 /gnu/store/15zh79zna12m45afl6h1rclsnfsw7m7b-ghostscript-9.27
 /gnu/store/94nw4ch1gjn6pqdb54a90k6cvnx3lag3-potrace-1.15
 /gnu/store/l06xm6ax5j99gkqjkbwsrb0353l2fclz-zziplib-0.13.69
 /gnu/store/543ybxjpmkpwzcbdxmlr3x8qwpxlb1hw-teckit-2.5.9
 /gnu/store/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414
 /gnu/store/78w7y0lxar70j512iqw8x3nimzj10yga-python-3.7.4
 /gnu/store/6r0hkmky937g824g02c8mzyhq80vjql4-python-3.7.4-tk

Make sense. That's 2.6 GB.

  The following grafts will be made:
 /gnu/store/j3xfkw271db0bnvkylf8fik3dqnmwwck-python-3.7.4.drv
 /gnu/store/vcbpxwrrkk1frp1kgdbn86dm87l1zl85-texlive-20180414.drv
 /gnu/store/97c19j1dnxsjshmpp80p6hfi4v4bg0by-texlive-bin-20180414.drv
 /gnu/store/bs7w34zc6a0sznbln8wmsbrdjdhfzpmk-teckit-2.5.9.drv
 /gnu/store/cb0aag3qha7znkrv9z12j2smvk3kn8h2-ruby-2.5.3.drv
 /gnu/store/dqn2lf7755s4wl4kn49m4b18va5yvxjz-texlive-texmf-20180414.drv
 /gnu/store/w7ynpv1wyvcqk8lkzwkgblik5gl5q0r2-python-pyyaml-3.13.drv
  The following profile hooks will be built:
 /gnu/store/609kij4ac4154x3aslmpwpiq8b6kpb5g-fonts-dir.drv
 /gnu/store/6ckxy3rmh55dd95zr94wx3q063q1bhv1-info-dir.drv
 /gnu/store/v7wnqdpbfk9yd1kfdsa013rj22jy47id-manual-database.drv
 /gnu/store/yqzsdl5b4mmfplbhp08lskb5m0g2v1iq-ca-certificate-bundle.drv

Looks OK as well. And now...

  downloading from 
https://ci.guix.gnu.org/nar/mj40l554qxw15acz0h018gk5c9mxzfgn-texlive-20180414-texmf.tar.xz...
   texlive-20180414-texmf.tar.xz  2.42GiB 1.4MiB/s 29:22 [##] 
100.0%

That's my 2 GB of TeXLive. Some small stuff follows:

  downloading from 
https://ci.guix.gnu.org/nar/lzip/dch016c5w3zijqrpkhsky89s81jk7p41-cairo-1.16.0...
   cairo-1.16.0  1.0MiB 3.0MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/15zh79zna12m45afl6h1rclsnfsw7m7b-ghostscript-9.27...
   ghostscript-9.27  10.9MiB4.8MiB/s 00:02 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/w02vdgqimzrby3yab4062yq34hjxz6nr-libyaml-0.1.7...
   libyaml-0.1.7  70KiB 1.6MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/gzip/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import...
   module-import  334B   29KiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/18q4r8bpwmpm4w15zipf66l3bvdjzfbs-poppler-0.79.0...
   poppler-0.79.0  1.3MiB   4.4MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/jl8jj8d1s2ldvazylyfgmz7ga7rvcgxx-module-import-compiled...
   module-import-compiled  166KiB   2.0MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/94nw4ch1gjn6pqdb54a90k6cvnx3lag3-potrace-1.15...
   potrace-1.15  96KiB  1.9MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/6r0hkmky937g824g02c8mzyhq80vjql4-python-3.7.4-tk...
   python-3.7.4-tk  29KiB   2.2MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/byhjm99aabwh91csyjsaja83m7xlbln6-python-pyyaml-3.13...
   python-pyyaml-3.13  148KiB   1.7MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/xypzclmh2i1nkzyyb1crmhpbngx3pcmw-ruby-2.5.3...
   ruby-2.5.3  5.5MiB   1.7MiB/s 00:03 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/543ybxjpmkpwzcbdxmlr3x8qwpxlb1hw-teckit-2.5.9...
   teckit-2.5.9  445KiB 2.3MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/l06xm6ax5j99gkqjkbwsrb0353l2fclz-zziplib-0.13.69...
   zziplib-0.13.69  93KiB   1.3MiB/s 00:00 [##] 
100.0%

  downloading from 
https://ci.guix.gnu.org/nar/lzip/azd3rg350gjkgzvzps3s4j3kpz5kxh57-texlive-bin-20180414...
   texlive-bin-20180414  

Re: gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Hi Simon,

> Maybe a "gfortran-toolchain" package with all the battery included?

That sounds like a very good idea! And I even volunteer to
implement it. Except if someone comes up with a better
solution of course.

Cheers,
  Konrad.

Re: gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Hi Marius,

>>> With your patch, I can compile Fortran programs in an environment
>>> containing nothing but "gfortran", so I'd say it works!

Not quite, in fact. What I had tested successfully is compiling
a Fortran file to a .o file. Linking .o files into an executable
still fails:

  /gnu/store/wzia23i6ngqaaz0kd2il7s30758dxvca-profile/bin/ld: cannot find 
crt1.o: No such file or directory

I had to add glibc to my environment to get an executable. So it seems
that compiling Fortran programs requires gfortran + binutils + glibc.

Cheers,
  Konrad.

Re: gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Hi Marius,

>> With your patch, I can compile Fortran programs in an environment
>> containing nothing but "gfortran", so I'd say it works!
>
> On second though, the patch increases the size of 'gcc' from 238.0 MiB
> to 291.5 MiB.  It may also make it difficult to use a different 'as'
> executable.
>
> So I'm not sure whether the added convenience is worth it.

I'd prefer a compiler that works at 291.5 MiB to a compiler that doesn't
work at 238.0 MiB.

When you know how to fix the problem (by installing binutils), it's
perhaps just a convenience. If you don't know, it's a show-stopper.

I see the point of wanting to use a different 'as', but are there any
concrete alternatives in Guix that someone might wish to substitute?
Personally I have never cared much about 'as'. It's a necessary tool
but also a very boring and predictable one. I don't see what I could
gain by replacing it.

Cheers,
  Konrad.

Re: gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Hi Marius,

> 'as' is part of Binutils, you don't need the entire toolchain.
>
> That said, there are various other workarounds in Guix due to GCC
> (and apparently gfortran) lacking an absolute reference to 'as'.
>
> Can you try the following patch and see if it works for your case?

Thanks for looking into this!

With your patch, I can compile Fortran programs in an environment
containing nothing but "gfortran", so I'd say it works!

Thanks,
  Konrad

gfortran seems to require gcc-toolchain

[Konrad Hinsen]

Hi Guix,

I am trying to recompile old Fortran code under Guix. I made an (pure)
environment containing "gfortran" plus a few required tools (make etc.),
but found that every Fortran compilation stops with an error message
complaining about "as" missing. Installing gcc-toolchain fixes the
problem.

If gfortran cannot be used without gcc-toolchain, shouldn't
gcc-toolchain be a propagated input of gfortran?

Cheers,
  Konrad.

Re: REQUEST to Guix Maintainers

[Konrad Hinsen]

Hi Raghav,


I tried converting the PDF to EPUB via calibre and the result was
awful. Formatting got messed up. So I thought it would be better if the
epub was generated directly from source?


Did you try converting the HTML version to EPUB? Calibre does that as 
well. EPUB is little more than a packaging convention for a subset of 
HTML, so this conversion is easier than starting from PDF.



Cheers,

  Konrad.

Re: “Guix Profiles in Practice”

[Konrad Hinsen]

Pierre Neidhardt  writes:

> "Thompson, David"  writes:
>
>> if it's a good idea.  Probably not.  So, I wonder if maybe a new
>> subcommand, say 'guix develop', could address this common development
>> use-case while allowing 'guix environment' to continue being the swiss
>> army knife that it is.  Some simple naming conventions could make this
...

> This is essentially what you propose, but to have it at the CLI level
> would provide several benefits:
...

> Both issues could be addressed the same way.

Perhaps. But then, "could" doesn't imply "should". I'd love to see all
that functionality easily accessible from the CLI, but I can't say I
know how this should best be organized.

Maybe we should start a Guix CLI nursery. A project/repository separate
from Guix itself that contains a copy of the "guix" script under a
different name ("guixx" for guix-extras?) and with the same interface
for scripting modules. We could then use this to play collectively with
ideas, and if something turns out to work well, migrate it to the
official Guix CLI.

Does this sound like a good idea? Would anyone else participate in such
an experiment?

Cheers,
  Konrad.

Re: [Blog/Cookbook?] On multiple Guix profiles and manifests

[Konrad Hinsen]

Am 14.10.19 um 09:27 schrieb Pierre Neidhardt:


However, I wonder why nobody has implemented
"guix environment --profile=/path/to/my/profile".


Note that there is the "--manifest" option to "guix environment".

This brings up another "pro" for manifest: Right now it's possible to
create environments out of manifests while it's not possible to create
environments out of profiles without Chris' hack.


When I explain Guix, I start with environments, which I consider that 
more fundamental concept, and then introduce profiles as persistent 
environments. From that perspective, creating an environment from a 
profile makes no sense, though it may be useful as a convenience 
function for some needs (not mine). Manifests are persistent 
*specifications* of environments, which do make sense (a lot, in fact).



A question that I believe has been brought up before: is it possible to
specify multiple manifests from the command line, such as to provide the
union of the manifests?

Even better: what high-level functions to manipulate manifests, such as
"manifest-union", "manifest-difference"?


Union is OK, difference isn't. A manifest is not just any set of 
packages, it's a set of packages that has no dependencies outside of the 
set.


This sounds like the beginning of another chapter for the cookbook: 
package lists, manifests, bags, etc. What are the differences, and when 
should I use what?


Which reminds me that when working on the command line, the "manifest" 
option in practice always refers to a package list that is then 
converted to a manifest. And most people *want* to work at the package 
list level. And then differences make sense again. It's all a bit of a 
mess...


Cheers,
  Konrad.

Re: [Blog/Cookbook?] On multiple Guix profiles and manifests

[Konrad Hinsen]

Pierre Neidhardt  writes:

> Konrad Hinsen  writes:
>
>> Sounds good in principle. I just wonder how many authors (and thus
>> different preferences and use cases) it takes to make this really
>> useful. I note for example that my own use of profiles is rather
>> different from yours: I have per-project profiles for long-term projects
>> whose software I don't want to update regularly to avoid breaking stuff.
>
> Hmmm, this sounds like what I do too! :)

The main difference is that I don't have all my profiles activated
in normal use, only my main profile plus one project profile. Different
project profiles can contain different versions of the same software,
so activating them together is not a good idea.

What got me started with this strategy was the need to use
Python 2 and Python 3 in different projects. But then it turned out to
be useful for other software as well.

> Anyways, I'm all for discussing multiple strategies, the more the better!

Sounds like a good plan!

Cheers,
  Konrad

Re: [Blog/Cookbook?] On multiple Guix profiles and manifests

[Konrad Hinsen]

Hi Pierre,

> So what about writing a blog article / cookbook chapter to explain why
> profiles and manifests are truly awesome indeed?  (Unless this has
> already been done and I missed it?)

Sounds good in principle. I just wonder how many authors (and thus
different preferences and use cases) it takes to make this really
useful. I note for example that my own use of profiles is rather
different from yours: I have per-project profiles for long-term projects
whose software I don't want to update regularly to avoid breaking stuff.

> Placing all your profiles in a single folder, with each profile getting its 
> own
> subfolder is somewhat cleaner, plus it's obvious to "loop over profiles" from
> any programming language (e.g. a shell script) by
> simply looping over the sub-directories of .guix-extra-profiles.

That's very good advice that definitely should be written down somewhere.

Konrad.

Who is sending my Guix System to sleep?

[Konrad Hinsen]

Hi Guix,

In an attempt to make more use of Guix in my daily life on a
MacBook, I have set up a virtual machine (using VirtualBox)
that contains a desktop installation of Guix. I have then set
up ssh with X11 forwarding, and thus run software such as Emacs
from my macOS terminal. Since I don't need the virtual machine's
display, I usually run the machine in headless mode.

The only problem is that after 20 minutes, the virtual machine
seems to freeze. I found the cause in /var/log/messages:

Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2246] 
manager: sleep: sleep requested (sleeping: no  enabled: yes)
Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2247] 
manager: NetworkManager state is now ASLEEP
Sep 26 08:54:40 localhost NetworkManager[282]:   [1569480880.2248] 
device (enp0s3): state change: activated -> deactivating (reason 'sleeping', 
sys-iface-state: 'managed')
Sep 26 08:54:40 localhost NetworkManager[282]: 
[1569480880.2293] device (enp0s3): state change: deactivating ->
disconnected (reason 'sleeping', sys-iface-state: 'managed')

Something requests NetworkManager to go to sleep, which is obviously not
good for my ssh connection. But what?

First I went to the XFCE settings and switched off all automatic suspend
and hibernate actions. No success. Then I replaced %desktop-services in
my config.scm by %base-services plus the explicit list of what
%desktop-services adds to it. And then I removed suspect and/or unneeded
services one by one. Now I have nothing left that I can remove without
losing some functionality or getting en error message at "guix system
reconfigure". But my system still goes to sleep after 20 minutes.

These are the services I still have, in addition to %base-services:

  (list (service xfce-desktop-service-type)
(service openssh-service-type
 (openssh-configuration
  (x11-forwarding? #t)))
(set-xorg-configuration
  (xorg-configuration
   (keyboard-layout keyboard-layout)))

(service gdm-service-type)
(service network-manager-service-type)
(service wpa-supplicant-service-type)
(service avahi-service-type)
(accountsservice-service)
(elogind-service)
(dbus-service)

(service ntp-service-type)

x11-socket-directory-service)

Does anyone have an idea what could cause the automatic sleep?

BTW, I also tried using a basic non-desktop system, but then I cannot
run X11 applications for whatever reason.

Thanks in advance,
  Konrad

Re: Outdated po files

[Konrad Hinsen]

Julien Lepiller  writes:

> I'm not sure what the issue is here. I've seen that before when I
> tried to add a file to the list of translated sources, but it had an
> incorrect plural form. Gettext thought there was a different number of
> placeholders, but actually one of them is not a placeholder.

There are two bugs filed in relation to this (#37491 and #37505), which
may or may not be the same (I can't say). I hope someone will be able to
figure out what's going wrong!

Konrad.

Re: Outdated po files

[Konrad Hinsen]

Hi Julien,

> This is not an error, but rather a warning. They are expected because
> their is one po file for two texinfo files, they cannot have the same
> number of entries. So the message is harmless, but I can't find an
> option to hide it specifically.

Ah, thanks. I thought the po file problem was the reason for the error
that follows, but from your explanation it looks like this is just a
coincidence. However, it does look as if the error is related
to po files in some way:

   rm -f e...@boldquot.gmo && 
/gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/msgfmt -c --statistics 
--verbose -o e...@boldquot.gmo e...@boldquot.po
   e...@boldquot.po:2848: format specifications in 'msgstr[0]' are not a subset 
of those in 'msgid_plural'
   e...@boldquot.po:2855: format specifications in 'msgstr[0]' are not a subset 
of those in 'msgid_plural'
   /gnu/store/6z2rl8vrbcghvwcjdcf740b8l2cgx25a-profile/bin/msgfmt: found 2 
fatal errors
   e...@boldquot.po: 915 translated messages.
   make[3]: *** [Makefile:201: e...@boldquot.gmo] Error 1
   make[3]: Leaving directory '/home/hinsen/guix-from-source/guix/po/guix'
   make[2]: *** [Makefile:238: stamp-po] Error 2
   make[2]: Leaving directory '/home/hinsen/guix-from-source/guix/po/guix'
   make[1]: *** [Makefile:4865: check-recursive] Error 1
   make[1]: Leaving directory '/home/hinsen/guix-from-source/guix'

Cheers,
  Konrad

Outdated po files

[Konrad Hinsen]

Hi Guix,

My attempt to compile the current state of the master branch ended
rapidly with a long string of error messages like this one:

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

For my current purposes, I don't need translations of the
documentation. Is there a way to tell the installation procedure to go
on in spite of these errors (which I have no idea how to fix)?

Cheers,
  Konrad

Re: Help with Learning Programming and LISP

[Konrad Hinsen]

On 12/09/2019 03:16, Raghav Gururajan wrote:

I have a doubt though, do I have to learn dialects of LISP in a
particular order?


No, you can learn each of them on its own, and proceed in any order if 
you want to learn all three of them.


If your main goal is to learn about the core features of the Lisp 
family, I'd start with Scheme, which is the smallest and most coherent 
Lisp dialect. Common Lisp is huge in comparison, but if you try to write 
real-life programs in Scheme, you will discover that there are actually 
good reasons for having a large standardized language. The other main 
difference is that Common Lisp implementations tend to have much better 
development environments and in particular much better debuggers, which 
is also a consequence of the minimalist vs. practical tool approaches 
taken by the two dialects.


In my opinion, there is exactly one reason for learning Emacs Lisp: to 
configure and extend Emacs. Some people also use Emacs Lisp for text 
processing tasks, because Emacs provides an excellent support library 
for that. But as a language, Emacs Lisp is mostly considered outdated 
and inferior to either Scheme or Common Lisp. I would definitely not 
recommend learning Emacs Lisp as a typical modern Lisp.


Konrad.

Re: Scripting guix in guile (Konrad Hinsen)

[Konrad Hinsen]

On 06/09/2019 12:28, Tobias Geerinckx-Rice wrote:


Konrad Hinsen 写道：

Is there any reason why this isn't defined by default? That would solve
portability problems for lots of scripts, and I don't see any
disadvantage caused by this link.


It is now!


Great, thanks!

Konrad

Re: Scripting guix in guile (Konrad Hinsen)

[Konrad Hinsen]

Hi Gary,

> Just in case you hadn't thought of this yet, you can ensure that
> /usr/bin/env exists on any Guix system by consing the following entry
> onto the list of services under your operating-system definition.

I hadn't thought of this for the simple reason that I didn't know about
this mechanism. It looks very useful, thanks for the pointer!

Is there any reason why this isn't defined by default? That would solve
portability problems for lots of scripts, and I don't see any
disadvantage caused by this link.

Cheers,
  Konrad

Re: Scripting guix in guile

[Konrad Hinsen]

Hi Jesse and Ludo,

Jesse Gibbons  writes:

> 1. Tell your audience to call "guile " when running the
> script.

That's very reasonable, but...

> This does not garuntee guix is in their GUILE_LOAD_PATH though, so you
> will either need to tell them to add a segment to .bashrc to add the
> guix source location to their GUILE_LOAD_PATH or have them use the -L
> flag to have guile search that directory.

that sounds a bit complicated to explain, especially since they first
have to figure out the correct path segment to add, which depends on how
Guix was installed.

> 2. Instruct the audience to use features of guix when playing with the
> script:

Some of those are in fact my main topic (which will be part of a
tutorial on managing software environments for reproducible research).
But I want to keep technical details to a minimum for an introduction to
Guix.

> 3. I think you can use autogen to find out where guile and guix are
> located and use that location in the shebang and in a script that adds
> guix to GUILE_LOAD_PATH. This is a bit complicated though, and you will
> need to make sure your audience has autogen before they can do
> anything.

I don't even use autogen myself, so that's perhaps not the right
approach...


Ludovic Courtès  writes:

>>  1. What to put into the #! line to locate Guile.
>
> On Guix System #!/run/current-system/profile/bin/guile is very likely to
> work :-), but on other systems you could use “#!/usr/bin/env guile” I
> suppose.

True. But I'd prefer something that works on both!

>>  2. How to construct the load path to make sure it includes
>> Guix as installed under $HOME/.config/guix/current
>
> That’s indeed annoying.  I think we should add ‘-s’ and similar flags
> that ‘guile’ supports to ‘guix repl’.

That sounds like a good idea, though I'd probably use "guix script" or
something similar rather than overload "repl".

> In the meantime, as Jesse suggested, you could arrange to have both
> ‘guix’ (the package) and ‘guile’ in a profile, such that Guix and its
> dependencies are available in $GUILE_LOAD_PATH.

That's what I thought would work, but it doesn't:

   $ which guix
   /home/hinsen/.guix-profile/guix
   $ which guile
   /home/hinsen/.guix-profile/guile

   $ echo $GUILE_LOAD_PATH
   /home/hinsen/.guix-profile/share/guile/site/2.2

   $ ls $GUILE_LOAD_PATH
   emacs-guix  emacs-guix.scm  gcrypt

That's with a Guix install under Ubuntu.

>´ As for inspecting the installed packages, the entry point is (guix
> profiles), which has everything you need to grab info about a profile.

Indeed, together with (guix packages) that's enough for exploring
a profile or environment, which is my main topic. My scripts
output stuff like (transitive-manifest-entries ...) or
(package-closure ...) in a readable format, to let users get a better
idea of what their code really depends on, and how.

Cheers,
  Konrad.

Re: Scripting guix in guile

[Konrad Hinsen]

Hi Jesse,

First of all, thanks for your suggestions!

>>  1. What to put into the #! line to locate Guile.
> I don't think you need a shebang to script guile. If you do, you could
> always make a guix package for the scripts, and that will fix
> everything in the patch-shebangs phase.

Right, packaging solves the problem because Guix takes care of patching
my script. But that comes at a significant cost in terms of deployment
complexity. It's certainly the right way to distribute black-box tools,
but my scripts are mainly illustrations for working with Guix. I want to
use them in a tutorial, saying "there is no built-in Guix functionality
for this, but you can write your own scripts interfacing with
Guix. Here's an example, download it, play with it, modify it to fit
your needs."

> I think the default GUILE_LOAD_PATH includes guix. Here's the contents

Not on my system. I am using Guix on top of Ubuntu, maybe for Guix
System it works out of the box. I'll try with a virtual machine.

> --You can wrap the executables with the environment variables you need
> so the executable scripts are callable from the default PATH. See what
> guix does with guile, mcron, and shepherd, which are mostly guile
> scripts with a little bit of native code.

Looking at those examples is certainly a good plan - I'll do and report
back!

Konrad.

Scripting guix in guile

[Konrad Hinsen]

Hi everyone,

I'd like to write Guile scripts that inspect Guix, for example analyze
the packages is my profile. That turned out to be a lot more difficult
than I expected, and in fact I haven't found a satisfying general
solution yet, meaning a script that I could publish in such a way that
any Guix user could download and run it without modification.

The problems I see are

 1. What to put into the #! line to locate Guile.
 2. How to construct the load path to make sure it includes
Guix as installed under $HOME/.config/guix/current

I wonder if could somehow hijack 'guix repl', which solves these
problems for a REPL but not for scripts.

Any ideas?

Konrad

Re: Why reproducibility is breaking by metadata?

[Konrad Hinsen]

Hi Giovanni,

> Just "food for thought": git-annex metadata allows users to attach
> arbitrary metadata to their annexed files, «metadata is stored in the
> git-annex branch, and so is automatically kept in sync with the rest of
> git-annex's state»

That's indeed a nice example of how to handle metadata in a better way.
But it does require more than a plain files, so publishing and archiving
the metadata requires additional tools (git in this case).

> I doubt this could be applied to `guix pack`, but it's an intereting
> approach to "sidecar" metadata

We could adapt the idea to the Guix store. Write the metadata to a
separate file in the store that has the same filename as the packed
archive, but an additional extension. Since the filename contains the
hash of the archive contents, the relation between data and metadata
is also maintained.

Konrad.

Re: Why reproducibility is breaking by metadata?

[Konrad Hinsen]

zna...@disroot.org writes:

> Hello, Guix Help! I am translating Guix manual and found that the
> author is entirely given to reproducibility. It leads to such phrases
> that metadata breaks reproducibility when he describes
> '--save-provenance' flag of 'guix pack' command here:
>
> 'This option is not enabled by default because, like timestamps,
> provenance information contributes nothing to the build process. In
> other words, there is an infinity of channel URLs and commit IDs that
> can lead to the same pack. Recording such “silent” metadata in the
> output thus potentially breaks the source-to-binary bitwise
> reproducibility property. '
>
> I did not expected such a categorical statement. I think, it does not
> actually break reproducibility but only complicates checks. If we have
> to talk about reproducibility to ignoramus, saying 'this option breaks
> reproducibility option' have to have remark 'simply put' or 'plainly'.

If you define reproducibility in a pragmatic way as something that can
be verified without deep knowledge of file formats, then the only
reasonable definition is bitwise identity. That's what anyone can check
with generic tools. If you want to check that two outputs of 'guix pack'
are equivalent, i.e. identical up to provenance data, then you need a
separate tool for each output format (and you have to write those tools
yourself because to the best of my knowledge they don't exist yet). In
short, I agree with the statements made in the text.

However, you are completely right that this paragraph is not written at
the right level for the typical user. Here is a proposition for
improving it:

--save-provenance

Save provenance information for the packages passed on the command
line. Provenance information includes the URL and commit of the
channels in use (see Channels), which permit the recipient to locate
the source code of the package definitions that were used.

Provenance information is saved in the /gnu/store/…-profile/manifest
file in the pack, along with the usual package metadata—the name and
version of each package, their propagated inputs, and so on.

Note that inclusion of provenance information makes the resulting
archive non-reproducible in the sense that two archives containing
identical binaries can be different if they were built using
different channels or different commits.

Does this look better to you?

Philosophical side note: the right way to store provenance information
is outside of the data they refer to. Unfortunately, with file-based
storage, there is no clean way to attach the provenance information
securely to the data without putting it into the same file.

Konrad.

Re: guix-a dokumentaro en Esperanto

[Konrad Hinsen]

Quiliro Ordonez  skribis:

Laŭ mia scio nenia dokumentaro en Esperanto ekzistas. Sed ja troviĝas
esperantistoj inter la Guix-istoj kaj Guix-umantoj. Eblas do esperi
iaman pliboniĝon de la situacio.

Ĝis,
  Konrad.

Re: Real-world example for channels?

[Konrad Hinsen]

Hi Chris,


I agree with Hartmut.  I also found this confusing.  I've attached a
patch to try clarifying it.  What do you think?


Thanks for the clarification. I was also confused about this, to the 
point of never actually setting up my own channel.


Konrad.

Re: Stuck upgrading from Guix v0.12

[Konrad Hinsen]

Hi Paul,

> A lesson learnt from a previous update process [1] was; do not leave it
> too long between 'guix pull' updates.  
>
> However, I have one system running Ubuntu 16.04 and Guix v0.12 that I
> am trying to update.  As root:

I have had similar problems as well in the past. The one recipe that has
always worked (aside from one case of a machine with very limited disk
space) is temporarily using a Guix compiled from source code.

The procedure for building Guix from source code is explained in the manual:

   
https://www.gnu.org/software/guix/manual/en/html_node/Building-from-Git.html#Building-from-Git

When done (it takes a while to compile), run that copy of Guix to do a
"guix pull", without installing it, as described in

   
https://www.gnu.org/software/guix/manual/en/html_node/Running-Guix-Before-It-Is-Installed.html#Running-Guix-Before-It-Is-Installed

After that, your standard Guix installation is up to date and you can
delete all the source code again.

The procedure is lengthy in terms of compile time, and requires a lot of
temporary disk space, but the advantage is that you don't have to
analyze what actually went wrong with your installation. Put
differently, it's hard on your computer but easy on our brain :-)

Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

swedebugia  writes:

> Could you report this to bug-g...@gnu.org?

Done (and Ludo and Ricardo are already looking into this).

> How about reinstalling v. 0.15 overwriting your current installation?
>
> this would invalidate all your store items though.

Exactly, which is why I would like to avoid it. The current profile
of the only account that matters on that machine contains some fragile
software, so I am not at all sure that if I reinstall and update
everything I will still have a working system.

Perhaps I could try to archive all the stuff in the profile, re-install
Guix, and recover my store items from the archive. But as far as I know
there is no way to install them into a profile afterwards.

BTW, I did find a way to run "guix pull" which has a good chance to work
on a more typical installation: remove $HOME/.config/guix and then run
"/usr/local/bin/guix pull". Unfortunately, this fails on my machine
because of insufficient disk space for building an enormous amount of
packages. Even gtk, although I am on a headless server.

I actually wonder if it is reasonable to run Guix on such a limited
machine. My store fills up 1/3 of the 10 GB partition, and that's right
after a "guix gc". Perhaps I should keep a profile with that machine's
software on my main Guix machine and just copy over the binaries from
time to time.

Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

Hi Julien,

> The command you should run is:
>
> guix archive --recursive --export `readlink -f ~/.config/guix/current` > 
> guix-update.nar
>
> note the --recursive (so guix can find its dependencies, but it will 
> bundle every dependency in the .nar, so there may be some duplication 

I just tried that one - same problem with guix-authenticate.

> renamed the directory where the current guix version is installed). I 
> think I told you "latest" before, that was my mistake, sorry. Maybe you 
> can try again "guix copy", with "current" this time?

No change, I get the same protocol error.

I actually do have ~/.config/guix/latest (probably left over from an
older guix), and it does point to a store entry. So I should be able to
archive and copy it, even if it's not the entry that I need.

Cheers,
  Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

swedebugia  writes:

> This is most probably not correct. You most probably do have a working 
> Guix in the store but your current guix points to the new one which 
> lacks guile-gcrypt.

Indeed, kind of. It looks more complicated than that.

As you say, there is indeed a working guix in the store, but calling
apparently still makes it use the messed-up code under ~/.config/guix.
After renaming this to move it out of the way, I can again run guix
commands.

However...

> I suggest you roll back your guix pull profile following the manual. 
> (this might not work if your guix is too old)

My guix does seem to be too old for that. And while I can now invoke it
without an immediate error message, every attempt at installing or even
removing packages leads to an attempt to compile the GCC toolchain,
which fails for lack of disk space (there's only one 10 GB partition).


So I tried Julien's suggestion to copy over a newer guix from another
machine.

Step by step:

   guix archive --generate-key

Works fine, but must be run as root because it writes to /etc.

   scp /etc/guix/signing-key.pub remote@machine

then on the remote machine

   guix archive --authorize < signing-key.pub

Again "guix archive" must be run as root. Back to the "new-guix" machine:

   guix copy --to=remote@machine `readlink -f ~/.config/guix/latest`

guix copy: error: failed to connect to `#': Protocol error

Hard to say which protocol is not respected there, but given how old my
guix is, I suspect the protocol used by "guix copy" has changed since.

So let's try a variant: use "guix archive" to export a nar file, copy it
over to the other machine, and import it.

   guix archive --export `readlink -f ~/.config/guix/latest` > guix-update.nar

guix archive: error: build failed: program `guix-authenticate' failed
with exit code 1

There isn't much documentation on "guix authenticate" and how it might
fail, so I'll end my experiments here. Does anyone have an idea for
something else that I might try?

Cheers,
  Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

 writes:

> I think the main feature of guix - the roll back function - rests there. 
> May be you could choose most previous kernel in grub and then ran
> `guix system roll-back`. Would it repair your system?

Sorry for my lack of precision: I am not running GuixSD, but the guix
package manager on top of a Debian installation.

Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

Konrad Hinsen  writes:

> I can still check out some intermediate version and build from source.

I can indeed check out and build them, but not use them at all. The
binaries for these intermediate versions are no longer on the substitute
servers, and my machine runs out of memory and/or disk space when trying
to rebuild everything from source.

So I will try Julien's suggestion next week.

Konrad.

Re: Updating a very old Guix

[Konrad Hinsen]

Hi Swedebugia and Julien,

First of all, thanks to both of you for your suggestions!

> Have you tried the commit for the next nearest stable? v.0.13 v.0.14 
> v.0.15? (gcrypt was added after 0.15 point)
> Ludo recommended in another thread to pull in increments. But basically 
> building guix with an old guix is not supported at all ATM but should work.

I did consider going through intermediates, but only when the problems
showed up. Since I do not have a working Guix any more, I cannot use
"guix pull" with a commit to move to an intermediate.

I can still check out some intermediate version and build from source.
But then I guess I would have to install it in some temporary place, and
use it to build another intermediate. In the end, I would use the final
one to do a pull on my standard user account. Well, that just *might*
work...

> Please report your progress!

I will!


> If you have another machine with guix installed, you could try to use 
> guix copy to copy a working guix pull profile (~/.config/guix/current) 

Yes, I do have another machine with a pretty recent Guix. Unfortunately
I have no access to it over the weekend, but if the above strategy
fails, I will try yours next week.

Thanks again to both of you,
  Konrad

Updating a very old Guix

[Konrad Hinsen]

Hi everyone,

I have a computer that I don't use very often, with a rather old Guix
installation from nearly a year ago. So I though I should do an update.

First try: "guix pull".

Does a lot of downloading and compiling, then finishes. But guix no
longer works:

   ERROR: In procedure scm-error:
   no code for module (gcrypt hash)

Next try: I cloned the repository under a different user account (that
still had the old Guix). "guix environment guix", "bootstrap", and
then "configure" get me to the error message:

  configure: error: A recent Guile-SQLite3 could not be found; please
  install it.

But I cannot install a recent Guile-SQLite3 without doing a "guix pull"
first.

One more option I can think of is installing everything required to
compile Guix manually, then compile from source. Not exactly an
attractive idea, all the more since the dependency list in the Guix
manual looks incomplete (it doesn't mention Guile, for example, nor 
Guile-SQLite3).

Are there any other options ? I would like to avoid deleting everything
and starting from scratch because there is one account on that machine
that has in its Guix profile my only working installation of the only
program I actually need this machine for.

Konrad.

Re: Updating guix for root

[Konrad Hinsen]

Hi Clément and Ricardo,

Thanks for your replies!

I conclude from them that there is no clear recommendation yet for
dealing with this situation, so for the meantime I applied

>>  1) update /etc/systemd/system/guix-daemon.service
>> to point to the current daemon? If so, is
>> /root/.config/guix/current/bin/guix-daemon
>> the right (stable) path to use?

I prefer to point to /root rather then to my $HOME which is less
reliable for reasons completely unrelated to Guix (it's on a zfs volume
shared with macOS).

So far (i.e. for about a day) this seems to work fine!

Thanks again,
  Konrad.]

Updating guix for root

[Konrad Hinsen]

Hi Guixers,

I wonder what the correct way is to update Guix for the root user.
I did "guix pull" and got the new Guix under /root/.config/guix/current.
This also contains the daemon under
/root/.config/guix/current/bin/guix-daemon. So far, fine.

However, the systemd service still launches the daemon from 
/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon. So if I
uninstall the package "guix" for the root account (see
https://www.mail-archive.com/bug-guix@gnu.org/msg09793.html), I will
probably remove the guix-daemon that is used on system startup.

Should I

 1) update /etc/systemd/system/guix-daemon.service
to point to the current daemon? If so, is
/root/.config/guix/current/bin/guix-daemon
the right (stable) path to use?

 2) Get an updated guix-daemon.service from somewhere?
If so, from where?

 3) Do nothing, and keep using the old guix-daemon?

 4) Do yet something else?

Konrad.

Re: Checking for substitutes

[Konrad Hinsen]

Hi Ricardo,


I tried it. It provides interesting statistics, but always considers all
packages in Guix rather than just the ones I care about.


You can pass a manifest to “guix weather”.


Found it in the manual - great! And a quick look at the source shows 
that it shouldn't be too hard to make it print a list of the packages 
that are not available as substitutes. It's on my to-do list...


Thanks,
  Konrad.

Re: Checking for substitutes

[Konrad Hinsen]

Hi Tim,

Thanks for your explanations! I will try out the script you posted
last year. From your description it sounds like good enough to solve my
routine problem, which is that compiling Qt runs out of memory on my
machine unless it's close to idle. No way to have Emacs + Firefox + Qt
compilation with 8 GB of RAM :-(

> There’s also the ‘guix weather’ command.  It is supposed to provide info
> about available substitutes.  I have not made much of use of it, though.

I tried it. It provides interesting statistics, but always considers all
packages in Guix rather than just the ones I care about.

Konrad.

Checking for substitutes

[Konrad Hinsen]

Hi Guix,

I wonder if there is any way to check if substitutes are available for a
given set of packages (e.g. a single package with its dependencies, or a
complete manifest).

The context is optimizing package updates: if I know everything I need
is available as a substitute, I can do an update immediately, but if big
packages need to be built locally, I prefer to wait until my computer is
idle.

Ideally, I'd like "guix package" to have an option –only-substitutes
that will stop if local builds are required, providing a list of the
packages that must be built.

Konrad.

Re: [racket-users] Using Racket's raco on on Guix(SD)

[Konrad Hinsen]

On 22/05/2018 15:42, Christopher Lemmer Webber wrote:


Unfortunately when I try to install packages with "raco pkg install"
I get errors like the following:


I filed a bug report about this problem a while ago:

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

Quote:

  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.


I seem to remember a couple of packages failing altogether, though in
the present moment I think the result is bad performance due to not
being properly compiled, but I'm not really sure.


In my tests, all packages ended up working, but performance is indeed 
worse than with a Racket installation outside of Guix.


It would be nice if someone with more knowledge of Racket internals 
could give a hint or two for debugging this issue!


Konrad.

Re: Emacs in multiple profiles

[Konrad Hinsen]

Hi George,

> I am revamping my emacs config approach and I came across your
> discussion. Following Alex's suggestions I found 2 approaches that seem
> to do what Konrad wanted ...

Thanks a lot - this looks very useful. Your second solution is just fine
for my use case as well. I just wish it were simpler!

Konrad.

Re: Emacs in multiple profiles

[Konrad Hinsen]

Alex Kost  writes:

> It is completely different: with "-Q", your .emacs file is not loaded at
> all, and with "--no-site-file", only the emacs packages from the guix
> profile are not autoloaded.  Isn't that what you wanted?

Not quite: I want it to autoload the packages from my current Guix
profile, not from my main Guix profile.

> If you want to autoload emacs packages from a guix environment (or
> similarly from any non-standard guix profile), you can do it like this:
>
> (let ((guix-env (getenv "GUIX_ENVIRONMENT")))
>   (when (and guix-env
>  (require 'guix-emacs nil t))
> (guix-emacs-autoload-packages guix-env)))

Except that GUIX_ENVIRONMENT is defined only by "guix environment", not
by profiles. Otherwise this would be exactly what I want - and in fact
what I'd expect guix-emacs.el to do, instead of accessing the user's
main profile.

Konrad.

Re: Emacs in multiple profiles

[Konrad Hinsen]

Hi Alex,

Alex Kost  writes:

>> Since nothing runs before site-start.el, I don't see how I could
>> override this definition. My only choice is to use the -Q option on the
>> Emacs command line to bypass site-start.el altogether. But then I don't
>> get the packages from my new profile either.
>
> It's not the only choice.  You can also use "--no-site-file".  It is
> also mentioned at:
>
> https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Emacs-Packages

Right, but that's not very different from -Q: I get no start-site at all
and thus none of the Guix-installed packages. What I am looking for is a
way to get the packages that I put into the profile from which I started
Emacs.

I suspect that this could only be done via some environment variable,
analogous $PATH and others. Emacs doesn't consult any such variable, and
it seems that Guix didn't introduce one either. At least I didn't find
any.

Is this a decision made for a good reason, or just something "to be
done"? I could image guix-emacs.el consult a Guix-specific "Emacs path"
for constructing the internal load-path.

Konrad.

Re: Best practices for Guix environment variables on foreign distro

[Konrad Hinsen]

On 12/03/2018 11:11, Ludovic Courtès wrote:


If my attempt is recommended against then how else should I enable Guix
on Emacs and interactive Bash shells while preventing it from disrupting
the foreign distro (e.g. programs spawned by GNOME)?  Or is this feared
disruption a non-issue in practice and I’m creating unnecessary
complication?


The suggestion is to source ~/.guix-profile/etc/profile from
~/.bash_profile (or similar).


That's what I am using in exactly the same setup (Guix on Ubuntu 
16.04LTS) and it works fine. Sourcing ~/.guix-profile/etc/profile from 
$HOME/.profile, on the other hand, prevents logins to GNOME or Unity 
sessions.


Konrad.

Re: Integrate guix-installed Emacs packages with locally compiled Emacs pretest

[Konrad Hinsen]

On 13/03/2018 00:49, Jorge wrote:


Hi.  I want to use Guix to install notmuch (with the Emacs interface) and
emacs-guix; however, since Guix does not have Emacs 26, I would like to keep
using my locally-compiled Emacs 26.0.91.  Is that possible?  Would it be quicker
to learn Guix packaging and package Emacs 26.0.91 for Guix?


With Emacs, everything is possible :-)

You'd have to do two things in your Emacs configuration:
  - add the notmuch elisp directory from Guix to load-path
  - make sure that your Guix profile is on exec-path

You probably want the latter anyway, so the additional effort looks small.

On the other hand, packaging Emacs 26 for Guix is a nice exercise and 
useful for lots of other people, so I don't want do discourage you from 
trying!


A third option is to use the notmuch executable from Guix but installing 
the e-lisp part via elpa into your non-Guix Emacs. Even with somewhat 
different versions, this should work fine, since the notmuch command 
line interface is very stable.


Konrad.

Re: A few questions about packages

[Konrad Hinsen]

On 07/03/2018 17:09, Jone wrote:

Hello. Can I remove old package versions and other builds? On the 
example of Icecat:


     252.1 MiB [  ] 
/5ym67s5vp1vmnc3y4ds4r3687vc3nl25-icecat-52.6.0-gnu1
     252.0 MiB [  ] 
/360i9ca4gnm3rsjj8v43ih0j3mfrp40n-icecat-52.6.0-gnu1
     246.8 MiB [  ] 
/kd0nnq3i0qarx4vqxcampxfj3igxn84h-icecat-52.3.0-gnu1


"guix gc" will delete all packages that are no longer required. Most 
probably that includes all Icecat installs except for the latest. 
However, if two users on the system have different versions of Icecat 
installed, both will be kept.


And the next question, is also about Icecat: version 52.6.0 was compiled 
from source. This is too long. Can I create binary package from this 
local installation?


In a sense you already have one, stored on your computer. So I guess 
your question is how you can use this binary package on a different 
machine, right? There are two answers to this question:


 1) If the other machine also runs Guix, the answer is "guix archive":

https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-archive

 2) If the other machine does not use Guix, have look at "guix pack":
https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-pack

Konrad.

Re: Posts in languages other than English on help-guix?

[Konrad Hinsen]

On 03/03/2018 11:52, Hartmut Goebel wrote:

Am 03.03.2018 um 11:45 schrieb Hartmut Goebel:

+1 @Ludo: Please use this genter-neutral translation. Thanks.


@Ludo Correction: I've just seen Andreas' translation from 2018-03-03
11:00, which is okay, too. That one works around the gender-issue be
translating more freely and should be preferred IMHO, since it is less
arguable.


+1

Avoiding a problem is always better than solving it.

Konrad (left Germany 25 years ago, so not quite up-to-date with latest 
language fashion)

Re: guixbuild does not exist???

[Konrad Hinsen]

Hi Ricardo and Marius,

Ricardo Wurmus  writes:

> I’m guessing that NSCD is not running.  You might need it on some
> systems.

Marius Bakke  writes:

> This has to do with the recent update to glibc 2.26.  It no longer
> builds the "nss_compat" library, which causes problems on distributions
> that only has 'compat' in /etc/nsswitch.conf.
>
> There is some discussion about it here: .
>
> The workaround is to either install 'nscd', or update nsswitch.conf to
> include 'files' (or similar) as a fallback (for "group" in this case).

Thanks to both of you for the crucial hint. After installing nscd,
I can now again use Guix!

Konrad.

guixbuild does not exist???

[Konrad Hinsen]

Hi Guixers,

Today guix greeted me with a strange error message when I tried to 
install a package:


  guix package: error: build failed: the group `guixbuild' specified in 
`build-users-group' does not exist


I call this strange because
 1) The group exists, as do the users guixbuilder01 to guixbuilder10.
 2) Guix has been working for quite a while on this machine, and 
nothing spectacular happened since the last use.

 3) I cannot find any trace of this error message in the Guix source code.
 4) The guix daemon is running without any sign of trouble.

Any idea of what could be going wrong here?

Konrad.

Re: Proxy authentication

[Konrad Hinsen]

On 23/01/2018 21:40, Jorge wrote:


Now I want to make Guix talk to the corporate proxy server directly (not
mediated by ntlmaps) but then it needs to authenticate.  I could


I had the same problem not so long ago. See this thread on guix-devel 
for the solution:


  http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00070.html

Konrad.

Re: Which version ?

[Konrad Hinsen]

On 21/12/2017 08:44, Catonano wrote:


There's this question

https://octodon.social/@alienghic/99197743305578001 



She's a biologist and I 'd like to help her

But I don't know the answer to her question

Apart from suggesting here to come on this mailing list, what could I 
reply to her ?


Using

  guix --version

you can get the commit ID in the Guix repository that corresponds to 
your installation (i.e. the version you got with your last `guix pull`). 
In general that commit ID does not correspond to any release, so there 
is no point in looking for something release number like 0.14.0.


If you have a local copy of the Guix repository, you can look up the 
commit ID and find a corresponding date (plus tons of more information).


Example (my current installation):

$ guix --version
guix (GNU Guix) 574b1d0262c0e9af8aa7bbfe4998a498f2ba23da
Copyright (C) 2017 the Guix authors
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ git show 574b1d0262c0e9af8aa7bbfe4998a498f2ba23da|more
commit 574b1d0262c0e9af8aa7bbfe4998a498f2ba23da
Author: Tobias Geerinckx-Rice 
Date:   Fri Dec 15 16:44:00 2017 +0100

gnu: python-pyicu: Set python2-variant.

This follows up on commit d65854bdda4ad5464fcd8fe6289eedc13ea82ba1, 
which

did not fix test failures for dependents using package-with-python2.

* gnu/packages/python.scm (python-pyicu)[properties]: Set 
python2-variant.



So my last "guix pull" happened on Dec 15 or shortly thereafter.

Konrad.