Re: cannot run recent kodi [was: substitute server not used]

[Marco van Hulten]

On Sat, 17 Feb 2024 19:54:33 +0100 pelzflorian (Florian Pelz) wrote:
> Marco van Hulten  writes:
> > I told kodi to use the the driver by exporting
> >
> > export 
> > MESA_LOADER_DRIVER_OVERRIDE=../../../m59c9hj9d4n65maimbpmx2xq56d2mvqs-mesa-20.2.4/lib/dri/i915
> >   
> 
> As a blind guess, since a few generations, for VLC I need to use:
> 
> export MESA_LOADER_DRIVER_OVERRIDE=i965

In mesa-20.2.4, this was a symlink:

$ file 
/gnu/store/m59c9hj9d4n65maimbpmx2xq56d2mvqs-mesa-20.2.4/lib/dri/i965_dri.so
/gnu/store/m59c9hj9d4n65maimbpmx2xq56d2mvqs-mesa-20.2.4/lib/dri/i965_dri.so: 
symbolic link to i915_dri.so

My guess is that i915 was thrown out at some point, or i965 got a
proper driver at which (or a later) time the i965 hardware became
incompatible with the i915 driver.

The problem I'm having is that neither the i915 nor the i965 driver are
present in mesa-23.0.3/lib/dri/, which is what kodi asks for.  They are
also not in the newest mesa-23.3.2/lib/dri/.

  Marco

cannot run recent kodi [was: substitute server not used]

[Marco van Hulten]

Hello,

Building the package 'kodi' appears hard, as suggested by the failed
builds at
<https://ci.guix.gnu.org/search?query=kodi-19.5+system%3Ax86_64-linux>.
Building also failed on my machine, probably because it has too little
RAM.  Therefore, I decided to skip kodi in upgrading my system.

On Wed, 14 Feb 2024 20:11:11 +0100 Marco van Hulten wrote:
> After I had done a 'guix package -u . --do-not-upgrade=kodi', I got:
> 
> 
> [kodi@watson ~]$ cat kodi.log.txt 
> libEGL warning: MESA-LOADER: failed to open i915: 
> /gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/i915_dri.so: 
> cannot open shared object file: No such file or directory (search paths 
> /gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri, suffix _dri)
> 
> libva info: VA-API version 1.18.0
> libva info: Trying to open 
> /gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/iHD_drv_video.so
> libva info: va_openDriver() returns -1
> libGL error: MESA-LOADER: failed to open i915: 
> /gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/i915_dri.so: 
> cannot open shared object file: No such file or directory (search paths 
> /gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri, suffix _dri)
> libGL error: failed to load driver: i915
> [...]

kodi wants i915_dri.so from mesa@23.0.3, whereas this does not contain
lib/dri/i915_dri.so.

My problems started after a thorough gc, though I kept a Guix profile
from July 2023.  I can run kodi from that profile, but that is not a
good solution.

This file is available on my system only for mesa@20.0.8 and
mesa@20.2.4.

I told kodi to use the the driver by exporting

export 
MESA_LOADER_DRIVER_OVERRIDE=../../../m59c9hj9d4n65maimbpmx2xq56d2mvqs-mesa-20.2.4/lib/dri/i915

This ended badly:

```
$ kodi
libEGL fatal: did not find extension DRI_Mesa version 1

/home/kodi/.guix-profile/bin/kodi: line 186:  7867 Segmentation fault  
${KODI_BINARY} $SAVED_ARGS
```

That desperate attempt is a horrible hack anyway.  I wonder

1. if a more recent build of kodi@19.5 would actually solve something,
   as it has mesa-23.3.2 as a dependency, which – just like mesa-23.0.3
   – doesn't include the i915 driver either (I checked by installing)
2. whether kodi worked before because it depended on a mesa version
   that did include lib/dri/i915_dri.so

ad. 2)  I now see that in my July 2023 profile the same error appears
(no i915_dri.so available), but it just isn't fatal.  Some videos play
very slowly.  Could that be related to the problem it cannot load this
driver?  The system is not very new (Intel(R) Core(TM)2 Duo CPU E8500
@3.16GHz with 2 GiB RAM).

  Marco

substitute server not used

[Marco van Hulten]

Dear all,

Even though a substitute is available [1], one of my Guix system does
not want to use this:


[kodi@watson ~]$ guix package -u kodi
The following packages will be upgraded:
   kodi (dependencies or package changed)
   kodi-cli (dependencies or package changed)

substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0% substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0% The following derivation will
be built: /gnu/store/mhq3az363na1wnz1mnzy9nln3s5f40a4-kodi-19.5.drv

building /gnu/store/mhq3az363na1wnz1mnzy9nln3s5f40a4-kodi-19.5.drv...
- 'unpack' phase [...]


It is an "upgrade" because of "changed dependencies".  I *suppose* the
substitute is too old for the outputs to be bit identical?  (I hope I
use the right terminology here and this makes sense.)


# Background/rationale for trying to upgrade Kodi

After I had done a 'guix package -u . --do-not-upgrade=kodi', I still
needed to upgrade Kodi, because otherwise:


[kodi@watson ~]$ cat kodi.log.txt 
libEGL warning: MESA-LOADER: failed to open i915: 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/i915_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri, suffix _dri)

libva info: VA-API version 1.18.0
libva info: Trying to open 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libGL error: MESA-LOADER: failed to open i915: 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/i915_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri, suffix _dri)
libGL error: failed to load driver: i915
libGL error: MESA-LOADER: failed to open i915: 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/i915_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri, suffix _dri)
libGL error: failed to load driver: i915
libva info: VA-API version 1.18.0
libva info: Trying to open 
/gnu/store/zisvdry6856i6z4iai62ff6l3anbdld8-mesa-23.0.3/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
/home/kodi/.guix-profile/bin/kodi: line 186:  1634 Segmentation fault  
${KODI_BINARY} $SAVED_ARGS
Crash report available at /home/kodi/kodi_crashlog-20240214_200244.log


Best,
  Marco

[1]: https://ci.guix.gnu.org/build/3395475/details

Sakura is upgraded, or maybe not

[Marco van Hulten]

Hi all,

There is something wrong with the version or version number of Sakura
(a terminal emulator):

marco@graviton ~$ 
/gnu/store/3manvmdcf3zy3h2pyx3ljnam1jm66gka-sakura-3.8.4/bin/sakura --version
sakura version is 3.8.3

I might have a look at the package definition tomorrow.

Marco

networking service problem with static address

[Marco van Hulten]

Hi all,

Sometimes my ethernet interface was not configured at boot.  I do not
know where the problem lies, but I decided to try a static address:

   (service static-networking-service-type
(list (static-networking
(addresses
  (list (network-address
  (device "enp0s25")
  (value "192.168.0.7/16"
(routes   
  (list (network-route
  (destination "default")
  (gateway "192.168.0.11"
(name-servers '("192.168.0.11")

Before this, I used dynamic:

   (service dhcp-client-service-type)

With a static address the interface always comes up configured, at least
so far. (So, at some time, I should check cabling, the DHCP daemon )

But now cups does not always start at boot, so I try to restart:

root@graviton ~# herd start cups
Exception caught while starting networking: (%exception 
#< errno: 17>)
Service cups depends on networking.
herd: error: failed to start service cups
root@graviton ~# herd start networking
herd: error: exception caught while executing 'start' on service 'networking':
Throw to key `%exception' with args `("#< errno: 17>")'.

Should 'networking' not be running when using a static IP?

As another work-around, could I tell the system that cups does not need
the 'networking' dependency?

Here is my cups service config; this is unchanged.

  (service cups-service-type
(cups-configuration
  (web-interface? #t)
  (extensions
(list cups-filters foomatic-filters 
hplip-minimal

—Marco

Re: find and install a LaTeX package

[Marco van Hulten]

On  9 Sep 21:43 Andreas Enge wrote:
> On Wed, Sep 09, 2020 at 03:43:18PM +0200, Marco van Hulten wrote:
> > * Is 'texlive' really complete including all packages published on CTAN?  
> 
> I think so. The big "texlive" package is compiled from one big tarball
> published by the TeXlive project. I am not sure what they put into it,
> but I always thought it was all of CTAN.
> 
> If in doubt, if you have space and if you might need a random CTAN package
> in offline situations, I would recommend the monolithic package. The other
> ones are definitely less complete.

Great, I'll do that for now.

On  9 Sep 22:02 Ricardo Wurmus wrote:
> Marco van Hulten  writes:
> 
> > * CTAN packages in Guix are sometimes named 'texlive-PACKAGE' and
> >   sometimes 'texlive-latex-PACKAGE'.  I find it hard to decide if
> >   something is LaTeX-specific, so should I search for something like
> >   'texlive*-PACKAGE'?  
> 
> Those named “texlive-{latex,generic,tex…}-PACKAGE” are old and are in
> need of serious fixes.
> 
> Do not search for Guix package names.  Instead look at
> 
> $(guix build texlive-bin)/share/tlpkg/texlive.tlpdb
> 
> and then deduce the name of the Guix package.

I did find out that instead of mhchem I can use chemmacros that popped
up in the output from this command.  But then I did 'guix package -s
chemmacros' (I suppose a stupid way to deduce the name of the Guix
package, but I suppose the name won't be hashed or something and thus
this should work), but no package came up.

Because of other issues and lack of time, I'll compile the document on
a different system.

—Marco

find and install a LaTeX package

[Marco van Hulten]

Hi Guix—

I don't always find a LaTeX package on Guix, even if I know its name in
CTAN.

There is the package 'texlive', a complete TeX distribution.  I chose
to install 'texlive-base' plus a number of additional 'texlive-*'
packages instead.  But now it happens sometimes that a certain package
is not available; through ad hoc searching, and sometimes
trial-and-error, I manage to install the right Guix package and I can
compile my LaTeX document.  I have a couple of questions, hoping to
make this experience a bit more smooth.

* CTAN packages in Guix are sometimes named 'texlive-PACKAGE' and
  sometimes 'texlive-latex-PACKAGE'.  I find it hard to decide if
  something is LaTeX-specific, so should I search for something like
  'texlive*-PACKAGE'?
* Is 'texlive' really complete including all packages published on CTAN?
* If not, what *is* included in the full TeX Live distribution?

I suppose, if I invest a lot of time, I could try to understand CTAN
and also more of Guix, but I am hoping that there is a relatively "user
friendly" answer available.  I know a serious of effort is done to
improve the TeX Live situation significantly, but I'm still from time
to time at a loss to get a document compiled.

Thanks for pointers.

—Marco

Re: Unison GTK UI in unison package

[Marco van Hulten]

Hello—

To synchronise file with a server I don't operate, I would like to use
unison@2.48.15 on my Guix System, preferably the GUI*.  The last e-mail
I could find about this on the mailinglists looks relevant.

Je 2 apr 2018 16:16 skribis Leo:
> On Mon, Apr 02, 2018 at 02:10:22PM +0200, Arnaud B wrote:
> > I looked at the ocaml.scm file where the unison package is defined,
> > together with ocaml, lablgtk and a number of other related tools. It uses
> > the gtk module (gnu packages gtk), in which there is pango as well.  
> 
> > So it seems everything is in place to build unison and at the same time its
> > graphical version, according to the build instructions
> > 
> > given for that.
> > But in the end in my GuixSD as the user having done the installation, I
> > just end up with the CLI unison and not unison-gtk2 as expected.
> > I tried explicitly installing various packages such as gtk+, lablgtk, and
> > then rebuilding the unison package, to no avail.  
> 
> Basically, the packages that are required to build the Unison GUI, such
> as lablgtk, GTK+ itself, etc, are not present in the environment where
> Unison is built by Guix. They may be defined in the same source file as
> the Unison package, or they may be imported by that file, but this does
> not mean they are present in the Unison build environment. Additionally,
> installing a package with `guix package --install` has no effect on how
> packages are built.
> 
> Each time Guix builds a package, it uses an isolated environment that
> only includes the software specified in the package definition of the
> package being built, as well as "implicit" dependencies that come with
> the specified build system.
> 
> To make progress on building the Unison GUI, I recommend adding the
> required packages to a new inputs field in the Unison package
> definition. You can copy the structure of the native-inputs field for
> this.
> 
> I recommend reading the Introduction of the Guix manual [0], and
> continuing to other sections as your interest allows. You will also find
> some useful info in Package Reference [1].
> 
> Please don't hesitate to ask more questions here or on the Guix IRC
> channel, #guix on Freenode.
> 
> [0]
> https://www.gnu.org/software/guix/manual/html_node/Introduction.html
> 
> [1]
> https://www.gnu.org/software/guix/manual/html_node/package-Reference.html

Arnaud, did you ever look into this again?  Did you find a solution for
synchronising between Guix and the other system?

I vaguely remember that at some time there were several Unison versions
available on Guix.

Of course, I might try to build Unison 2.51.2 on the non-Guix system.

—Marco

* Works nice to put unison-gtk in .xinitrc, before and after running
  your window manager.


pgpZv15zcxFwS.pgp
Description: OpenPGP digitale handtekening

Re: ungoogled-chromium

[Marco van Hulten]

Vagrant—

Je 22 Mar 06:14 skribis Vagrant:
> I'm curious if you can get audio or microphone access using
> ungoogled-chromium on meet.jit.si... video worked fine for me, but
> neither audio output nor microphone input worked.  Are there optional
> plugins needed to make audio work with ungoogled-chromium?

No, it worked out-of-the-box for me.  I am using a USB-connected
microphone (C-Media Blue Snowball).

I don't have an audio_capture_enabled line in Chromium's Preferences.

> On the same system, audio output worked fine with icecat, though
> meet.jit.si wasn't supported at all on icecat.

Same experience for me.  I vaguely remember a message on this list (or
guix-devel) about media input issues with Icecat, possibly related to
WebRTC.

—Marco

Re: ungoogled-chromium

[Marco van Hulten]

Ricardo—

Je 22 Mar 13:37 skribis Ricardo:
> > I installed ungoogled-chromium.  When it starts and I browse to the
> > main Jitsi instance [1], it wants to install the extension for Google
> > Calendar and Office 365 integration.  I don't know if those are
> > non-free softwares, but they at least provide non-free web services.  
> 
> It seems to me that these suggestions are triggered by the website.
> We don’t attempt to filter website contents.

Thanks for this info, also Marius.  Then there is no issue with the
ungoogled-chromium package.

I might look into what meet.jit.si is doing.

—Marco

Re: ungoogled-chromium suggests extension

[Marco van Hulten]

Je 22 Mar 13:02 skribis Marco:
> Hello—
> 
> I installed ungoogled-chromium.  When it starts and I browse to the
> main Jitsi instance [1], it wants to install the extension for Google
> Calendar and Office 365 integration.  I don't know if those are
> non-free softwares, but they at least provide non-free web services.
> 
> I think this suggestion should not happen.

I am using Chromium 80.0 on Guix System:

$ file $(which chromium)
/home/marco/.guix-profile/bin/chromium: symbolic link to 
/gnu/store/z3r5sf0q0jmb2yhxqpag3snlhvnbsanf-ungoogled-chromium-80.0.3987.132-0.7e68f18/bin/chromium

I think this should not be considered a bug when meet.jit.si is
suggesting to install this extension.  It happens when I go there, not
when I go to slashdot.org, for instance.  It would be weird if
meet.jit.si is suggesting this extension.

Any ideas?

—Marco

[1]: https://meet.jit.si/

ungoogled-chromium

[Marco van Hulten]

Hello—

I installed ungoogled-chromium.  When it starts and I browse to the
main Jitsi instance [1], it wants to install the extension for Google
Calendar and Office 365 integration.  I don't know if those are
non-free softwares, but they at least provide non-free web services.

I think this suggestion should not happen.

—Marco

[1]: https://meet.jit.si/

Re: TeX Live: lualatex looks in /usr

[Marco van Hulten]

Hi Ricardo—

Je 22 feb 21:41 skribis Ricardo:
> > lualatex (from texlive-20180414) is looking in /usr/local/.
> >
> >
> > $ lualatex apen
> > This is LuaTeX, Version 1.07.0 (TeX Live 2018) 
> >  restricted system commands enabled.
> > (./apen.tex[\directlua]:1: module 'lualatexquotejobname.lua' not found:
> > no field package.preload['lualatexquotejobname.lua']
> > [kpse lua searcher] file not found: 'lualatexquotejobname.lua'
> > [kpse C searcher] file not found: 'lualatexquotejobname.lua'
> > no file '/usr/local/lib/lua/5.2/lualatexquotejobname.so'
> > no file '/usr/local/lib/lua/5.2/loadall.so'
> > no file './lualatexquotejobname.so'
> > stack traceback:  
> > [C]: in function 'require'
> > [\directlua]:1: in main chunk.
> >  \directlua {require("lualatexquotejobname.lua")}
> > \typeout {\fmtname \space 
> > <\fmt
> > l.1
> >   \documentclass{article}  
> 
> Please show us the file you’re working with and the texlive packages you
> have installed.

$ cat apen.tex
\documentclass{article}
\author{Marco}
\title{Een titel}

\begin{document}
\maketitle
Wat een rare jongens!
\end{document}
$ guix package -I | grep texlive
texlive 20180414out 
/gnu/store/wlba9v03ypi0z5qz7p89sa0w12lh37zb-texlive-20180414


—Marco

Re: TeX Live: lualatex looks in /usr

[Marco van Hulten]

Je 22 feb 18:15 skribis Marco:
> lualatex (from texlive-20180414) is looking in /usr/local/.

This happens from a terminal, but from Texmaker lualatex works (builds
a good PDF).

—Marco

TeX Live: lualatex looks in /usr

[Marco van Hulten]

Hi all—

lualatex (from texlive-20180414) is looking in /usr/local/.


$ lualatex apen
This is LuaTeX, Version 1.07.0 (TeX Live 2018) 
 restricted system commands enabled.
(./apen.tex[\directlua]:1: module 'lualatexquotejobname.lua' not found:
no field package.preload['lualatexquotejobname.lua']
[kpse lua searcher] file not found: 'lualatexquotejobname.lua'
[kpse C searcher] file not found: 'lualatexquotejobname.lua'
no file '/usr/local/lib/lua/5.2/lualatexquotejobname.so'
no file '/usr/local/lib/lua/5.2/loadall.so'
no file './lualatexquotejobname.so'
stack traceback:  
[C]: in function 'require'
[\directlua]:1: in main chunk.
 \directlua {require("lualatexquotejobname.lua")}
\typeout {\fmtname \space <\fmt
l.1
  \documentclass{article}


This looks like a bug.  What would be the best approach.

I do not want energy be spend to get old stuff working.

At the same time, installing texlive-base from the core-updates branch
has problems as well here (on this list, one month ago).

—Marco

Re: TeX Live issues

[Marco van Hulten]

Je 19 jan 17:34 skribis Marco:
> I had GUIX_LOCPATH set but did not have glibc-locales installed.
> Installing this packages solved the issue and I can now compile TeX
> files with success.  Thanks for the help!
> 
> To recap, to reduce the damage of going off-topic, compiling a TeX file
> with {,lua}latex works when only texlive-base is installed.  I had to
> do this:
> 
> guix pull --branch=core-updates
> guix package -r texlive texlive-bin texlive-latex-base -i texlive-base

I've done all these things (locales, installed only texlive-base from
core-updates branch, removed any other texlive* packages and removed
~/.texlive*), now under a different user, same Guix system.  I have
issues again:

```
$ lualatex apen
This is LuaTeX, Version 1.10.0 (TeX Live 2019) 
 restricted system commands enabled.

kpathsea: Running mktexfmt lualatex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence 
order):
mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
mktexfmt:   /home/otheruser/.texlive2019/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under 
/home/otheruser/.texlive2019/texmf-var/web2c
mktexfmt [INFO]: did not find entry for byfmt=lualatex, skipped
mktexfmt [INFO]: Total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `lualatex.fmt'!
```

Given the similarity of the issue (except for that this does not now
relate to the package texlive-bin-20180414 as it is not installed), the
fact that I won't have a lot of time at the moment and don't want to
waste other people's time, and that there will be a next staging branch
soon, would it be best to wait when the latter happens and switch to
that one?

Of course, if there is still an actual issue (instead of user error) it
may actually be relevant to look at this more closely (but I don't know
anymore!), so here is at least some info:

$ guix package -I | grep texlive
texlive-base51265   out 
/gnu/store/iccw4cdkcgmccl5svndji830k55v9cxy-texlive-base-51265

—Marco

Re: TeX Live issues

[Marco van Hulten]

Ricardo—

Je 19 jan 16:01 skribis Ricardo:
> > marco@graviton ~$ guix package -I | grep texlive
> > guile: warning: failed to install locale
> > texlive-base51265   out 
> > /gnu/store/iccw4cdkcgmccl5svndji830k55v9cxy-texlive-base-51265
> > ```
> >
> > But I have a locale issue:
> >
> > ```
> > marco@graviton ~/temp$ export LANG="nl_NL.utf8"
> > marco@graviton ~/temp$ lualatex test
> > Unable to read environment locale: exit now.
> > marco@graviton ~/temp$ locale -a | grep '\bnl_NL.utf8\b'
> > nl_NL.utf8
> > ```  
> 
> Earlier when you ran “guix package -I” you had the same issue.  Please
> take a look at the “Application Setup” section in the manual.  It tells
> you how to set up things.

I had GUIX_LOCPATH set but did not have glibc-locales installed.
Installing this packages solved the issue and I can now compile TeX
files with success.  Thanks for the help!

To recap, to reduce the damage of going off-topic, compiling a TeX file
with {,lua}latex works when only texlive-base is installed.  I had to
do this:

guix pull --branch=core-updates
guix package -r texlive texlive-bin texlive-latex-base -i texlive-base

—Marco

Re: TeX Live issues

[Marco van Hulten]

Ricardo—

Je 19 jan 14:42 skribis Ricardo:
> > Removing texlive (which is from the master branch) makes sense.
> >
> > But now there are no "latex" or "lualatex" binaries.  Which packages
> > should contain the basic binaries?  
> 
> Please install “texlive-base”, not “texlive-latex-base”.  This should
> give you the minimal set of TeX Live packages alongside the executables.

There is progress; I have now installed texlive-base without
conflicting packages:

```
marco@graviton ~$ guix package -r texlive-latex-base texlive-fonts-latex -i 
texlive-base
guile: warning: failed to install locale
The following packages will be removed:
   texlive-latex-base   51265   
/gnu/store/s9qr333cj87mc1gpns1xcid763mfgfz3-texlive-latex-base-51265
   texlive-fonts-latex  49435   
/gnu/store/5m5nqvjvykw9xgfsv4azs4iv2dw03kf0-texlive-fonts-latex-49435

The following package will be installed:
   texlive-base 51265   
/gnu/store/iccw4cdkcgmccl5svndji830k55v9cxy-texlive-base-51265

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/7lki7hpac5nf4qgnb54zis44m834v6cj-profile.drv
   /gnu/store/dqdg9ghskvjnvz73hh7x1f0b8wiaffkx-texlive-base-51265.drv
The following profile hooks will be built:
   /gnu/store/03k448bg3i6391n0aixka6ikm5bc6j2a-gtk-im-modules.drv
   /gnu/store/102xji5hvss21jg9r8zn8xwchnkyqknb-xdg-mime-database.drv
   /gnu/store/7vxdmwddij0ggnvk958bgy6pii0v1fk0-ca-certificate-bundle.drv
   /gnu/store/dzcdjfw0f08cq4bbq7mm377srv6hfplf-texlive-configuration.drv
   /gnu/store/haph9h15ky4vsvmxs1pgkiqphbiki517-glib-schemas.drv
   /gnu/store/jf3jg046qdb4kxxdkf15a13q433w002m-gtk-icon-themes.drv
   /gnu/store/m3sd8zhn7qa7c1m017ga0lz72j0q8lv0-fonts-dir.drv
   /gnu/store/mr50ypjcxxy8a0bzsw2swqhv51kw6fv9-info-dir.drv
   /gnu/store/q70mkdl367cn5a2rivx59z9gr3nwqf5l-manual-database.drv
   /gnu/store/vswv1a5ja58i5r9j88zxk0q777vjdmf6-xdg-desktop-database.drv
building /gnu/store/dqdg9ghskvjnvz73hh7x1f0b8wiaffkx-texlive-base-51265.drv...
building CA certificate bundle...
building fonts directory...
generating GLib schema cache...
creating GTK+ icon theme cache...
building cache files for GTK+ input methods...
building directory of Info manuals...
building database for manual pages...
building TeX Live configuration...
building XDG desktop file cache...
building XDG MIME database...
building /gnu/store/7lki7hpac5nf4qgnb54zis44m834v6cj-profile.drv...
74 packages in profile
marco@graviton ~$ guix package -I | grep texlive
guile: warning: failed to install locale
texlive-base51265   out 
/gnu/store/iccw4cdkcgmccl5svndji830k55v9cxy-texlive-base-51265
```

But I have a locale issue:

```
marco@graviton ~/temp$ export LANG="nl_NL.utf8"
marco@graviton ~/temp$ lualatex test
Unable to read environment locale: exit now.
marco@graviton ~/temp$ locale -a | grep '\bnl_NL.utf8\b'
nl_NL.utf8
```

—Marco

Re: TeX Live issues

[Marco van Hulten]

Ricardo—

Je 19 jan 09:59 skribis Ricardo:
> Marco van Hulten  writes:
> 
> > Je 18 jan 16:12 skribis Ricardo:  
> >> Can you show us what “guix package -I | grep texlive” says?  Also please
> >> remove ~/.texlive* if it exists and show us the output of “env”.  
> >
> > marco@graviton ~$ guix package -I | grep texlive
> > guile: warning: failed to install locale
> > texlive-fonts-latex 49435   out 
> > /gnu/store/5m5nqvjvykw9xgfsv4azs4iv2dw03kf0-texlive-fonts-latex-49435
> > texlive 20180414out 
> > /gnu/store/wlba9v03ypi0z5qz7p89sa0w12lh37zb-texlive-20180414
> > texlive-latex-base  51265   out 
> > /gnu/store/s9qr333cj87mc1gpns1xcid763mfgfz3-texlive-latex-base-51265  
> 
> Please remove the “texlive” package from your profile.
> The env output looks fine.

Removing texlive (which is from the master branch) makes sense.

But now there are no "latex" or "lualatex" binaries.  Which packages
should contain the basic binaries?

I remember that in Debian there are texlive-{minimal,recommended,full}
meta packages.  I have always found TeX Live packaging very
unintelligible.  I do not know how to find any LaTeX package.

—Marco

Re: TeX Live issues

[Marco van Hulten]

Je 18 jan 16:12 skribis Ricardo:
> Can you show us what “guix package -I | grep texlive” says?  Also please
> remove ~/.texlive* if it exists and show us the output of “env”.

marco@graviton ~$ guix package -I | grep texlive
guile: warning: failed to install locale
texlive-fonts-latex 49435   out 
/gnu/store/5m5nqvjvykw9xgfsv4azs4iv2dw03kf0-texlive-fonts-latex-49435
texlive 20180414out 
/gnu/store/wlba9v03ypi0z5qz7p89sa0w12lh37zb-texlive-20180414
texlive-latex-base  51265   out 
/gnu/store/s9qr333cj87mc1gpns1xcid763mfgfz3-texlive-latex-base-51265

marco@graviton ~/temp$ rm -rf .texlive*
marco@graviton ~/temp$ latex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded 
format=latex)
 restricted \write18 enabled.
---! /home/marco/.guix-profile/share/texmf-dist/web2c/latex.fmt made by 
different executable version
(Fatal format file error; I'm stymied)

marco@graviton ~/temp$ env
SHELL=/gnu/store/n1c9jiv2njnvdfz58v71fvzq0hkgivz1-bash-5.0.7/bin/bash
WINDOWID=41943043
FER_DATA=/scratch/fer_dsets/data
COLORTERM=truecolor
XDG_CONFIG_DIRS=/home/marco/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
FER_PALETTE=/home/marco/ferret/palettes /lokale-data/scratch/ferret/ppl
BASH_LOADABLES_PATH=/run/current-system/profile/lib/bash
LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules
XCURSOR_PATH=/home/marco/.icons:/home/marco/.guix-profile/share/icons:/run/current-system/profile/share/icons
FER_GO=/lokale-data/scratch/ferret/go /home/marco/ferret/scripts
NM_VPN_PLUGIN_DIR=/gnu/store/70sm39p9sxrjjlg66r5fgxs9aik1fvnj-network-manager-vpn-plugins/lib/NetworkManager/VPN
SWM_STARTED=YES
GPG_TTY=/dev/pts/4
GTK_DATA_PREFIX=/run/current-system/profile
XDG_SEAT=seat0
PWD=/home/marco/temp
LOGNAME=marco
XDG_SESSION_TYPE=x11
MANPATH=/run/current-system/profile/share/man:/home/marco/.guix-profile/share/man:/run/current-system/profile/share/man
GUILE_LOAD_PATH=/home/marco/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2
XAUTHORITY=/home/marco/.Xauthority
FER_FONTS=/lokale-data/scratch/ferret/ppl/fonts
X_XFCE4_LIB_DIRS=/run/current-system/profile/lib/xfce4
LD_PRELOAD=/gnu/store/dh3243hav0ldyy42sd0b0p7f52s1ns7f-spectrwm-3.2.0/lib/libswmhack.so.0.0
GIT_EXEC_PATH=/home/marco/.guix-profile/libexec/git-core
HOME=/home/marco
_SWM_PID=22164
GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
LANG=en_US.utf8
FER_GRIDS=/scratch/fer_dsets/grids
VTE_VERSION=5802
TEXMF=/home/marco/.guix-profile/share/texmf-dist
SSL_CERT_DIR=/etc/ssl/certs
_SWM_WS=3
GIO_EXTRA_MODULES=/home/marco/.guix-profile/lib/gio/modules:/home/marco/.guix-profile/lib/gio/modules
PULSE_CLIENTCONFIG=/etc/pulse/client.conf
GUILE_LOAD_COMPILED_PATH=/home/marco/.guix-profile/lib/guile/2.2/site-ccache:/run/current-system/profile/lib/guile/2.2/site-ccache
INFOPATH=/home/marco/.config/guix/current/share/info:/home/marco/.guix-profile/share/info:/run/current-system/profile/share/info:/home/marco/.guix-profile/share/info:/run/current-system/profile/share/info
DICPATH=/home/marco/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell
XDG_SESSION_CLASS=user
DBUS_FATAL_WARNINGS=0
PYTHONPATH=/home/marco/.guix-profile/lib/python3.7/site-packages:/home/marco/.guix-profile/lib/python3.7/site-packages
TERM=xterm-termite
TEXMFCNF=/home/marco/.guix-profile/share/texmf-dist/web2c
ACLOCAL_PATH=/home/marco/.guix-profile/share/aclocal
USER=marco
LIBRARY_PATH=/home/marco/.guix-profile/lib:/home/marco/.guix-profile/lib
FER_DIR=/lokale-data/scratch/ferret
TZDIR=/gnu/store/9mmsilz9avdl49i6a6nj5mzfyim8ihv2-tzdata-2019c/share/zoneinfo
VISUAL=vim
DISPLAY=:0
SHLVL=1
PLOTFONTS=/lokale-data/scratch/ferret/ppl/fonts
GUIX_LOCPATH=/home/marco/.guix-profile/lib/locale
XDG_VTNR=7
XDG_SESSION_ID=c5
GST_PLUGIN_PATH=/home/marco/.guix-profile/lib/gstreamer-1.0
TERMINFO_DIRS=/home/marco/.guix-profile/share/terminfo
XDG_RUNTIME_DIR=/run/user/1000
SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
PULSE_CONFIG=/etc/pulse/daemon.conf
XDG_DATA_DIRS=/home/marco/.guix-profile/share:/run/current-system/profile/share:/home/marco/.guix-profile/share:/run/current-system/profile/share
PATH=/run/setuid-programs:/home/marco/.config/guix/current/bin:/home/marco/.guix-profile/bin:/home/marco/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin
FER_DESCR=/scratch/fer_dsets/descr
FER_DSETS=/scratch/fer_dsets
MAIL=/var/mail/marco
CPATH=/home/marco/.guix-profile/include:/home/marco/.guix-profile/include
GUIX_GTK3_PATH=/run/current-system/profile/lib/gtk-3.0
_=/run/current-system/profile/bin/env
OLDPWD=/home/marco


—Marco

Re: TeX Live issues

[Marco van Hulten]

Je 17 jan 13:05 skribis Ricardo:
> Marco van Hulten  writes:
> 
> > Ricardo—
> >
> > On 17 Jan 10:03 Ricardo Wurmus wrote:  
> >> > I am unable to use LaTeX and friends.  I get this error:  
> >>
> >> Hmm, something broke here.  I also cannot compile my older documents any
> >> more.  I’ll investigate.  
> >
> > That's great, thanks!  
> 
> This is now fixed on the core-updates branch.  Note that it should not
> be a problem that pdftex.map cannot be found.  The PDF file gets
> generated just fine.

Thank you for fixing this bug!

I switched to the core-updates branch, but I am not sure if I did it
correctly.  First I did

guix pull --branch=core-updates

which seemed to work fine as there is a new current-guix link.  Then I
tried

guix package -i texlive-latex-base -u

which did not succeed:

...
   readline 8.0 → 8.0.1 
/gnu/store/hjh0n0f734q1mx9dnjlwisjl32nn43yl-readline-8.0.1
   pinentry-gtk21.1.0 → 1.1.0   
/gnu/store/g7ymwwc10gzzqkzbvnqxg07lvls369my-pinentry-gtk2-1.1.0
   claws-mail   3.17.4 → 3.17.4 
/gnu/store/6gzi2jhj5v1j3scrmfmcrckcph9vpjmz-claws-mail-3.17.4
   The following package will be installed:
   texlive-latex-base 51265   
/gnu/store/s9qr333cj87mc1gpns1xcid763mfgfz3-texlive-latex-base-51265
   substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
162.2% guix package: error: got unexpected path 
`/gnu/store/dwynpdsqpw24q1rkia7j4ifscc1ph2wg-libfontenc-1.1.4.tar.bz2' from 
substituter

(sorry for mangling of the lines; pasted text should never be touched,
it's really Claws Mail's fault).  Whereas that did not work, I was able
to only install texlive-latex-base, but compilation of a document gives:

$ lualatex test
This is LuaTeX, Version 1.07.0 (TeX Live 2018) 
 restricted system commands enabled.

(Fatal format file error; I'm stymied)
$ latex test
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded 
format=latex)
 restricted \write18 enabled.
---! /home/marco/.guix-profile/share/texmf-dist/web2c/latex.fmt made by 
different executable version
(Fatal format file error; I'm stymied)

So what my actual question here probably is: How do I make sure things
are consistent when switching branch?

—Marco

Re: TeX Live issues

[Marco van Hulten]

Je 17 jan 08:48 skribis Marco:
> Hi there—
> 
> I am unable to use LaTeX and friends.  I get this error:
> 
> [...]

and in another profile yet another issue:

```
$ pdflatex test
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded 
format=pdflatex)
 restricted \write18 enabled.

kpathsea: Running mktexfmt pdflatex.fmt
/gnu/store/znf7mmx3vslsscn9v3ilxmgkirqwswy8-texlive-bin-20180414/share/texmf-dist/scripts/texlive/fmtutil.pl:
 Unexpected non-option argument(s): pdflatex.fmt
Try "fmtutil --help" for more information.
I can't find the format file `pdflatex.fmt'!
```

—Marco

TeX Live issues

[Marco van Hulten]

Hi there—

I am unable to use LaTeX and friends.  I get this error:

```
$ cat apen.tex 
\documentclass{article}
\author{Marco}
\title{Een titel}

\begin{document}
\maketitle
Wat een rare jongens!
\end{document}
$ latex apen
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded 
format=latex)
 restricted \write18 enabled.
entering extended mode
(./apen.tex
LaTeX2e <2018-04-01> patch level 2
Babel <3.18> and hyphenation patterns for 84 language(s) loaded.

! LaTeX Error: File `article.cls' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: cls)

Enter file name: 
```

I am using the big texlive@20180414 package.  Is this a known issue?

Can I do something to test the more modular set-up of TeX Live?

—Marco

Re: protect generations

[Marco van Hulten]

Marius Bakke wrote:
> There are AFAIK two ways in which 'guix gc' can delete "live" profiles:
> 
> 1. you used the '-d' option, which deletes old profile generations,
>optionally filtering on age

This was the case.  I did

guix gc --delete-generations=1m

which deleted the last month of generations.  The profile that I wanted
to retain was a bit older than one month.

Apropos, in the documentation of 'guix gc' I read:

> -d [duration]
> 
> Before starting the garbage collection process, delete all the
> generations older than duration, for all the user profiles; when
> run as root, this applies to all the profiles of all the users.

I suppose the first mention of "all the user profiles" should not be
there, as a non-priviledged user should not be able to remove
generations from others' user profiles.  (This does, indeed, appear not
to be the case — the accidental removal of the generation in question
was one of the user who ran the gc command; other users' old
generation stayed in tact.)  Instead it should read

> -d [duration]
> 
> Before starting the garbage collection process, delete all the
> generations older than duration from the current user's profile; when
> run as root, this applies to all the profiles of all the users.


Je  7 jan 13:11 skribis zimoun:
> On Sun, 5 Jan 2020 at 22:42, Marco van Hulten  wrote:
> 
> > One of the great features of Guix is that one can roll back his
> > profile.  But I did a garbage collection (gc) that was too aggressive
> > such that a relevant old profile disappeared.  I presume this is gone
> > forever.  
> 
> From my understanding, yes gone but not necessary forever.
> 
> How did you instantiate the profile? Using a manifest file? Did the
> profile use only one Guix commit or several?
> How aggressive it was? What did you run?

I have never used manifest files but usually use the imperative method
of 'guix package -i ... -r ... -u' or sometimes I change to another
"live" profile.

> > Is it possible to lock certain generations (of certain users) such that
> > 'guix gc' would not touch it?  
> 
> Interesting whislist.

In retrospect, a realisation of this wish would probably introduce
unnecessary complexity of 'guix gc'.  So nevermind.  :-)

> Currently, the easiest way to protect the state of a profile is to
> write down a manifest file, IMHO.
> If this manifest file track the Guix commit and the targeted packages,
> then you can re-instantiate this very profile whereever and whenever
> you want to.

I see how I can declare a specific manifest be used (by giving the
manifest file).  How do I create (or where do I find) the manifest file
from the currently running generations?

Can you give a minor clarification on the terms 'generation' and
'profile'?  I understand that the a generation is an abstract term
defining a profile.  Generations correspond with

/var/guix/profiles/per-user/*/guix-profile*

, which is actually a subset, above referred to as "live" profiles.  The
running profile is the realpath(1) of ~/.guix-profile/.

Are 'generations' and 'profiles' not basically the same thing?

Instead of trying to restore the removed generation/profile, I try to
fix the issue that I'm experiencing in newer generations.  I might ask
about this in a new thread if I cannot figure it out.

—Marco

protect generations

[Marco van Hulten]

Hello—

One of the great features of Guix is that one can roll back his
profile.  But I did a garbage collection (gc) that was too aggressive
such that a relevant old profile disappeared.  I presume this is gone
forever.

Is it possible to lock certain generations (of certain users) such that
'guix gc' would not touch it?

—Marco

Re: gpg-agent error: No pinentry

[Marco van Hulten]

Gábor—

Thank you for the help: the issue might have been solved, at least
sometimes (sort-of explanation follows)!

Je 20 dec 20:12 skribis Gábor:
> If you still have the patience to experiment a little could you try
> with pinentry-tty on the console and pinentry-gtk on a gui?

Yes, I just had a little bit of time before the new year.  (Christmas is
a holiday, they say!)

> It might be a valuable experience, and a feedback that our simple
> pinentry is faulty in some ways.
> 
> I have extracted the inforamtions from my config, and it looks like this:
> 
> manifest: (specifications->manifest '("gnupg" "pinentry-tty"))
> 
> I also use guix home-manager [...]

A guix home-manager sounds intriguing.  I alluded to it once when
asking why we wouldn't define the state of the whole computing
environment.  But it adds a layer of complexity and so I don't think it
would be very useful to use this to analyse the problem I'm having.

> I am using bash, and I also have:
> 
> At the end of my .bashrc:
> export GPG_TTY=$(tty)
> 
> And at the end of my .bash_profile:
> 
> gpg-agent --options /home/gabriel/.home-config/.gnupg/gpg-agent.conf --daemon
> 
> I believe that is all.
> 
> Could you have a look if it works for you with these settings? Also,
> please not that these are for console only use, most probably some
> other tweaks are needed to use this form a gui.

Yes, this helps!  That is, when I set GPG_TTY and started the gpg-agent
like this, 'gpg --import' and 'gpg -d' started to work without
complaining about pinentry.  But then I tried the same as another user
and there it still complained.  So I went back to the first user again,
removed the GPG_TTY variable and killed the gpg-agent, but now it does
not complain anymore about pinentry anymore at all.

I don't understand what's going on, but for now I'll just add the export
and gpg-agent commands in my .bashrc since that seemed to do the trick
at least once.

export GPG_TTY=$(tty)
gpg-agent --options ${HOME}/.gnupg/gpg-agent.conf --daemon

—Marco

Re: gpg-agent error: No pinentry

[Marco van Hulten]

Following up on my pinentry issue—

In the end I used a work-around.  I decrypted the sensitive file on an
off-line OpenBSD machine onto a mounted USB flash drive, then mounted
the drive to the Guix machine, did what I needed to do with the file,
shredded any copy of the file and finally removed the USB drive and
destroyed it with a hammer.

—Marco

Re: gpg-agent error: No pinentry

[Marco van Hulten]

correction follows inline—

Any help is appreciated.

Je 19 dec 09:22 skribis Marco:
> Je 18 dec 22:50 skribis Andreas:
> > On Wed, Dec 18, 2019 at 10:41:27PM +0100, Marco van Hulten wrote:  
> > > Do I need to do any more actions accept for 'guix package -i gnupg
> > > pinentry'?
> > 
> > I also have a file .gnupg/gpg-agent.conf in my home directory
> > containing the following lines:
> > 
> > default-cache-ttl 300
> > max-cache-ttl 3600
> > pinentry-program /home/USERNAME/.guix-profile/bin/pinentry-curses  
> 
> Thank you, Andreas and Gábor, very useful to know that pinentry-program
> should be set.  I did so:
> 
> $ file $(realpath $(grep ^pinentry-program ~/.gnupg/gpg-agent.conf | awk 
> '{print $2}'))
> /gnu/store/12gagy0ql4v7qlv9px54lz5fy4d7gff9-pinentry-tty-1.1.0/bin/pinentry-tty:
> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
> interpreter 
> /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/ld-linux-x86-64.so.2,
> for GNU/Linux 2.6.32, not stripped
> 
> Importing a public and private key pair, following [1], worked properly
> now, but it still complains when decrypting a file.
> 
> [1]: https://www.debuntu.org/how-to-importexport-gpg-key-pair/
> 
> To be sure, if I now try to remove the key, 'gpg --delete-key publiko',
> it says that I need to use option "--delete-secret-keys" to delete the
> private key first.  So it appears to be really there.  However,
> 
> $ date | gpg -e > jadaja.gpg
> gpg: encrypted with 4096-bit RSA key, ID 54AE7D44B93BDBDF, created 
> 2019-05-30
>   "Marco van Hulten (publiko) "
> gpg: public key decryption failed: No pinentry
> gpg: decryption failed: No secret key

Sorry, the lines were not copied consistently.  Now the whole
encryption/decryption process verbatimly copied from my terminal:

$ date > test.txt
$ gpg --output test.txt.gpg --encrypt --recipient ma...@hulten.org test.txt
$ gpg --decrypt test.txt.gpg 
gpg: encrypted with 4096-bit RSA key, ID 54AE7D44B93BDBDF, created 
2019-05-30
  "Marco van Hulten (publiko) "
gpg: public key decryption failed: No pinentry
gpg: decryption failed: No secret key

> I tried killing gpg-agent to be sure it uses the current configuration,
> but again it complains about pinentry.
> 
> Apropos, I this e-mail is signed with this very key.
> 
> —Marco


pgprh8_1KrGWw.pgp
Description: OpenPGP digitale handtekening

gpg-agent error: No pinentry

[Marco van Hulten]

Hello—

I have installed gnupg 2.2.18 and pinentry 1.1.0 on a Guix System.
When I try to import a key, I get this issue:

$ gpg --import publiko-secret.asc 
gpg: key 9FC3734DFB84400D: "Marco van Hulten (publiko) " not 
changed
gpg: key 9FC3734DFB84400D/9FC3734DFB84400D: error sending to agent: No pinentry
gpg: error building skey array: No pinentry
gpg: error reading 'publiko-secret.asc': No pinentry
gpg: import from 'publiko-secret.asc' failed: No pinentry
gpg: Total number processed: 0
gpg:  unchanged: 1
gpg:   secret keys read: 1

It seems that the public key is imported but not the private key (I can
encrypt but not decrypt).  On an OpenBSD-current system importing this
key works properly.

Do I need to do any more actions accept for 'guix package -i gnupg
pinentry'?

Thanks,

—Marco

Re: xdm

[Marco van Hulten]

On 26 Nov 14:06 ng0 wrote:
> I have bits of an xdm package somewhere in my vault/archive of
> "packages to send to guix once I find time to contribute again".
> 
> What makes it more complicated / time consuming with xdm is that
> you need to figure out the service for it.
> 
> If you or anyone else wants to work on it, I can send a patch (external, not 
> applying to
> guix.git).

To be honest, I have not allocated enough time for Guix development for
any significant contribution like an xdm package.  I hope 2020 will be
better.  I hope someone else wants to work on it before that time (but
in my current Guix installations the desktop manager, whichever this
is, works properly).  In any case, I can make time for testing Guix
code if that is useful at all.

> Fwiw, I looked at the work OpenBSD does with their X11 patching (for more 
> time than I am willing to admit),
> and it's not worth to extract and re-apply the meaningful patches
> for one single project. I don't get why parabola is re-purposing this X11 
> work,
> but OpenBSD work is usually written for OpenBSD with an underlying OpenBSD
> system in mind. That's not to say their X11 is "useless", it's just useful
> in OpenBSD.

Point taken.  Seems reasonable.

—Marco

Re: upgrading systems with <= 2 GiB RAM

[Marco van Hulten]

Marius—

Je 31 okt 23:49 skribis Marius:
> Marco van Hulten  writes:
> 
> > I have an oldish amd64 system with 2 GiB of memory, but it is fast
> > enough to use as a media center.  Guix was last updated early this
> > year.  Upgrading it now takes many days.  It keeps on swapping (using
> > quite consistently 2 of 4 GiB of swap available).
> >
> > Do you think the swapping is the reason that it takes so long?
> >
> > Would it be a general strong advice to use more than 2 GiB, or is it
> > likely useful to give details like which program is compiling (as in a
> > proper bug report)?  
> 
> Ideally you should not have to compile anything.  Have you authorized
> the ci.guix.gnu.org signing key?

I did not authorize that signing key.  Now that I have, upgrading the
system and installing packages goes much faster.

Thanks for this!

—Marco

upgrading systems with <= 2 GiB RAM

[Marco van Hulten]

Hello—

I have an oldish amd64 system with 2 GiB of memory, but it is fast
enough to use as a media center.  Guix was last updated early this
year.  Upgrading it now takes many days.  It keeps on swapping (using
quite consistently 2 of 4 GiB of swap available).

Do you think the swapping is the reason that it takes so long?

Would it be a general strong advice to use more than 2 GiB, or is it
likely useful to give details like which program is compiling (as in a
proper bug report)?

—Marco

xdm

[Marco van Hulten]

Hi—

I see quite some issues passing by of login managers.  Would it be a
good idea to provide XDM?  I have been using it a lot (especially in
the form of xenodm under OpenBSD) together with .xinitrc and I cannot
remember ever having any issue with it.

It would probably be easy to make it a standard option.  Maybe port
xenodm back if there are interesting bug fixes or features in there
that are not in xdm.

I wish I had more time to do better research or write some code for
Guix, but I've not right now.

—Marco

Re: TeX Live and ConTeXt

[Marco van Hulten]

Ricardo—

Je  3 aug 20:15 skribis Ricardo:
> > I installed texlive-context-base.  Now I want to compile a document,
> > but there is an issue:  
> 
> the TeX Live packages in Guix are getting an overhaul on the
> “wip-texlive” branch.  We are still waiting for all affected packages to
> be built.
> 
> With some luck these changes will help you.

Yes, and in case the issue persists after the overhaul I'll pick up the
problem then.  For now I'll use TeX and friends on my non-Guix systems.

Thanks for this status update.  I'm looking forward to see how the
beast TeX Live is handled in Guix after the overhaul.

—Marco

TeX Live and ConTeXt

[Marco van Hulten]

Hello Guix'ers—

I installed texlive-context-base.  Now I want to compile a document,
but there is an issue:


$ cat test.tex 
\starttext
\startsection[title={Testing ConTeXt}]
  This is my {\em first} ConTeXt document.
\stopsection
\stoptext
$ context test.tex 
mtxrun  | forcing cache reload
resolvers   | resolving | configuration files already identified
resolvers   | resolving | loading configuration file 
'/gnu/store/mhxxwwph6y13aa1mqmczqcbkkndkvzaq-texlive-texmf-20180414/share/texmf-dist/web2c/texmfcnf.lua'
resolvers   | resolving |
resolvers   | resolving | locating list of 
'/gnu/store/hf3jvp06bqdhp5ckb3vf8c68p0ks7qgs-texlive-texmf-2017/share/texmf-var'
 (runtime) 
(tree:gnu/store/hf3jvp06bqdhp5ckb3vf8c68p0ks7qgs-texlive-texmf-2017/share/texmf-var)
resolvers   | methods | resolving, method 'locators', how 'uri', handler 
'tree', argument 
'tree:gnu/store/hf3jvp06bqdhp5ckb3vf8c68p0ks7qgs-texlive-texmf-2017/share/texmf-var'
resolvers   | trees | locator 
'/gnu/store/hf3jvp06bqdhp5ckb3vf8c68p0ks7qgs-texlive-texmf-2017/share/texmf-var'
 not found
resolvers   | resolving |
resolvers   | resolving |
mtxrun  | the resolver databases are not present or outdated
resolvers   | resolving | using suffix based filetype 'lua'
resolvers   | resolving | remembering file 'mtx-context.lua' using hash 
'lua::mtx-context.lua'
resolvers   | resolving | using suffix based filetype 'lua'
resolvers   | resolving | remembering file 'mtx-contexts.lua' using hash 
'lua::mtx-contexts.lua'
resolvers   | resolving | remembered file 'mtx-context.lua'
resolvers   | resolving | using suffix based filetype 'lua'
resolvers   | resolving | remembering file 'mtx-t-context.lua' using hash 
'lua::mtx-t-context.lua'
resolvers   | resolving | using suffix based filetype 'lua'
resolvers   | resolving | remembering file 'mtx-t-contexts.lua' using hash 
'lua::mtx-t-contexts.lua'
resolvers   | resolving | remembered file 'mtx-t-context.lua'
resolvers   | resolving | using suffix based filetype 'lua'
resolvers   | resolving | remembering file 'context.lua' using hash 
'lua::context.lua'
mtxrun  | unknown script 'context.lua' or 'mtx-context.lua'


quiliro has reproduced the issue (see recent #guix IRC log).
Does someone have an idea what is wrong or what I should do?

—Marco

libX11.so.6: cannot open shared object file

[Marco van Hulten]

Hello Guixians,

Many months ago I have installed Guix on Ubuntu 18.04, and it's mostly
working well.

I am now getting

/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash:
error while loading shared libraries: libX11.so.6: cannot open shared 
object file: No such file or directory

in my ~/.xsession-errors when I run atril via dmenu(1) from spectrwm(1)
on Ubuntu 18.04, but

$ which atril
/usr/bin/atril
$ which bash
/bin/bash
$ ldd /bin/bash
linux-vdso.so.1 (0x7ffc0c3b2000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f0518e99000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0518c95000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f05188a4000)
/lib64/ld-linux-x86-64.so.2 (0x7f05193dd000)

Here, I am showing all environment variables containing the string
"guix" known to dmenu:

CPATH=/Home/siv29/mhu027/.guix-profile/include
GIO_EXTRA_MODULES=/Home/siv29/mhu027/.guix-profile/lib/gio/modules
GUIX_PROFILE=/Home/siv29/mhu027/.guix-profile
LIBRARY_PATH=/Home/siv29/mhu027/.guix-profile/lib

PATH=/Home/siv29/mhu027/.guix-profile/bin:/Home/siv29/mhu027/.guix-profile/sbin:/Home/siv29/mhu027/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
SSL_CERT_DIR=/Home/siv29/mhu027/.guix-profile/etc/ssl/certs
TERMINFO_DIRS=/Home/siv29/mhu027/.guix-profile/share/terminfo
XDG_DATA_DIRS=/Home/siv29/mhu027/.guix-profile/share

What goes wrong?


(Apropos -- but I should make a separate, more complete, report of this
--, has anyone tried to use spectrwm on a native Guix System?  As soon
as I login, having `spectrwm' in my .xinitrc, the screen starts
flickering quickly between black and a login prompt from a vc.  Other
window managers, e.g. i3wm, start normally.  Has someone experienced a
similar behaviour?)

—Marco

system services (networking and xorg-server) don't start at boot

[Marco van Hulten]

Hello Guix—

I upgraded to the latest guix with

 # guix pull
 # guix system reconfigure config.scm
 # guix --version
   guix (GNU Guix) d13f3a033e42b4a14d581390b8fa36cd1db7d023

But now the system doesn't start up completely.  For things to work, I
needed to start some services, namely:

 # herd start networking
 # herd start xorg-server

dmesg just before these commands: https://paste.debian.net/1083361/
config: https://paste.debian.net/1083362/

Any pointers are appreciated.

—Marco

Re: Claws Mail LDAP support

[Marco van Hulten]

Ricardo—

On 22 Mar 10:27 Ricardo Wurmus wrote:
> > And you know what, adding "--enable-ldap" to the #:configure-flags
> > works as well!  In the address book, there is a new menu entry New LDAP
> > Server.  
> 
> Nice!
> 
> > Should this be added to the standard claws-mail entry?  Or
> > should there be an -ldap flavour, akin to OpenBSD's pkg_* where the
> > user is prompted to install the standard or -ldap or -minimal or
> > whichever flavour?  Or should this be left as an exercise to the user?  
> 
> Could you please submit a patch that changes the existing “claws-mail”
> package?  I don’t see a reason to build two variants of Claws.

I've sent a patch to guix-devel@.  I found out about 'git
format-patch'.  I hope that's the way to go.

—Marco

Re: Claws Mail LDAP support

[Marco van Hulten]

Ricardo—

On 21 Mar 22:14 Ricardo Wurmus wrote:
> > Yes, I added it and then ran
> >
> > guix package --install-from-file=claws-mail.scm
> >
> > But that does not do anything.  
> 
> That’s because the file does not evaluate to a package.  It only causes
> the definition of a variable, but does not return any value.
> 
> Add “claws-mail” to the bottom after the package definition to see the
> difference.

Thanks, it builds.

It makes sense now.  In Scheme the (define ...) and similar just define
stuff; called a "special form" as opposed to normal expressions like (+
1 2).  (I started reading SICP.)  And in "claws-mail" the
#:configure-flags evaluates just that, as defined earlier on with a
(define-public claws-mail ...).

And you know what, adding "--enable-ldap" to the #:configure-flags
works as well!  In the address book, there is a new menu entry New LDAP
Server.  Should this be added to the standard claws-mail entry?  Or
should there be an -ldap flavour, akin to OpenBSD's pkg_* where the
user is prompted to install the standard or -ldap or -minimal or
whichever flavour?  Or should this be left as an exercise to the user?

—Marco

Re: Claws Mail LDAP support

[Marco van Hulten]

Giovanni et al.—

On 21 Mar 15:10 Giovanni Biscuolo wrote:
> the Claws INSTALL file [1] states:
> 
> --8<---cut here---start->8---
> Options for configure script
> 
> For list of available options, refer to "./configure --help".
> 
> Most options are automatically enabled if the dependencies
> are matched.
> --8<---cut here---end--->8---
> 
> maybe "most" means "--enable-ldap" should be added to #:configure-flags
> 
> can you try this, Marco?

Yes, I added it and then ran

guix package --install-from-file=claws-mail.scm

But that does not do anything.

Should I not expect Guix to rebuild the package when the
#:configure-flags is changed compared to the already installed package?

Here is the full content of claws-mail.scm:

http://paste.debian.net/1074097/

—Marco

Claws Mail LDAP support

[Marco van Hulten]

Hello—

I would like to have LDAP support in Claws Mail.  Right now I am
missing the LDAP menu entry under the Book menu in the Address Book.
Though I'm short on time right now, I found copying e-mail addresses
from old e-mail becoming a bit too anoying, so I did a throw at
modifying the package to enable LDAP.

I just added (inputs ("openldap" ,openldap)).  No idea if that should
work.  I put this in a file claws-mail.scm, together with a
(use-modules ...).  I entered this command:

guix package --install-from-file=claws-mail.scm

That doesn't do anything.  Does (inputs ...) only specify dependencies,
and actually doesn't change Guix' state (when openldap is already
installed)?

Long story short: can LDAP be enabled in Claws Mail?

—Marco

Re: set dnsdomainname

[Marco van Hulten]

Je  6 mrt 10:21 skribis Tobias:
> Giovanni Biscuolo wrote:
> > I'd prefer setting the contents "inline" declaring each hosts
> > record... but I don't know how to do it  
> 
> Probably easier than you thought!
> 
>   (host-name "lapdog.tobias.gr")
>   ;; This creates a file /gnu/store/…-hosts and links it as 
>   /etc/hosts.
>   (hosts-file (plain-file "hosts "\
> 127.0.0.1 lapdog.tobias.gr localhost
> ::1   lapdog.tobias.gr localhost
> "))
> 
> Doing it in Scheme also allows one to factor out some of that ugly 
> repetition, if I'd bother.

Great, this works fine!  Thanks, Giovanni and Tobias!

—Marco

Re: set dnsdomainname

[Marco van Hulten]

Je  5 mrt 11:30 skribis Marco:
> Hello Guix—
> 
> I want `dnsdomainname` to be set on my system with GuixSD (because it
> is used as a destination in my Postfix configuration).  How do I go
> about this?
> 
> The system with GuixSD gets network information from my Debian 8 server
> that runs the ISC DHCP server.  So I thought the best approach would be
> to configure the DHCP server by adding this near the top of dhcpd.conf:
> 
> ddns-updates on;
> ddns-domainname "instanton";
> 
> But it doesn't get picked up by the GuixSD client system.
> 
> Is there a way to specify full hostname(1) information (`hostname
> --fqdn`, `dnsdomainname`) in Guix' system configuration?

I found that one can edit /etc/hosts , starting with something like:

127.0.0.1  localhost
127.0.1.1  myhost.mydomain  myhost

but of course this is overwritten by the Guix system (at reboot).

—Marco

set dnsdomainname

[Marco van Hulten]

Hello Guix—

I want `dnsdomainname` to be set on my system with GuixSD (because it
is used as a destination in my Postfix configuration).  How do I go
about this?

The system with GuixSD gets network information from my Debian 8 server
that runs the ISC DHCP server.  So I thought the best approach would be
to configure the DHCP server by adding this near the top of dhcpd.conf:

ddns-updates on;
ddns-domainname "instanton";

But it doesn't get picked up by the GuixSD client system.

Is there a way to specify full hostname(1) information (`hostname
--fqdn`, `dnsdomainname`) in Guix' system configuration?

—Marco

Re: libX11 not found after binary install of Guix

[Marco van Hulten]

Hi Ricado—

On 22 Feb 19:31 Ricardo Wurmus wrote:
> Marco van Hulten  writes:
> > On a freshly installed Ubuntu 18.04 I installed Guix following the
> > instructions on, except for the fact that I did it from grml in a
> > chroot(8)ed environment
> >
> > 
> > https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html
> >
> > Rebooting into Ubuntu I was happy to find that guix-daemon was running.
> > Then I tried install something:
> >
> > $ guix package -i hello
> > /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: 
> > error while loading shared libraries: libX11.so.6: cannot open shared 
> > object file: No such file or directory  
> 
> Bash shouldn’t want to load libX11.so.6.  I wonder what prints this
> line.  Is your bashrc telling the shell to load extra libraries?  Could
> you share the output of “env” perhaps?

It is attached.

When I removed the LD_PRELOAD variable, the problem disappeared.  It
appears that spectrwm(1) sets LD_PRELOAD.  It looks like that spectrwm
keeps on working fine when I override it in my .bashrc.

> > At least on the host system it exists:
> >
> > $ ls -l $(locate libX11.so.6)
> > lrwxrwxrwx 1 root root  15 Aug 29 20:18 
> > /usr/lib/x86_64-linux-gnu/libX11.so.6 -> libX11.so.6.3.0
> > -rw-r--r-- 1 root root 1277384 Aug 29 20:18 
> > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
> > $ file /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
> > /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: ELF 64-bit LSB shared object, 
> > x86-64, version 1 (SYSV), dynamically linked, 
> > BuildID[sha1]=46d02d32191b5470a70bf6710997bf89b8b8ae38, stripped  
> 
> This shouldn’t matter.  Guix will not use things that are on your system
> unless you force it (e.g. via LD_LIBRARY_PATH).

This variable was not set.

Thanks for your help!

—Marco
LC_ALL=en_US.utf8
LANG=en_GB.utf8
HISTCONTROL=
LESS=-R
DISPLAY=:0
_SWM_PID=8118
FER_DSETS=/scratch/fer_dsets
EDITOR=vi
PLOTFONTS=/Home/siv29/mhu027/installed/ferret/ppl/fonts
XDG_VTNR=7
SSH_AUTH_SOCK=/tmp/ssh-2g3D9r9pYHlp/agent.2878
XDG_SESSION_ID=1
XTERM_SHELL=/bin/bash
USER=mhu027
PAGER=less
GUIX_LOCPATH=/Home/siv29/mhu027/.guix-profile/lib/locale
FER_GRIDS=/scratch/fer_dsets/grids
FER_DATA=. /Home/siv29/mhu027/ferret/complot/data /scratch/fer_dsets/data
PWD=/Home/siv29/mhu027/system/Guix
HOME=/Home/siv29/mhu027
SSH_AGENT_PID=2925
_SWM_WS=2
QT_ACCESSIBILITY=1
KRB5CCNAME=FILE:/tmp/krb5cc_96252_Bna6EJ
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
FER_FONTS=/Home/siv29/mhu027/installed/ferret/ppl/fonts
FER_DESCR=/scratch/fer_dsets/descr
TMPDIR=/tmp
SWM_STARTED=YES
XTERM_VERSION=XTerm(330)
SAL_USE_VCLPLUGIN=gtk
GTK_MODULES=gail:atk-bridge
WINDOWPATH=7
TERM=xterm
SHELL=/bin/bash
GPG_AGENT_INFO=/run/user/96252/gnupg/S.gpg-agent:0:1
XDG_SEAT=seat0
SHLVL=2
LANGUAGE=en_US.UTF-8
MANPATH=:/opt/puppetlabs/puppet/share/man
WINDOWID=35651599
FER_DIR=/Home/siv29/mhu027/installed/ferret
XDG_CACHE_HOME=/var/cache/users/mhu027/.cache
LOGNAME=mhu027
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/96252/bus
XDG_RUNTIME_DIR=/run/user/96252
FER_GO=/Home/siv29/mhu027/ferret/complot/scripts 
/Home/siv29/mhu027/installed/ferret/go /Home/siv29/mhu027/ferret/scripts_UiB
PATH=/home/mhu027/.guix-profile/bin:/home/mhu027/.config/guix/current/bin:/Home/siv29/mhu027/bin:/Home/siv29/mhu027/installed/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/puppetlabs/bin
LD_PRELOAD=/usr/lib/spectrwm/libswmhack.so.0.0
FER_PALETTE=/Home/siv29/mhu027/ferret/complot/palettes 
/Home/siv29/mhu027/ferret/palettes /Home/siv29/mhu027/installed/ferret/ppl
XTERM_LOCALE=en_DK.UTF-8
GTK_IM_MODULE=xim
_=/usr/bin/env
OLDPWD=/Home/siv29/mhu027/system

libX11 not found after binary install of Guix

[Marco van Hulten]

Hi all—

On a freshly installed Ubuntu 18.04 I installed Guix following the
instructions on, except for the fact that I did it from grml in a
chroot(8)ed environment


https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html

Rebooting into Ubuntu I was happy to find that guix-daemon was running.
Then I tried install something:

$ guix package -i hello
/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: error 
while loading shared libraries: libX11.so.6: cannot open shared object file: No 
such file or directory

At least on the host system it exists:

$ ls -l $(locate libX11.so.6)
lrwxrwxrwx 1 root root  15 Aug 29 20:18 
/usr/lib/x86_64-linux-gnu/libX11.so.6 -> libX11.so.6.3.0
-rw-r--r-- 1 root root 1277384 Aug 29 20:18 
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
$ file /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=46d02d32191b5470a70bf6710997bf89b8b8ae38, stripped

but it is not in the Store:

$ ls -d /gnu/store/*libx11*
ls: cannot access '/gnu/store/*libx11*': No such file or directory

Should it be there?

What could've gone wrong?

—Marco

removal of induces installation of other package

[Marco van Hulten]

Hi—

I removed a package, but this resulted in other packages being built:


$ guix package -r evince
The following package will be removed:
   evince   3.28.2  
/gnu/store/0453w20ldm1pxhbbginwi35ri2w2b7vi-evince-3.28.2

Building /gnu/store/2gf7ndczpg99kbcy5vap5q1lpg1wf8hm-texinfo-6.5.tar.xz.drv - 
x86_64-linux 
/var/log/guix/drvs/2g//f7ndczpg99kbcy5vap5q1lpg1wf8hm-texinfo-6.5.tar.xz.drv.bz2
Built /gnu/store/2gf7ndczpg99kbcy5vap5q1lpg1wf8hm-texinfo-6.5.tar.xz.drv
Building /gnu/store/qqir6r1rnd3ljg1cd583v34klqjqpljb-texinfo-6.5.drv - 
x86_64-linux 
/var/log/guix/drvs/qq//ir6r1rnd3ljg1cd583v34klqjqpljb-texinfo-6.5.drv.bz2
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
[...]


It takes a long time.  Why does this happen?

One thing I can imagine is that some installed package depends on either
evince or texinfo.

—Marco

many similar builds

[Marco van Hulten]

$ md5sum /gnu/store/*-xeyes-*/bin/xeyes
e17c8aab7cdeedb763601288b6eb0c43  
/gnu/store/3syyc8yvyymnwsada0kgm1jmc83232c8-xeyes-1.1.2/bin/xeyes
f44bf885477a110f7d0ee7b3524b978a  
/gnu/store/j0ycra947a0y3d3c9afms7sjlykis629-xeyes-1.1.2/bin/xeyes
$ ls -l /gnu/store/*-atril-*/bin/atril
-r-xr-xr-x 2 root root 1226 Jan  1
1970 /gnu/store/01j2hg31cv41a0fb19h1wvmn7dzxlv8s-atril-1.18.1/bin/atril
-r-xr-xr-x 2 root root 1226 Jan  1
1970 /gnu/store/1qsm3qmiqc84p8yakbxvyccjbg64ak7z-atril-1.18.1/bin/atril
-r-xr-xr-x 2 root root 1226 Jan  1
1970 /gnu/store/30syxb0vqbcc0zap47mhxlswmhq0w2vw-atril-1.18.1/bin/atril
-r-xr-xr-x 2 root root 1226 Jan  1
1970 /gnu/store/3b95dhdrkyhbw3bijzy9phd34bq32nnq-atril-1.18.1/bin/atril
...

and many more, and 14 different «same-version» installations for
brasero.  Does this mean that it is just very difficult to get
reproducible builds?

—Marco

-- 
☎   +31 30 711 0341 (VoIP)
   hul...@jabber.fsfe.org (using OMEMO encryption)
   http://marcovan.hulten.org/

Freedom to read — https://www.nature.com/articles/d41586-018-06178-7
Finally, punishment of researchers not open accessing is long overdue!

Re: how does mounting work?

[Marco van Hulten]

Hello Ludo'—

Je 25 aug 00:23 skribis Ludovic:
> Marco van Hulten  skribis:
> 
> > I tried 'gvfs-mount', but now I'm quite sure it isn't that:
> >
> >
> > $ gvfs-mount --list
> > This tool has been deprecated, use 'gio mount' instead.
> > See 'gio help mount' for more info.
> >
> > /home/marco/.guix-profile/bin/gvfs-mount: line 13: exec: gio: not found
> >
> >
> > But this does look like something that wants fixing.  Maybe gvfs-mount
> > is a wrong or an unnecessary dependency of some other package.  
> 
> I just checked and glib:bin provides that ‘gio’ command.  I guess we
> should fix ‘gvfs-mount’ to refer to ‘gio’ by its absolute file name.

Yes, that's useful.  No high priority (at least concerning me).

> In the meantime, you can run:
> 
>   guix environment --ad-hoc glib:bin -- gio mount

Thank you, this works.

—Marco

how does mounting work?

[Marco van Hulten]

Hi—

When I insert a USB stick, an icon representing a partition shows up on
the desktop.  When I double-click it, it gets mounted under some
directory under /media/$(whoami)/.  What command is actually executed?


I tried 'gvfs-mount', but now I'm quite sure it isn't that:


$ gvfs-mount --list
This tool has been deprecated, use 'gio mount' instead.
See 'gio help mount' for more info.

/home/marco/.guix-profile/bin/gvfs-mount: line 13: exec: gio: not found


But this does look like something that wants fixing.  Maybe gvfs-mount
is a wrong or an unnecessary dependency of some other package.

It's a couple of weeks ago before I updated GuixSD.

—Marco

Re: racket patch not found

[Marco van Hulten]

Hi Mark, others—

Je 14 jul 16:38 skribis Mark:
> Marco van Hulten  writes:
> 
> > When I install the package `racket' through
> >
> > guix pull &&\
> > guix package -i racket
> >
> > I get this error:
> >
> > guix package: error: racket-fix-xform-issue.patch: patch not found  
> 
> This was fixed in commit 57ac5261fec345b16cf80f87aa03212abc2c5a11,
> pushed a few days ago.
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57ac5261fec345b16cf80f87aa03212abc2c5a11
> 
> If you "guix pull" and try again, hopefully it will work now.

Yes, it does!

It did warn me about no readline support:

$ racket
Welcome to Racket v6.12.
; Warning: no readline support (ffi-lib: couldn't open "libedit.so.3" 
(libedit.so.3: cannot open shared object file: No such file or directory))
> 

So I installed libedit, but the warning stays and I have still no
readline support.

Maybe I have to do add it to my LD_LIBRARY_PATH or something.  Instead,
I went looking for libedit.so.3, but it wasn't in ~/.guix-profile/lib/.
When I started racket from that working directory, the warning wasn't
given and I had readline support.  According to my experience binaries
indeed look in the working directory for libraries.  Apparently racket
finds the useful library in ~/.guix-profile/lib/.  But what file is it,
and why does it not need to be "libedit.so.3"?

—Marco

racket patch not found

[Marco van Hulten]

Hi—

When I install the package `racket' through

guix pull &&\
guix package -i racket

I get this error:

guix package: error: racket-fix-xform-issue.patch: patch not found

Cheers,

—Marco

ELF executable exists but is not found

[Marco van Hulten]

Hi—

I would like to run a piece of proprietary software on GuixSD.  Would
the general, relatively secure, approach be to use "guix environment"
and make available with "--expose" what the program needs?

The program is the photo ordering software by CEWE Stiftung & Co. KGaA,
which is used by several large photo service companies in Europe.

There is a «Linux» (sic) version available (for instance, this Dutch
version):

https://www.cewe.nl/bestelsoftware/bedankt-voor-de-download.html?version=linux

After changing the perl path of the installation script, I come across
the issue that I cannot execute the binary:

$ file CEWE\ Fotoservice 
CEWE Fotoservice: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
2.6.24, BuildID[sha1]=445a455753ee3c12b60edbaa40209200e8d3a18d, not stripped
$ ./CEWE\ Fotoservice 
bash: ./CEWE Fotoservice: No such file or directory

What do you make of this?

I am sure that I will come across many more issues, like it expecting
software in LSB-compliant locations.  Any general pointers there are
also appreciated.

—Marco

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

[Marco van Hulten]

Ludovic—

Je  2 mrt 17:02 skribis Ludovic:
> What about allowing posts on help-guix in one of the languages that
> regular contributors know, in addition to English?
> [...]

I like the idea.

> To experiment with this on help-guix, I propose the patch below for the
> web site.  If you’re a committer, please provide a translation for the
> language(s) you know!

 ("nl"
  "Abonneer je op de discussielijst \"Help\" om hulp te vragen
van de GuixSD- en GNU Guix-gemeenschap.  Je kunt berichten sturen in
het Nederlands.")
 ("nb"
  "Abonner på diskusjonlisten «Help» for å få hjelp om GuixSD og
GNU Guix via e-post.  Du kan legge inn meldinger på norsk.")

—Marco

julia compilation

[Marco van Hulten]

Hello—

When I am installing `julia', the compilation does not finish.  It hangs
for more than 10 hours at


guix package -i julia
...
iostream (2)  |0.98  |  0.00  |  0.0 |  2.66  | 1452.52 

│
WARNING: Method definition f(Tuple{Vararg{Int64, N}}, AbstractArray{T, N}) in 
module Test51Main_specificity at 
/tmp/guix-build-julia-0.6.0.drv-0/julia-0.6.0/test/specificity.jl│
:87 overwritten at 
/tmp/guix-build-julia-0.6.0.drv-0/julia-0.6.0/test/specificity.jl:93.   
 │
specificity (2)   |0.34  |  0.00  |  0.0 |  1.10  | 1452.52 

│
fft (2)   |   46.25  |  1.39  |  3.0 | 533.68 | 1452.52 

│
dsp (2)   |   15.63  |  0.66  |  4.2 | 247.45 | 1452.52 

│
examples (2)  |   82.05  |  1.34  |  1.6 | 617.55 | 1452.52 




There is swapping going on; my system only has 2 GiB of RAM.  But CPU
utilisation is close to zero.

The version of Julia is 0.6.0; but the current stable release is
0.6.2.  If someone has time, it would be good to increase the version.
The testing version 0.7.x would be fine as well, as many people seem to
use it already.

—Marco

mounting NTFS read-write

[Marco van Hulten]

Hello—

I have this in my Guix configuration:

(file-system
  (device "my-scratch")
  (title 'label)
  (mount-point "/scratch")
  (type "ntfs")
  (flags '(read-write user)))

There are two problems with it.

1. The file system with label 'my-scratch' is not found.  Of course, I
can use (device "/dev/sda6") instead.  But why can it not use the
label?  It does turn up in cfdisk(8), just like for the root file
system /dev/sda1.

2. The flags are ignored.  At least the first one, read-write, is
likely ignored because Linux does not support write access to NTFS
file systems.  Then I looked in the manual [1], and found out that the
flags read-write and user do not exist.  The former is maybe redundant
because it is default (in case there is support for writable mount of
the respective filesystem!), but the second could be useful, at least
for removable media (though for that might exist other solutions).

[1]: https://www.gnu.org/software/guix/manual/html_node/File-Systems.html

Instead, NTFS file systems can be mounted with write access through
fuse, using ntfs-3g.  So I installed ntfs-3g, and added a cron job to
my /etc/config.scm; excerpt here:


(use-modules (gnu services mcron))
...
(define mount-ntfs-job
  #~(job "@reboot"
 "/root/.guix-profile/sbin/mount.ntfs-3g -o
 rw /dev/sda6 /scratch"))
(operating-system
  ...
  (services (cons* (mcron-service (list mount-ntfs-job


This does not work.  And I think it is ugly in that I do not provide
the ntfs-3g package in config.scm, and that I am solving this at all
through a root cronjob @reboot.  But I'm not versed well enough in Guix
yet to know how to do it properly!


Finally, why the heck do I have an NTFS partition on my drive?  Well, I
am dual booting between OpenBSD and GuixSD, and want to share one
partition.  OpenBSD does not support so many filesystems, but it does
provide the ntfs-3g package, and my guess is that NTFS is quite robust,
especially considering I'm using it exclusively with the ntfs-3g
package (making it effectively an open spec.).

I am open for all kind of alternatives.

—Marco

P.S. I had to type over all code because I am not able to copy things
from the terminal with select then middle-click.  Is this a GuixSD bug?

common software

[Marco van Hulten]

Hello—

Is there a meta-package providing for many common utilities like
'file', 'wget', ...?

Even though there is some subjectivity in what is essential software, a
clean installation of GuixSD is very minimal.  Is there a reason for
this?

—Marco

Re: libvdpau: cannot open shared object

[Marco van Hulten]

Ludovic—

Je 15 dec 15:31 skribis Ludovic:
> Efraim Flashner  skribis:
> 
> > $ VDPAU_DRIVER=va_gl LD_LIBRARY_PATH=$(guix build libvdpau-va-gl)/lib 
> > vdpauinfo
> > display: :0.0   screen: 0
> > Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object 
> > file: No such file or directory
> > Error creating VDPAU device: 1  
> 
> Well the exact line is this:
> 
>   VDPAU_DRIVER=va_gl \
>   LD_LIBRARY_PATH=$(./pre-inst-env guix build libvdpau-va-gl)/lib/vdpau \
>   $(guix build vdpauinfo)/bin/vdpauinfo
> 
> Works for me!  It displays lots of things.  :-)
> [...]

It does not work for me, still cannot find 'libvdpau_va_gl.so'.
I am trying to understand the commands that you use to define
LD_LIBRARY_PATH:

kodi@watson ~$ guix build libvdpau-va-gl
guix build: error: libvdpau-va-gl: unknown package
kodi@watson ~$ guix build vdpauinfo
/gnu/store/46x8ba3q11zgq8qygqpgkv41ws9km9b1-vdpauinfo-1.0

Where can I find 'pre-inst-env'?  Does this make guix aware of the
libvdpau-va-gl package?

I'm running GuixSD 0.14.0 on real hardware, and did a pull and upgrade
just yesterday.

—Marco

Re: problem with Icecat in GuixSD 0.14.0

[Marco van Hulten]

Stefan—

Je 13 dec 06:24 skribis Stefan:
> I had the same "Content Encoding" error and I solved it by following 
> these instructions:
> 
> 1. Open IceCat browser and at the address bar write: about:config
> 2. Click on "I accept the risk!" button
> 3. At the Search bar write and search for the string: encoding
> 4. Double click on "network.http.accept-encoding"
> 5. Change 'String Value' from "gzip, deflate" to: true
> 6. Close the browser and see the result.

Thanks, this does away with the "Content Encoding" problem.

Navigation on https://tv.nrk.no/ now works properly, but when I try to
play a video, I get the message:
> Kunne ikke spille av fordi JavaScript ikke ble funnet!
> 
> Aktiver JavaScript i innstillingene til din nettleser.

It says that it cannot play because JavaScript is not found, and that I
need to enable it in the settings of my webbrowser.  But it should
already be: when I click on the LibreJS button, it gives me the option
to re-"Block all nonfree/nontrivial scripts from this page".

Of course, this may quite likely be an upstream problem.

—Marco

problem with Icecat in GuixSD 0.14.0

[Marco van Hulten]

Je 10 dec 16:18 skribis Marco:
> I do have an issue
> with the Javascript blocker [in GNU Icecat].  If I disable it for tv.nrk.no,
> the website still complains that I block Javascript.

This may not be quite right, let me correct this:

I had this problem in GuixSD 0.13.0, and *possibly* still in 0.14.0.

But now on 0.14.0, I am having a problem with loading any page.  I get a

> Content Encoding Error

Screenshot attached.

—Marco

multiple issues with Epiphany in GuixSD 0.14.0

[Marco van Hulten]

Hi,

In the package epiphany, the icons don't display well, and connecting
to webpages doesn't work.

guix package -i epiphany
epiphany &

Screenshot attached.

GNU Icecat does not have these two problems, but I do have an issue
with the Javascript blocker.  If I disable it for tv.nrk.no,
the website still complains that I block Javascript.

—Marco

libvdpau: cannot open shared object

[Marco van Hulten]

Hi,

I am having a problem with kodi, which I installed on a clean
install of GuixSD 0.14.0 on amd64.  It was looking for libvdpau, so I
installed it.  Hereafter I get this:

kodi@watson ~$ vdpauinfo 
display: :0.0   screen: 0
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared
object Error creating VDPAU device: 1

Running `kodi` gives the same error.  The VDPAU problem seems like
something that I should solve first, before continuing with kodi.

Thanks,

—Marco

state of the system

[Marco van Hulten]

Hi,

Concerning my kodi crash happening on my system but not on other's [1],
maybe by system got broken and I should reinstall.

I understand that the state of a GuixSD installation is defined by one's
`config.scm`.  Thus I can very easily reproduce an exact copy of the
functional system.

However, there are also packages installed per user.  What would
define, excluding data files in the home directories, the complete
state of a system, including both the core OS and packages (as
available per user), if there such a thing in GuixSD?

http://lists.gnu.org/archive/html/help-guix/2017-11/msg00078.html

—Marco


pgpdNTxK99RdE.pgp
Description: OpenPGP digitale handtekening

Re: kodi crash, and gdb not found

[Marco van Hulten]

Marius—

Je 21 nov 23:59 transskribita far Marius Bakke:
> I wonder why this only started happening recently.  Can you post the
> output of `guix package -l` so we can see what changed between the
> working and non-working profile?

kodi@watson /var/guix/profiles/per-user/kodi$ guix package -l
Generation 1Nov 06 2017 12:45:39
  kodi  18.0_alpha-4-b8ad238out 
/gnu/store/0wf6as3bfichvc3sdlz0xh5kskdg6sbm-kodi-18.0_alpha-4-b8ad238

Generation 2Nov 06 2017 18:38:47
 + openssh  7.5p1   out 
/gnu/store/3gdq1cbfic3bgfcf6736bnpja0vxhh3w-openssh-7.5p1

Generation 3Nov 06 2017 21:14:27
 + epiphany 3.22.7  out 
/gnu/store/4dsj87avl81lld533a546abckg53z9yd-epiphany-3.22.7

Generation 4Nov 11 2017 23:23:17
 + file 5.30out /gnu/store/6133az05p1jivzv7m6hjdnqj512hyllp-file-5.30

Generation 5Nov 19 2017 18:19:59
 + youtube-dl   2017.11.15  out 
/gnu/store/gcj62qd2n2z3nd2ivqqaf1n721vsjl86-youtube-dl-2017.11.15

Generation 6Nov 19 2017 18:22:01
 + mpv  0.27.0  out /gnu/store/2lr2kq16r7z6y60ji9nlp5bakqr97ijp-mpv-0.27.0
 + mplayer  1.3.0   out 
/gnu/store/shbd9s0s7hi95i90mfn9q37l379jdl4n-mplayer-1.3.0

Generation 7Nov 21 2017 00:38:18
 + file 5.30out /gnu/store/sx2zmwldcw0yj67zxqjqb3ljfqhbxqz3-file-5.30
 + epiphany 3.24.4  out 
/gnu/store/x1q2gzq0wh0byf8qnf50j3lgka721fqn-epiphany-3.24.4
 + openssh  7.6p1   out 
/gnu/store/q1dsz7d1z6n590bypaaz2fzcwg7w14cw-openssh-7.6p1
 + kodi 18.0_alpha-7-67fd70fout 
/gnu/store/bg778i13jck782r2pbiang0jswbgnks3-kodi-18.0_alpha-7-67fd70f
 - file 5.30out /gnu/store/6133az05p1jivzv7m6hjdnqj512hyllp-file-5.30
 - epiphany 3.22.7  out 
/gnu/store/4dsj87avl81lld533a546abckg53z9yd-epiphany-3.22.7
 - openssh  7.5p1   out 
/gnu/store/3gdq1cbfic3bgfcf6736bnpja0vxhh3w-openssh-7.5p1
 - kodi 18.0_alpha-4-b8ad238out 
/gnu/store/0wf6as3bfichvc3sdlz0xh5kskdg6sbm-kodi-18.0_alpha-4-b8ad238

Generation 8Nov 21 2017 05:15:25
 + libvdpau 1.1.1   out 
/gnu/store/ansi9nv4qgyb59rhsxg63s8piflqrkgz-libvdpau-1.1.1

Generation 9Nov 21 2017 05:20:35
 + git  2.15.0  out /gnu/store/44ahv950sc9qj8b1k86y7rbx4y7z2h3y-git-2.15.0

Generation 10   Nov 22 2017 09:37:09
 - youtube-dl   2017.11.15  out 
/gnu/store/gcj62qd2n2z3nd2ivqqaf1n721vsjl86-youtube-dl-2017.11.15

Generation 11   Nov 18 2017 22:48:24
 + epiphany 3.24.4  out 
/gnu/store/8mf72ihvns7nw2mc7gxg7irqcfkm3rjd-epiphany-3.24.4
 + vim  8.0.1274out 
/gnu/store/gffay405f7bqpsxiivhl8b5ssgp7dy2i-vim-8.0.1274
 + gdb  8.0.1   out /gnu/store/c53i14s3qigk66pvgv3q2z48axmrivcn-gdb-8.0.1
 + icecat   52.3.0-gnu1 out 
/gnu/store/9r7j7iqkcxn8d2ixkk6jxmm2jdwz83i0-icecat-52.3.0-gnu1
 + openssh  7.6p1   out 
/gnu/store/j0lzcal5r3y4x4bhfq2ksfn2xirdhqhl-openssh-7.6p1
 + kodi 18.0_alpha-6-f22d62dout 
/gnu/store/0zv8v4zjy5r7hhrn2mmwb3qzqm1lmnb7-kodi-18.0_alpha-6-f22d62d
 + file 5.30out /gnu/store/6133az05p1jivzv7m6hjdnqj512hyllp-file-5.30
 - git  2.15.0  out /gnu/store/44ahv950sc9qj8b1k86y7rbx4y7z2h3y-git-2.15.0
 - libvdpau 1.1.1   out 
/gnu/store/ansi9nv4qgyb59rhsxg63s8piflqrkgz-libvdpau-1.1.1
 - file 5.30out /gnu/store/sx2zmwldcw0yj67zxqjqb3ljfqhbxqz3-file-5.30
 - epiphany 3.24.4  out 
/gnu/store/x1q2gzq0wh0byf8qnf50j3lgka721fqn-epiphany-3.24.4
 - openssh  7.6p1   out 
/gnu/store/q1dsz7d1z6n590bypaaz2fzcwg7w14cw-openssh-7.6p1
 - kodi 18.0_alpha-7-67fd70fout 
/gnu/store/bg778i13jck782r2pbiang0jswbgnks3-kodi-18.0_alpha-7-67fd70f
 - mpv  0.27.0  out /gnu/store/2lr2kq16r7z6y60ji9nlp5bakqr97ijp-mpv-0.27.0
 - mplayer  1.3.0   out 
/gnu/store/shbd9s0s7hi95i90mfn9q37l379jdl4n-mplayer-1.3.0

Generation 12   Nov 19 2017 04:28:28
 + epiphany 3.24.4  out 
/gnu/store/x1q2gzq0wh0byf8qnf50j3lgka721fqn-epiphany-3.24.4
 + vim  8.0.1300out 
/gnu/store/i3a3jcx5blsrb4mgh6x4509d5vw7swcv-vim-8.0.1300
 + gdb  8.0.1   out /gnu/store/mhs7yrbgnc3f85gxxvjvh93p5f3wi7bl-gdb-8.0.1
 + icecat   52.3.0-gnu1 out 
/gnu/store/67gkrr81f9nm3dj95dqcf8fvbpq9jxk5-icecat-52.3.0-gnu1
 + openssh  7.6p1   out 
/gnu/store/q1dsz7d1z6n590bypaaz2fzcwg7w14cw-openssh-7.6p1
 + kodi 18.0_alpha-6-f22d62dout 
/gnu/store/302x3yf8cdy6abggbf0nlzha0nn4fdbi-kodi-18.0_alpha-6-f22d62d
 + file 5.30out /gnu/store/sx2zmwldcw0yj67zxqjqb3ljfqhbxqz3-file-5.30
 - epiphany 3.24.4  out 
/gnu/store/8mf72ihvns7nw2mc7gxg7irqcfkm3rjd-epiphany-3.24.4
 - vim  8.0.1274out 
/gnu/store/gffay405f7bqpsxiivhl8b5ssgp7dy2i-vim-8.0.1274
 - gdb  8.0.1   out /gnu/store/c53i14s3qigk66pvgv3q2z48axmrivcn-gdb-8.0.1
 - icecat   52.3.0-gnu1 out 
/gnu/store/9r7j7iqkcxn8d2ixkk6jxmm2jdwz83i0-icecat-52.3.0-gnu1
 - openssh  7.6p1   out 
/gnu/store/j0lzcal5r3y4x4bhfq2ksfn2xirdhqhl-openssh-7.6p1
 - kodi 18.0_alpha-6-f22d62dout 
/gnu/store/0zv8v4zjy5r7hhrn2mmwb3qzqm1lmnb7-kodi-18.0_alpha-6-f22d62d
 - 

Re: kodi crash, and gdb not found

[Marco van Hulten]

Ludovic—

Je 21 nov 14:21 transskribita far Ludovic Courtès:
> Marco van Hulten <ma...@hulten.org> skribis:
> 
> > $ kodi
> > Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object 
> > file: No such file or directory  
> 
> Guix’s ‘mesa’ package does not provide this specific shared object under
> lib/vdpau, so there might be some interference with the host distro.
> 
> What happens if you run: [...]

kodi@watson ~$ guix environment --pure --ad-hoc kodi -- kodi
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/6gh05g6i9i5wwriwijmi1hcvlb2f52ff-profile.drv
   /gnu/store/hnd63cfgpf41y04jgrk56g2lb7y1nrby-xdg-desktop-database.drv
   /gnu/store/bq2m3cx2m93zc77b3zivlqkgdw9p9l36-xdg-mime-database.drv
   /gnu/store/6lvwvnnyfc3911hsjkrnd2bnh0a3m60n-fonts-dir.drv
   /gnu/store/6fn12y0ja1wgpw44r00aixd0jsx7mpnr-ca-certificate-bundle.drv
   /gnu/store/2642kkskcfhzwib8pxzzwhiiw94hwhd3-info-dir.drv
   /gnu/store/lrl1a0w7hf279ybm319rmyznvl2svpmw-manual-database.drv
Creating manual page database for 0 packages... done in 0.075 s
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 66: grep: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 88: 
basename: command not found
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: 
No such file or directory
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 208:   610 
Segmentation fault  ${KODI_BINARY} $SAVED_ARGS
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 117: date: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 122: date: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 125: uname: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 127: uname: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 171: cat: 
command not found
Crash report available at /home/kodi/kodi_crashlog-.log
kodi@watson ~$ guix environment -C --ad-hoc kodi -- kodi
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/yrql0mnyygf9pq11piznz4h0sdxg0zcy-bash-4.4.12.drv
grafting '/gnu/store/rm94cza4jv4iwykrfrbxgggfh19xzpai-bash-4.4.12-doc' -> 
'/gnu/store/1qwbn6c051xhss8pa09m2b0r8hfryl5d-bash-4.4.12-doc'...
grafting '/gnu/store/ngyidsfwhlk50rhr2kx3gqjxasmsab57-bash-4.4.12-include' -> 
'/gnu/store/8grbnl6vhr4qnw31730jm79h7j98ip33-bash-4.4.12-include'...
grafting '/gnu/store/b7y66db86k57vbb03nr4bfn9svmks4gf-bash-4.4.12' -> 
'/gnu/store/ars9lm9jk9hgdifg0gqvf1jrvz5mdg1j-bash-4.4.12'...
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 66: grep: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 88: 
basename: command not found
ERROR: Unable to create GUI. Exiting
*** Error in 
`/gnu/store/bg778i13jck782r2pbiang0jswbgnks3-kodi-18.0_alpha-7-67fd70f/lib64/kodi/kodi-x11':
 double free or corruption (out): 0x027cf180 ***
=== Backtrace: =
[...]
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 117: date: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 122: date: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 125: uname: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 127: uname: 
command not found
/gnu/store/w0b172fsjp2a786zjr69fm4zhjhs76hb-profile/bin/kodi: line 171: cat: 
command not found
Crash report available at /home/kodi/kodi_crashlog-.log


That looks bad.

Do let me know if you need the backtrace and/or memory map and/or the
crash log of the Kodi crash.

I am installed GuixSD 0.13.0, and upgraded it (pull & package -u).

—Marco

Re: kodi crash, and gdb not found

[Marco van Hulten]

Marius—

Je 20 nov 01:23 transskribita far Marius Bakke:
> I assume "18.0-ALPHA1" here is actually "18.0_alpha-6-f22d62d".
> 
> I have updated the snapshot in Guix to point to the latest upstream
> commit as of today, can you try updating to it and see if that works for
> you?  It starts here on an up-to-date profile, at least.

I did this, but it did not solve the issue:

$ kodi --version
18.0-ALPHA1 Git:20171120-nogitfound Media Center Kodi
Copyright (C) 2005-2013 Team Kodi - http://kodi.tv
$ kodi
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: 
No such file or directory
/home/kodi/.guix-profile/bin/kodi: line 208: 20108 Segmentation fault  
${KODI_BINARY} $SAVED_ARGS
Crash report available at /home/kodi/kodi_crashlog-20171121_051607.log

[1]: https://paste.debian.net/996798/

I installed libvdpau-1.1.1, but that did not resolve the problem either.

It seems that these things are not found in one way or another:

- gdb (see [1])
- git (`kodi --version`)
- vdpau (`kodi`)

Could there be a common cause?

—Marco


pgpsLuYu54v7S.pgp
Description: OpenPGP digitale handtekening

Re: kodi crash, and gdb not found

[Marco van Hulten]

Marius—

Je 19 nov 17:36 transskribita far Marius Bakke:
> Marco van Hulten <ma...@hulten.org> writes:
> > I have `kodi' and `gdb' installed.  When I start kodi, it crashes:
> >
> > https://paste.debian.net/996313/
> >
> > An excerpt of the `kodi' output:  
> >> gdb not installed, can't get stack trace.  
> >
> > but I installed gdb, under the same user:
> >
> > kodi@watson ~$ gdb --version | head -1
> > GNU gdb (GDB) 8.0.1
> >
> > Interesting, `man gdb` does not gives an empty or unreadable man page:
> > at the bottom of the terminal is:  
> >> Manual page gdb(1) line ?/? (END) (press h for help or q to quit)  
> >
> > I have never before tried (to let a program) use gdb on GuixSD.
> >
> > Last Sunday, the program `kodi' worked fine.  Shortly after that
> > (according to lastlog(8) the same day), I did a package upgrade, but
> > did not test kodi hereafter (according to `history`).  Today, I tested
> > kodi and it crashes.  I upgraded packages, but then it still crashes.  
> 
> Can you try rolling back to the generation that worked, to verify that
> it's not something in your environment that has changed?  Maybe also try
> to temporarily move away the ".kodi" folder in the users home directory.

Removing ~/.kodi/ did not solve the issue.

Rolling back sufficiently far did help.  My generations:

4 — kodi 18.0-ALPHA1 Git:20171106-nogitfound — works
5 — kodi 18.0-ALPHA1 Git:20171113-nogitfound — crashes

Fantastic feature this rolling back!

Sidenote: I see that the guix-profile symlink in
/var/guix/profiles/per-user/*/ is absolute; why no relative links?

> I'm currently testing the latest git snapshot of Kodi regardless, the
> alpha version in Guix is pretty old already.  Originally Kodi 18 was
> slated for July, but the release was pushed back to January[0], so the
> version in Guix is probably pretty buggy.

I installed GuixSD 0.13.0.  Hereafter, I have done a `guix pull` and
`guix package -u`, which resulted recently in

9 — kodi 18.0-ALPHA1 Git:20171113-nogitfound — crashes

That's six days ago; that's not that old, right?

—Marco


pgpSDV6WNm6i7.pgp
Description: OpenPGP digitale handtekening

kodi crash, and gdb not found

[Marco van Hulten]

Hi,

I have `kodi' and `gdb' installed.  When I start kodi, it crashes:

https://paste.debian.net/996313/

An excerpt of the `kodi' output:
> gdb not installed, can't get stack trace.

but I installed gdb, under the same user:

kodi@watson ~$ gdb --version | head -1
GNU gdb (GDB) 8.0.1

Interesting, `man gdb` does not gives an empty or unreadable man page:
at the bottom of the terminal is:
> Manual page gdb(1) line ?/? (END) (press h for help or q to quit)

I have never before tried (to let a program) use gdb on GuixSD.

Last Sunday, the program `kodi' worked fine.  Shortly after that
(according to lastlog(8) the same day), I did a package upgrade, but
did not test kodi hereafter (according to `history`).  Today, I tested
kodi and it crashes.  I upgraded packages, but then it still crashes.

—Marco

Re: openssh installed, but ssh-daemon not starting

[Marco van Hulten]

Ludo'-

Op 13 nov 10:52 schreef Ludovic Courtès:
> [...] the current convention is to set users
> write:
> 
>   (service TYPE CONFIG)
> 
> or
> 
>   (service TYPE)
> 
> ‘service’ is a record constructor: it produces a “service” object with
> the given type and config.
> 
> We’ve started removing the “old-style” service procedures, but we should
> keep doing that to avoid the confusion.

Thank you for clearing that up.

-Marco

Re: openssh installed, but ssh-daemon not starting

[Marco van Hulten]

David-

Op 10 nov 07:45 schreef Thompson, David:
> Marco wrote:
> > root@watson ~# herd start ssh-daemon
> > herd: service 'ssh-daemon' could not be found
> > ```
> >
> > Is there actually a service `ssh-daemon' belonging to the package
> > openssh?  
> 
> Services being installed upon package installation is one of those
> things you learn from other distros that needs to be "unlearned" when
> using GuixSD.  When you run `guix package` you are altering your own
> personal package profile, it doesn't alter the system in any way.
> Installing the openssh package as a user is a good way to get the
> openssh client available in your shell, but in order to get the
> openssh daemon running you'll need to add an expression like `(service
> openssh-service-type (openssh-configuration ...))` to your OS
> configuration file and run `guix system reconfigure`.  Make sure to
> import the (gnu services ssh) module otherwise you'll get undefined
> variable errors.

It now works with the (service openssh-service-type).  I did not change
the default configuration.  I feel a bit fuzzy about the exact keywords
used, sometimes services take only one keyword:

  (services (cons* (xfce-desktop-service)
   (service openssh-service-type)
   %desktop-services))

For XFCE we use a singlet, whereas for OpenSSH a pair is used.  Must
one use such a pair if there are (optionally) configuration parameters
to be defined for the respective service?

The syntax of the ssh module import at the top of my profile is a bit
different, but it seems to work (https://paste.debian.net/995301/).


I am starting to understand the generals of the system.

Thank you for the help!

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Leo-

Op 10 nov 11:35 schreef Leo Famulari:
> On Fri, Nov 10, 2017 at 08:26:12AM +0100, Marco van Hulten wrote:
> > kodi@watson ~$ time guix pull --cores=1  
> 
> [...]
> 
> > compiling... 75.4% of 647 filesbuilding of 
> > `/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out 
> > after 3600 seconds of silence  
> 
> [...]
> 
> > real609m30.245s
> > user0m3.125s
> > sys 0m0.875s  
> 
> This is terrible, but you can work around it by passing a large value to
> the --max-silent-time "common build option": [...]

Hmm, but the time-out is now after 1 hour of silence, and the whole
process takes over 10 hours before crashing.  This option may be useful
if I set a very short time, though it remains to be seen if this ends
guix quickly.  I will play around with it.

Right now a `guix pull' results in a `dispatch-exception' in procedure
`struct_vtable: Wrong type argument in position 1 (expecting struct):
#'.  It seems that GuixSD (or components) is strongly in
flux right now, so I will try again later and do a proper bug report if
problems persist.

> Out of curiosity, what kind of machine are you using? A full hour with
> no output at all indicates that something is happening very slowly! Is
> it swapping?

I'd like to test if it is swapping.  I have 2 GiB of RAM in a 2-core
machine (Intel Core 2 Duo).  I did notice that swap was not enabled yet
on my system, and that (during last `guix pull') around 95% of RAM was
used.

> > - it took over 10 h to give me back control, whereas this used to be
> >   a bit over 2 h in previous tries;  
> 
> Do you mean that the computer becomes unresponsive?

Yes.

> > What is Guix doing between 75.2 and 75.4 %?  
> 
> I don't know exactly, but during `guix pull` Guix is built from source
> with the Guile compiler.
> 
> There are some bugs in the current version of the Guile compiler that
> cause it to require way more memory than expected. This is terrible on
> memory-constrained systems because it forces the use of swap, which is
> typically super slow. Hopefully we can deploy a fix soon.

Is 2 GiB considered "memory-constrained"?

-Marco


pgpFloTblh8m7.pgp
Description: OpenPGP digitale handtekening

openssh installed, but ssh-daemon not starting

[Marco van Hulten]

```
root@watson ~# guix package -i openssh
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following package will be upgraded:
   openssh  7.6p1 → 7.6p1   
/gnu/store/j0lzcal5r3y4x4bhfq2ksfn2xirdhqhl-openssh-7.6p1

substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/hfqadrr4am10d6lwwcwgfk148yrgybr1-profile.drv
   /gnu/store/ypc6gq61shfmp1pcxzhig5ygzi4a6hs5-ca-certificate-bundle.drv
   /gnu/store/r7arxs6qlf8iix56r7yv6qiqnjzf8wmp-fonts-dir.drv
   /gnu/store/f5d0jq44ghb1kbpk0mrsp45xxla910bn-info-dir.drv
   /gnu/store/9naqz8l0z023linybdjy0as5ymf9x40w-manual-database.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
Creating manual page database for 3 packages... done in 0.227 s
4 packages in profile
root@watson ~# herd start ssh-daemon
herd: service 'ssh-daemon' could not be found
```

Is there actually a service `ssh-daemon' belonging to the package
openssh?

root@watson ~# herd status | grep -i ssh
root@watson ~# 

This shows that there is no service containing the string `ssh'
*defined* (i.e. available?), if I understand the manual correctly [1].

[1]: https://www.gnu.org/software/guix/manual/html_node/Services.html

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Op 09 nov 21:53 schreef Mathieu Othacehe:
> My bad, this has been fixed by Efraim in
> d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.
> 
> You may want to guix pull again !

This work again — thanks for the quick response.

However, now I get the freeze again at around 75 %:

```
kodi@watson ~$ time guix pull --cores=1

Starting download of /tmp/guix-file.MgDQxo
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   3.2MiB/s 00:04 | 13.8MiB transferred
unpacking '/gnu/store/r3740b6bil3vcign3wj2izw9hb3c4gpg-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
copying and compiling to 
'/gnu/store/b4rs2nl3q1hb3ckbgzg98s23q44bcys4-guix-latest' with Guile 2.2.2...
loading...   26.1% of 647 filesrandom seed for tests: 1510261509
compiling... 75.4% of 647 filesbuilding of 
`/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' timed out after 
3600 seconds of silence
kguix pull: error: build failed: build of 
`/gnu/store/gk5chb0dwpsq3na7b4gn1hd7h0h2b63h-guix-latest.drv' failed

real609m30.245s
user0m3.125s
sys 0m0.875s
```

This command did work last time as root.  It only worked once.
Special things to note this time:

- it hangs at 75.4 % instead of 75.2 %;
- it took over 10 h to give me back control, whereas this used to be
  a bit over 2 h in previous tries;
- using only one core did not help this time.

What is Guix doing between 75.2 and 75.4 %?

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Hello,

Op 09 nov 20:27 schreef Marco van Hulten:
> Right now I'm updating packages, and things are looking up.

Well... concerning the root user.  As the manual states that one needs
to do a `guix pull' for any user for whom you want to upgrade the
packages, I did that here, but it failed:

```
kodi@watson ~$ export GUILE_WARN_DEPRECATED="detailed"
kodi@watson ~$ time guix pull --cores=1

Starting download of /tmp/guix-file.vAOlZl
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   1.8MiB/s 00:07 | 13.8MiB transferred
unpacking '/gnu/store/3kh26avmdfz01gmfdd88692bv0cm5ic5-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv
copying and compiling to 
'/gnu/store/hqzlhmjqyip7qys36fjligi7p4zavhhp-guix-latest' with Guile 2.2.2...
loading...   20.4% of 647 filesBacktrace:
In ice-9/boot-9.scm:
  2879:24 19 (_)
   230:29 18 (map1 _)
   230:29 17 (map1 _)
   230:29 16 (map1 _)
   230:29 15 (map1 _)
   230:29 14 (map1 _)
   230:29 13 (map1 _)
   230:29 12 (map1 _)
   230:17 11 (map1 (((gnu packages linux)) ((gnu packages ncurses
  2792:17 10 (resolve-interface (gnu packages linux) #:select _ # _ # ?)
  2718:10  9 (_ (gnu packages linux) _ _ #:ensure _)
  2986:16  8 (try-module-autoload _ _)
   2316:4  7 (save-module-excursion _)
  3006:22  6 (_)
In unknown file:
   5 (primitive-load-path "gnu/packages/linux" #)
In ice-9/eval.scm:
619:8  4 (_ #f)
   626:19  3 (_ #)
   173:55  2 (_ #)
   223:20  1 (proc #)
In unknown file:
   0 (%resolve-variable (7 . %intel-compatible-systems) #<di?>)

ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: %intel-compatible-systems

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
builder for `/gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv' 
failed with exit code 1
guix pull: error: build failed: build of 
`/gnu/store/499sa14r2f940asrwrflkwgj85iih67m-guix-latest.drv' failed

real1m49.870s
user0m2.869s
sys 0m0.434s
```

The message here, together with the fact that --cores=1 worked (see
previous message in thread), suggests that /proc/cpuinfo may be useful:

https://paste.debian.net/994931/

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludo'-

Op 09 nov 14:19 schreef Ludovic Courtès:
> How many CPUs and how much RAM does this machine have?  Does it help in
> any way to run “guix pull --cores=2”, thereby limiting CPU usage to two
> cores?

I have two processors, so I tried to run it on one, and it worked:

```
root@watson ~# time guix pull --cores=1 
 

Starting download of /tmp/guix-file.kQQ8AM
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   2.8MiB/s 00:05 | 13.8MiB transferred
unpacking '/gnu/store/v1zs6bfaam79wp9pf1ja9k8ys4f3dm2s-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/5admrckcwdqgqix1d7hfj23fczk2k7ss-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
copying and compiling to 
'/gnu/store/pmk3b4sqqnizkhmrxx7cdyj4as0ym6r4-guix-latest' with Guile 2.2.2...
loading...   26.1% of 647 filesrandom seed for tests: 1510251772
compiling...100.0% of 647 files

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
updated GNU Guix successfully deployed under `/root/.config/guix/latest'

real37m0.478s
user0m2.963s
sys 0m0.508s
```

Right now I'm updating packages, and things are looking up.

Do you have any idea what went wrong when using both cores?

I am conflating cores and processors right now.  I think these are
equal for this system, but I'm not sure.  I have an Intel Core2 Duo.
/proc/cpuinfo shows two processes.  Furthermore, I presume that
`--cores N` actually means that guix spawns N processes.

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludo'-

Minor additional info below.

Op 08 nov 02:37 schreef Marco van Hulten:
> Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.

I tried with this suggestion, and actually got less information with
this (no "failed to expand heap"):

```
kodi@watson ~$ GUILE_WARN_DEPRECATED="detailed" guix pull

Starting download of /tmp/guix-file.BDW8Cd
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   3.4MiB/s 00:04 | 13.8MiB transferred
unpacking '/gnu/store/kd7k7ndc31hp73liwm93vpjpx9wb47k7-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
copying and compiling to 
'/gnu/store/s1gx4pamdwsqmgxqjz86c2g2pisxm14k-guix-latest' with Guile 2.2.2...
loading...   26.0% of 646 filesrandom seed for tests: 1510124252
compiling... 75.2% of 646 filesbuilding of 
`/gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv' timed out after 
3600 seconds of silence
guix pull: error: build failed: build of
`/gnu/store/15zzkryzyx984h4yz2rbzgm2rax2c1i8-guix-latest.drv' failed
```

Do you have any tips for stressing hd, memory, cpu, to try to exclude
hardware issues?  I can install packages in GuixSD with success.

-Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludovic-

This is the second time I tried a `guix pull':

```
root@watson ~# time guix pull

Starting download of /tmp/guix-file.x2AvJM
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   2.3MiB/s 00:06 | 13.8MiB transferred
unpacking '/gnu/store/5sgb93jdacr36xv0xm67zr7dmlr1yyb0-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv
   /gnu/store/6gxf5snkl5him1iqg6aqmpyn5ggijhx5-module-import-compiled.drv
   /gnu/store/fxnbl74nxjzzm44f1j25glsb3gav4k6b-module-import.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
copying and compiling to 
'/gnu/store/z8zygkj1c97xskgzxhwy4ys2b0x6shwm-guix-latest' with Guile 2.2.2...
loading...   26.0% of 646 filesrandom seed for tests: 1510087321
compiling... 75.2% of 646 filesGC Warning: Failed to expand heap by 8388608 
bytes
building of `/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' timed 
out after 3600 seconds of silence
guix pull: error: build failed: build of 
`/gnu/store/s71rww59a0avvk9di4rkq3j5f9zvr62k-guix-latest.drv' failed

real142m53.606s
user0m3.098s
sys 0m1.369s
```

It took over 2 hours before I had control back over the system.  It is
very similar to the first `git pull' (even for the transfer speeds and
the percentage where `guix pull' hangs).  Of course, file/directory
checksums are different.  Also, it now tries to build three
`derivations' instead of one.  There is also a warning on about an
environment variable this time.

- Marco

Re: successful installation, but problems updating

[Marco van Hulten]

Ludovic-

Op 07 nov 10:20 schreef Ludovic Courtès:
> Marco van Hulten <ma...@hulten.org> skribis:
> 
> > root@watson ~# guix pull
> >
> > Starting download of /tmp/guix-file.F5p3in
> > From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
> >  ….tar.gz   2.3MiB/s 00:06 | 13.8MiB 
> > transferred
> > unpacking 
> > '/gnu/store/5qcf02fjmi4y4chh3c07ardvjlw355gw-guix-latest.tar.gz'...
> > substitute: updating list of substitutes from 
> > 'https://mirror.hydra.gnu.org'... 100.0%
> > substitute: updating list of substitutes from 
> > 'https://mirror.hydra.gnu.org'... 100.0%
> > The following derivation will be built:
> >/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv
> > updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
> > 100.0%g'...   0.0%
> > copying and compiling to 
> > '/gnu/store/4gs1fivs32qw3xrn5z1dq3hr9xmblv18-guix-latest' with Guile 
> > 2.2.2...
> > loading...   26.0% of 646 filesrandom seed for tests: 1509990307
> > compiling... 75.2% of 646 filesbuilding of 
> > `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' timed out 
> > after 3600 seconds of silence
> > guix pull: error: build failed: build of 
> > `/gnu/store/nd19z0mxhj81p1pc5f86ahxkzih6z2mg-guix-latest.drv' failed  
> 
> Ouch, I’ve never seen reports for this kind of failure before.
> 
> It is 100% reproducible every time you run ‘guix pull’?

It happens every time.  Whether the terminal output is identical (e.g.,
timing out at 75.2%, but not the hash) I plan check in about half a day.

-Marco

successful installation, but problems updating

[Marco van Hulten]

Hello,

I installed GuixSD 0.13.0 with success!  But I still have a couple
of issues and questions concerning updating the system and installing
packages.  I followed the [installation guide][1].

[1]:
https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html


'guix pull' ends with a compilation error:

> guix pull: error: build failed: build of
> `/gnu/store/*-guix-latest.drv' failed


After this I should execute this command.

> $ guix system reconfigure
> guix system: error: wrong number of arguments for action 'reconfigure'

I expected this not to work properly anyway because 'guix pull' did not
succeed, but this seems like a syntax error that would have come up
also after a correct 'guix pull' (except, of course, if 'guix pull'
would provide files that account for the right number of arguments —
but I don't understand Guix well enough to make any good presumptions
about it).


Finally, have two more general questions (possibly related) about
Guix.

Firstly, it often says that I need to use '--fallback'.  Is that
because the binary is not available?

Secondly, I noted that with, e.g., 'guix package -i kodi' software gets
compiled.  I understood that GNU Guix is capable of both binary and
source packages.  Which should I typically expect?  Can I choose?


I attached my 'config.scm' (sadly, the paste.lisp.org service has just
been disabled).  This is what I understand as the single most important
configuration file of any GuixSD installation.

-Marco
;; This is an operating system configuration template
;; for a "desktop" setup.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop ssh)
(use-package-modules wm ratpoison certs suckless gnome)

(operating-system
  (host-name "watson")
  (timezone "Europe/Oslo")
  (locale "en_US.utf8")

  ;; Assuming /dev/sda is the target hard disk, and "my-root"
  ;; is the label of the target root file system.
  (bootloader (grub-configuration (device "/dev/sda")))

  (file-systems (cons* (file-system
(device "my-root")
(title 'label)
(mount-point "/")
(type "ext4"))
  (file-system
(device "my-home")
(title 'label)
(mount-point "/home")
(type "ext4"))
  %base-file-systems))

  (users (cons* (user-account
(name "kodi")
(comment "mediacenter")
(group "users")
(supplementary-groups '("wheel" "netdev"
            "audio" "video"))
(home-directory "/home/kodi"))
   (user-account
(name "marco")
(comment "Marco van Hulten")
(group "users")
(supplementary-groups '("wheel" "netdev"
"audio" "video"))
(home-directory "/home/marco"))
   %base-user-accounts))

  ;; Add a bunch of window managers; we can choose one at
  ;; the log-in screen with F1.
  (packages (cons* ratpoison i3-wm i3status dmenu ;window managers
   nss-certs  ;for HTTPS access
   gvfs  ;for user mounts
   %base-packages))

  ;; Add GNOME and/or Xfce---we can choose at the log-in
  ;; screen with F1.  Use the "desktop" services, which
  ;; include the X11 log-in service, networking with Wicd,
  ;; and more.
  (services (cons* (xfce-desktop-service)
   %desktop-services))

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss))

partitions and filesystems

[Marco van Hulten]

Hello,

Something is not so clear to me on this page:

https://www.gnu.org/software/guix/manual/html_node/Preparing-for-Installation.html

under section "6.1.4.3 Disk Partitioning":

> Preferably, assign partitions a label so that you can easily and
> reliably refer to them in file-system declarations (see File
> Systems). This is typically done using the -L option of mkfs.ext4 and
> related commands. So, assuming the target root partition lives
> at /dev/sda1, a file system with the label my-root can be created
> with: mkfs.ext4 [...]

and

> mount the target root partition under /mnt with a command like
> (again, assuming my-root is the label of the root partition)

Wait, "my-root" was the label of the filesystem, right?


I think the terms "partition" and "filesystem" are confused here.  I
propose that this be correct and consistent, so

- a partition has a "partition label";
- a filesystem has a "filesystem label", or "volume label" when
  following mkfs(8) terminology.

Could someone make this consistent?  Or I could propose an updated text.
Should I send them in plain text to guix-devel?

-Marco

Re: no passwd command during installation

[Marco van Hulten]

Chris-

Op 01 nov 22:59 schreef Chris Marusich:
> Marco van Hulten <ma...@hulten.org> writes:
> 
> > Hello,
> >
> > During the installation process of GuixSD 0.13.0, I'd like to login
> > from another system.  After setting up the network, I start the SSH
> > server through
> >
> > herd start ssh-daemon
> >
> > as described on
> > https://www.gnu.org/software/guix/manual/html_node/Preparing-for-Installation.html
> > .
> >
> > Then I want to set the root password.  The manual tells me to use
> > passwd, but Bash returns "command not found".  There is also no
> > ssh-keygen to create SSH keys.  
> 
> These commands are present in a recent version of the installation
> image.  Perhaps the version you used is old enough that they are not
> present?  Since Wayne also seems to have seen the same problem, I
> wonder if perhaps it's an issue with an old image being hosted
> somewhere? Where did you get the installation image?

I downloaded the latests System Distribution image at
https://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.13.0.x86_64-linux.xz .
I just checked the signature, and it is in order.

> I verified that the commands are present by running the following
> commands from a system that has a recent version of Guix:
> 
>   $ guix system vm gnu/system/install.scm
>   ...
>   /gnu/store/zrcjqk520wlbq0m9rq8ss60sj24hjpjg-run-vm.sh
>   $ /gnu/store/zrcjqk520wlbq0m9rq8ss60sj24hjpjg-run-vm.sh
> 
> The commands "passwd" and "ssh-keygen" were present at
> /run/setuid-programs/passwd and

This directory in my image is empty.

> /run/current-system/profile/bin/ssh-keygen, respectively.

This directory contains 411 symlinks to binaries, none of which match
with ssh*.

> > Additionally, it could be useful if the scp or ssh were available
> > from the installation prompt.  
> 
> Similar to above, I can confirm that the programs "ssh" and "scp" are
> present in a recent version of the installation image.

Possibly, Wayne and I used the (experimental) GuixSD 0.13.0 image,
whereas you use the GuixSD 0.13.0 Virtual Machine Image.  I presume we
all are on amd64.

I did find the programs at the locations (with different hash in path)
that Wayne suggested; this issue could be solved by updating the manual
(updating the image can wait until the next release).

> > SSH in either direction would give me a way to copy config.scm to a
> > system where I can e-mail from.  That would be useful, because I am
> > having problems installing GuixSD (unionfs of 2.1G gets full during
> > guix system init /mnt/etc/config.scm /mnt --fallback; the last
> > option was suggested by guix when it couldn't fetch some package).  
> 
> That sounds frustrating!  Maybe you can try first installing the "bare
> bones" operating system (the example file for this is located at
> /etc/configuration/bare-bones.scm in the installation image). After
> you've booted into that initial bare bones operating system, you could
> run "guix system reconfigure" using the actual operating system
> configuration file you want.  That might help if the issue is lack of
> storage space in the installation image.

That's a useful tip for when I have a similar problem again.  Doing the
installation again results in a succesful installation (well, more or
less).  It is very likely that I forget

herd start cow-store /mnt

which makes the installation use the harddisk instead of RAM.  However,
I always need to use --fallback.

In any case, thanks to you and Wayne for the useful tips.


Now for the "well, more or less".  When booting my system with a
freshly installed GuixSD, I get this output:

```
waiting for partition 'my-root' to appear...
waiting for partition 'my-root' to appear...
...
ERROR: In procedure scm-error:
ERROR: failed to resolve partition "my-root"
```

My etc/config.scm is here: http://paste.lisp.org/display/360070

- Marco
;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.

(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
(use-package-modules certs gnome)

(operating-system
  (host-name "watson")
  (timezone "Europe/Oslo")
  (locale "en_US.utf8")

  ;; Assuming /dev/sdX is the target hard disk, and "my-root"
  ;; is the label of the target root file system.
  (bootloader (grub-configuration (device "/dev/sda")))

  ;; Specify a mapped device for the encrypted root partition.
  ;; The UUID is that returned by 'cryptsetup luksUUID'.
  (mapped-devices
   (list (mapped-device
  (source (uuid "c0a2b51e-0c50-43e7-a56b-932061c00af8"))

no passwd command during installation

[Marco van Hulten]

Hello,

During the installation process of GuixSD 0.13.0, I'd like to login
from another system.  After setting up the network, I start the SSH
server through

herd start ssh-daemon

as described on
https://www.gnu.org/software/guix/manual/html_node/Preparing-for-Installation.html
 .

Then I want to set the root password.  The manual tells me to use
passwd, but Bash returns "command not found".  There is also no
ssh-keygen to create SSH keys.


Additionally, it could be useful if the scp or ssh were available from
the installation prompt.  SSH in either direction would give me a way to
copy config.scm to a system where I can e-mail from.  That would be
useful, because I am having problems installing GuixSD (unionfs of 2.1G
gets full during guix system init /mnt/etc/config.scm /mnt --fallback;
the last option was suggested by guix when it couldn't fetch some
package).

-Marco