Re: How do I put assign supplementary groups to nginx user?

[Thompson, David]

Hi Jayesh,

On Tue, Mar 19, 2024 at 2:44 AM Jayesh Bhoot  wrote:
>
> Hello,
>
> I am setting up a git server with Guix System with the following 
> configuration:
>
> - A git user with home directory set to /srv/git, so that git repos can be 
> hosted from /srv, and the repo urls can have the shortest path possible, like 
> git@server:test-repo.git.
> - A git group to which the git user is assigned.
> - cgit-service-type to serve a read-only view of the repos, with nginx acting 
> as the server.
>
> In order to serve the repos, nginx needs access to /srv/git. But, /srv/git, 
> being a home directory, has the configuration of 700 git:git by default. I 
> need to loosen up its permissions to at least 750 so that the git group 
> members can read the directory, and add nginx user to the git group.
>
> How do I encode the following withing the system-configuration.scm?
>
> - add nginx user to git supplementary group. Neither (cgit-service-type) not 
> (nginx-configuration) provide option to edit nginx's supplementary group, and 
> %nginx-accounts does not seem to be exported.
> - modify permissions of home directory /srv/git to 750. (user-account) does 
> not seem to have this option.

Unfortunately, some Guix services lack flexibility when it comes to
groups. The nginx service is one of them. My workaround for using
nginx and cgit together has been to make a modified nginx service that
adds the 'git' group to the 'nginx' user's supplementary groups.

Regarding file permissions, I use the gitolite service which creates a
home directory that's readable by the 'git' group.  To do so without
gitolite probably requires a similar modification of the cgit service
to modify the permission bits of the 'git' user's home directory.

Maybe my config source will help you:
https://git.dthompson.us/guix-config/tree/dthompson/machines/takemi.scm#n21

Good luck!

- Dave

Re: guile-hoot install reproducibly crashes at 41% build

[Thompson, David]

Hi Felix,

On Sat, Oct 28, 2023 at 11:29 PM Felix Lechner
 wrote:
>
> Hi Dave,
>
> On Fri, Oct 27 2023, Thompson, David wrote:
>
> > Or remove v8 from the package inputs at the bottom of the guix.scm
> > file.  We only use V8 for the test suite.
>
> I know it's impolite to quote oneself, but please grant me a brief plug
> to drop build-time tests everywhere. [1]
>
> Package declarations would list (test-inputs ...) separately. For many
> packages, it has the potential to reduce the prerequisites actually
> needed to build them.

That's good to know! Thanks for the tip. I'm behind the times on that
detail. In this particular case, though, Mortimer was trying to build
our development environment, in which we definitely want V8.  The
package in Guix core doesn't use it. :)

- Dave

Re: guile-hoot install reproducibly crashes at 41% build

[Thompson, David]

Hi again,

I see a couple more issues...

On Fri, Oct 27, 2023 at 3:27 PM Mortimer Cladwell  wrote:
>
> Thanks Dave.
> I gave 'guix shell guile-next guile-hoot' a try.
> Please see the error below: In procedure resolve-interface: no binding 
> `define-custom-primcall-conver
ter' in module (language tree-il compile-cps) and note that the
reflect.wasm file was not generated.
> Thanks
> Mortimer
>
> mbc@ins3910:~/projects/guile-hoot$ guix shell guile-next guile-hoot
> 45.4 MB will be downloaded
>  glibc-2.35  8.5MiB   
>  5.5MiB/s 00:02 ▕██▏ 
> 100.0%
>  guile-next-3.0.9-0.79e836b  7.2MiB   
>  1.5MiB/s 00:05 ▕██▏ 
> 100.0%
>  glibc-2.35-static  1.4MiB
>  3.8MiB/s 00:00 ▕██▏ 
> 100.0%
>  guile-next-3.0.9-0.79e836b-debug  6.9MiB 
>  3.6MiB/s 00:02 ▕██▏ 
> 100.0%
>  glibc-2.35-debug  19.3MiB
>  6.2MiB/s 00:03 ▕██▏ 
> 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
>   /gnu/store/0vyk4cd0y1zj8bkrifmg73hd3jbgjffd-profile.drv
>
> 3.4 MB will be downloaded
>  module-import-compiled  107KiB   
>  440KiB/s 00:00 ▕██▏ 
> 100.0%
>  guile-2.0.14  3.0MiB 
>  1.6MiB/s 00:02 ▕██▏ 
> 100.0%
>  module-import-compiled  47KiB
>  8.3MiB/s 00:00 ▕██▏ 
> 100.0%
>  module-import-compiled  57KiB
>  8.4MiB/s 00:00 ▕██▏ 
> 100.0%
>  module-import-compiled  72KiB
> 10.8MiB/s 00:00 ▕██▏ 
> 100.0%
> applying 8 grafts for guile-next-3.0.9-0.79e836b ...
> applying 2 grafts for libffi-3.4.4 ...
> applying 3 grafts for libfontenc-1.1.4 ...
> applying 2 grafts for libgc-8.2.2 ...
> applying 2 grafts for libunistring-1.0 ...
> applying 8 grafts for mkfontscale-1.2.2 ...
> applying 2 grafts for pkg-config-0.29.2 ...
> applying 2 grafts for mkfontdir-1.0.7 ...
> applying 7 grafts for guile-3.0.9 ...
> applying 6 grafts for texinfo-6.8 ...
> building CA certificate bundle...
> listing Emacs sub-directories...
> building fonts directory...
> building directory of Info manuals...
> building profile with 2 packages...
> mbc@ins3910:~/projects/guile-hoot [env]$ guile
> GNU Guile 3.0.9

Looks like your shell environment is clobbering the Guix environment.
This is Guile 3.0.9 stable, not the Guile provided by Guile next.  The
version string should look like this:

guile (GNU Guile) 3.0.9-0.c2cba86

You can try using the --pure or --container flag to isolate guix shell
from the rest of your system more.

> Copyright (C) 1995-2023 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> ,use (hoot compile)
> While executing meta-command:
> In procedure resolve-interface: no binding `define-custom-primcall-converter' 
> in module (language tree-il compile-cps)
> scheme@(guile-user)>  (define the-answer (compile 42))
> scheme@(guile-user)> ,use (wasm parse)
> scheme@(guile-user)> (define reflector
>(call-with-input-file 
> "/home/mbc/projects/guile-hoot/js-runtime/reflect.wasm"
>  parse-wasm))

reflect.wasm is a build artifact. Since you haven't built Hoot from
the Git checkout, there is no reflect.wasm for you to use there.
Instead, use the one installed by Guix. The file name for it can be
computed like so:

   echo $(guix build guile-hoot)/share/guile-hoot/js/js-runtime/reflect.wasm

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure open-file: No such file or directory: 
> "/home/mbc/projects/guile-hoot/js-runtime/reflect.wasm"

If you'd like to build Hoot from the Git checkout but skip V8, you
could try this:

  guix shell guile-next autoconf automake pkg-config texinfo

Or remove v8 from the package inputs at the bottom of the guix.scm
file.  We only use V8 for the test suite.

Hope this helps,

- Dave

Re: guile-hoot install reproducibly crashes at 41% build

[Thompson, David]

Hi Mortimer,

On Fri, Oct 27, 2023 at 7:01 AM Mortimer Cladwell  wrote:
>
> Hi,
>
> I did a git pull https://gitlab.com/spritely/guile-hoot.git
> I am following installation instructions at
> https://spritely.institute/files/docs/guile-hoot/0.1.0/Installation.html
> I am using guix
> The first attempt installs lots of stuff but at the build stage crashes at
> 41%. I need to reboot and retry:
>
> mbc@ins3910:~/projects/guile-hoot$ guix shell
> guix shell: loading environment from
> '/home/mbc/projects/guile-hoot/guix.scm'...
> The following derivation will be built:
>   /gnu/store/lfx6a7a16jydk0zzlppwgv9ajsa92wia-v8-11.7-1.155ea5c.drv
>
> building
> /gnu/store/lfx6a7a16jydk0zzlppwgv9ajsa92wia-v8-11.7-1.155ea5c.drv...
>  41% ▕█▋
> ▏guix shell: error: corrupt input while restoring archive from
> #
>
> To recover I must reboot and do a 'guix pull' but I get the same results:
> crash at ~41%
>
> I tried:
> guix package --delete-generations
> guix gc
> cd ./projects/guile-hoot
> guix shell
>
> Seems to re-initiate the entire build process but same results -crash at
> 41% build
> I am using Ubuntu on an Intel i5-12400 processor with 8GB RAM
>
> Has anyone had success with this install process? Suggestions?

Couple of things:

1) The Hoot docs describe building from source via a Git checkout.
That gets you the same environment we use to develop Hoot, but it
requires building V8 which is pretty intense. Looks like that's where
your build is getting stuck. You'll need to increase verbosity to get
a pointer to the build log to see details about the failure. Could be
that 8GB of RAM is simply not enough to build V8.

2) Hoot is available in Guix now. If you just want to use Hoot, just
do `guix shell guile-next guile-hoot`. We'll have this in the manual
for the next release now that it's packaged for Guix officially.

Hope this helps,

- Dave

Re: guix shell without arguments

[Thompson, David]

Hi Simon,

On Fri, May 12, 2023 at 12:10 PM Simon Tournier
 wrote:
>
> Hi,
>
> On ven., 12 mai 2023 at 14:06, André A. Gomes  wrote:
>
> > --8<---cut here---start->8---
> > guix shell -D -f /path/to/guix.scm -- foo-command
> > --8<---cut here---end--->8---
> >
> > The incantation below creates an empty environment.  But wouldn't it be
> > nice if it would infer manifest.scm or guix.scm, in case they exist in
> > the current directory?
> >
> > --8<---cut here---start->8---
> > guix shell -- foo-command
> > --8<---cut here---end--->8---
>
> That’s already the case, no?   From the manual:
>
> If it finds a manifest.scm in the current working directory or any
> of its parents, it uses this manifest as though it was given via
> --manifest. Likewise, if it finds a guix.scm in the same
> directories, it uses it to build a development profile as though
> both --development and --file were present. In either case, the file
> will only be loaded if the directory it resides in is listed in
> ~/.config/guix/shell-authorized-directories. This provides an easy
> way to define, share, and enter development environments.
>
> 
>
> Is it a regression?

It *sounds* like it should be the case, but it isn't. Specifying the
command to run explicitly is considered a non-interactive case, and in
non-interactive mode the automagic guix.scm/manifest.scm reading does
not occur. :(

- Dave

Re: guix shell without arguments

[Thompson, David]

Hi Andre,

On Fri, May 12, 2023 at 7:07 AM André A. Gomes  wrote:
>
> Hello Guix,
>
> Issuing guix shell without arguments is equivalent to the command below,
> when guix.scm exists in the directory where it's being issued:
>
> --8<---cut here---start->8---
> guix shell -D -f /path/to/guix.scm
> --8<---cut here---end--->8---
>
> I am wondering if there's a more succinct way of saying:
>
> --8<---cut here---start->8---
> guix shell -D -f /path/to/guix.scm -- foo-command
> --8<---cut here---end--->8---
>
> The incantation below creates an empty environment.  But wouldn't it be
> nice if it would infer manifest.scm or guix.scm, in case they exist in
> the current directory?
>
> --8<---cut here---start->8---
> guix shell -- foo-command
> --8<---cut here---end--->8---

I agree with you! It's a big usability issue! Even though I'm aware of
this behavior, I still catch myself trying to do `guix shell --
foo-command` from time to time and being disappointed. I filed an
issue about this awhile back and the tl;dr is that the behavior can't
be changed (at least not easily) without breaking things for users who
have different expectations/needs: https://issues.guix.gnu.org/57467

There seem to be two main use cases that are sort of at odds with each other:

1) Users who invoke 'guix shell' in their terminal and want "do what I
mean" implicit behavior (I'm in this group and suspect you are, too)
2) Users who invoke 'guix shell' in scripts and want all behavior to
be explicit using flags so that the scripts behave in a reliable way

'guix shell' is primarily focused on case 2, and case 1 is only
supported when 'guix shell' has no other args, as you've noticed.
Perhaps this is an indicator that we need two different tools.  I've
thought for years that we need a 'guix develop' (working title) tool
that does what 'guix shell' does but also goes beyond by starting
containerized services like 'docker compose' can. For example, if a
project requires a PostgreSQL database, 'guix develop' could create a
shell environment with the client program/library but also
automatically start the server using an instance of Shepherd and
'herd' inside the shell could be used to control the service.

- Dave

Re: Issue with 'guix shell' for Guile projects on non-Guix distros

[Thompson, David]

Hi Ludo,

On Thu, Mar 16, 2023 at 11:55 AM Ludovic Courtès  wrote:
>
> Hello,
>
> "Thompson, David"  skribis:
>
> > Here's the context: Someone wants to build guile-goblins from a Git
> > checkout using their non-Guix, FHS distro. However, they happen to
> > have Guile 3 installed to /usr via the host distro's package manager.
>
> I was going to suggest running ‘guix shell --check …’, which can detect
> a class of problems on non-Guix distros, but that’s not the problem
> here.
>
> > They install Guix, run 'guix shell', then './bootstrap.sh' and that
> > all works fine. Then they run './configure' and this happens:
>
> [...]
>
> > The most important line above is:
> >
> > checking for guile-3.0... /usr/bin/guile-3.0
> >
> > Guile's guile.m4 code checks for a 'guile-3.0' executable *before*
> > checking for a 'guile' executable.  Guix's Guile package only provides
> > 'guile', but the host distro provides 'guile-3.0'.  Unfortunately, the
> > build environment ends up as a mix of host distro and Guix things
> > which eventually proves fatal to the build.
>
> I’ve not encountered this before.
>
> My suggestion would be to recommend running ‘guix shell -CP’ as this
> addresses problems of that sort once and for all.  I do that, even on
> Guix System: it’s pretty reassuring to know that your dev environment is
> isolated from the rest.
>
> Alternatively, ‘guix shell --pure’ would also address that because then
> ‘configure’ wouldn’t look for programs under /usr/bin.  It’s less robust
> though.

I should have mentioned that we did get a working environment by using
--container, but it required explaining why the tools from the host,
like git, were no longer available and how those would have to be used
outside of the Guix shell.  Same with --pure, only with additional
complications because of a .bashrc that was referring to lesspipe and
other things that were no longer available.  I tend to prefer plain
'guix shell' because, usually, it does the right thing without
additional surprises for someone who is unfamiliar with Guix.  Each
method has its downsides, not sure what to recommend going forward.

- Dave

Issue with 'guix shell' for Guile projects on non-Guix distros

[Thompson, David]

Hey everyone,

At Spritely we've run into a situation where 'guix shell' doesn't
"just work" for setting up a development environment and we're
wondering about the best way to fix it.  We're experiencing this issue
with our guile-goblins project currently, but this appears to be a
more general problem that likely affects most projects that use
Guile's guile.m4 autoconf code.

Here's the context: Someone wants to build guile-goblins from a Git
checkout using their non-Guix, FHS distro. However, they happen to
have Guile 3 installed to /usr via the host distro's package manager.
They install Guix, run 'guix shell', then './bootstrap.sh' and that
all works fine. Then they run './configure' and this happens:

$ ./configure
checking for a BSD-compatible install...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for pkg-config...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 3.0
configure: found guile 3.0
checking for guile-3.0... /usr/bin/guile-3.0
checking for Guile version >= 3.0... 3.0.7
checking for guild-3.0...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/guild
checking for guile-config-3.0... no
checking for Guile site directory...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/share/guile/site/3.0
checking for Guile site-ccache directory using pkgconfig...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/site-ccache
checking for Guile extensions directory...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/extensions
checking if (fibers) is available... no
configure: error: required guile module not found: (fibers)

The most important line above is:

checking for guile-3.0... /usr/bin/guile-3.0

Guile's guile.m4 code checks for a 'guile-3.0' executable *before*
checking for a 'guile' executable.  Guix's Guile package only provides
'guile', but the host distro provides 'guile-3.0'.  Unfortunately, the
build environment ends up as a mix of host distro and Guix things
which eventually proves fatal to the build.

As a workaround, I am considering adding a package to our manifest.scm
file that symlinks 'guile' to 'guile-3.0', 'guild' to 'guild-3.0',
etc. so that they take priority over the host executables.
Internally, we are tracking this issue here:
https://gitlab.com/spritely/guile-goblins/-/issues/84

Has anyone encountered something like this before?  If so, how did you
deal with it?  Should something be changed in Guix itself to avoid
this issue altogether?

- Dave

thermald updated to suport Intel Alder Lake CPUs

[Thompson, David]

Hello everyone,

I suspected my laptop was having some overheating issues this morning
and I realized that I wasn't running thermald like I should. So, I
added the thermald service to my OS config but the service failed to
start because my CPU wasn't supported. Turns out that was because our
thermald package was at version 2.4.7 which did not have support for
12th gen Intel Alder Lake CPUs. I upgrade our package to 2.5.1 and now
thermald works. If you have an Alder Lake CPU and want thermald to
actually work, you should run 'guix pull' and then reconfigure your
system!

- Dave

Re: Understanding the Guix approach when language package managers are around

[Thompson, David]

Hi Daniel,

On Fri, Sep 16, 2022 at 10:48 AM Daniel Sockwell
 wrote:
>
> Hi all,
>
> (I also asked this question in r/guix; sorry if you're seeing it
> twice.)
>
> I'm trying to understand how Guix "wants" me to install software
> that's in language package managers, such as npm, Leiningen, etc.
> My current approach to installing some non-packages software
> gives me the feeling that I'm fighting against Guix -- usually a
> clear sign that I'm missing something.
>
> Here's a specific example (though note that I'm asking about overall
> approaches; I'm not currently seeking help debugging this specific
> install).  I use a keyboard with open-source firmware and would like
> to install the configuration utility, Chrysalis
> (https://github.com/keyboardio/Chrysalis) for that firmware.
>
> My first step, of course, was to check if Guix packages Chrysalis
> (it's licensed under GPLv3, so we could); but we don't package it.
> From the project `README`, I see that Chrysalis is distributed as an
> AppImage, so on any other distro I'd use that.  However, I know that
> AppImages don't cooperate well with Guix, so that's out.  The `README`
> also shows that Chrysalis is a JavaScript program (actually an
> Electron app), so the normal/non-Guix installation would be to run
> `npm install` and go from there.
>
> I can think of two ways to proceed:
>
>   1. Install Node/npm and attempt to install Chrysalis just like I
>   would on any other distro

This is the way I would recommend, if you can get it to work.

>   2. Attempt to package Chrysalis via Guix (probably using the
>   `node-build-system`) and then install it normally

As you explain below, here be dragons. :(

> But both of these approaches give me the feeling that I'm Doing It
> Wrong™.  With the first, I immediately hit errors about libraries not
> being where Node expected.  I might be able to work around those (a
> guide on the mailing list seems promising
> https://lists.gnu.org/archive/html/help-guix/2018-06/msg00052.html).
> But, even if I did, I'd be left with a package that is entirely
> outside Guix's functional model -- which seems like a hint that this
> isn't the Guix approach.

Yes, ideally, everything could be managed with Guix.  However, with
node, this is the best that you can do right now.

> But looking into option 2 (packaging Chrysalis) doesn't seem promising
> either.  My understanding is that packaging Chrysalis involves listing
> its dependencies as `inputs`.  And that could be hard. Chrysalis has
> ~40 dependencies most of which aren't packaged for Guix.  And many of
> those dependencies have their own transitive dependencies -- the full
> graph seems to include 1,534 programs (for comparison, Guix currently
> packages 51 `node-*` programs).  Given that I'm fairly new to Guix, I
> very much doubt I should be trying to package a bunch of software.
> Plus, even if I did, I doubt Guix would want to host an order of
> magnitude more Node packages.  So, again, I get the sense that going
> this route would be fighting against Guix instead of working with it.

Unfortunately, you're right.  Many have tried to untangle the mess,
but no one has succeeded.  Here's a blog post from 2015 that
illustrates some of the problems:

https://dustycloud.org/blog/javascript-packaging-dystopia/

Unfortunately, the problems are still the same in 2022.  Huge
dependency trees with likely multiple versions of *the same library*
in it, circular dependencies when "dev dependencies" (aka the stuff
you need to build from source) are taken into account, missing
licenses, binary blobs with no source, proprietary code, etc.  It's a
real mess.

> So that's my question.  Are one of those approaches correct and I'm
> just confused on the details?  Or is there some other approach to
> installing this GPLv3 software that's the "real" Guix approach?  Or is
> this sort of multi-dependency JavaScript app just a weak point for
> Guix at the moment?

Guix's highly reproducible, source-based approach is very much at odds
with the npm model of distribution which is effectively the polar
opposite.  If you can sort out your issues with making the npm tool
work on a Guix system, I would just go that route for lack of a
feasible alternative.

Sorry for the bad news!  Good luck!

- Dave

Re: [EXT] Use package transformation to get commit of eglot

[Thompson, David]

Hi jgart,

On Thu, Sep 1, 2022 at 11:43 AM jgart  wrote:
>
> Hi,
>
> Is anyone able to successfully get the latest eglot with a package 
> transformation?
>
> I get the following error for commit 000b7fdce93ed29c505a7fa75baaf87094fd690a:
>
> ```
> $ guix install emacs-eglot 
> --with-commit=emacs-eglot=000b7fdce93ed29c505a7fa75baaf87094fd690a
> guix install: error: the source of emacs-eglot@1.8 is not a Git reference
> ```
>
> am i doing it all wrong?

You were very close. The emacs-glot package gets its source code via
https, not git. So you need to additionally apply a transformation
that changes it to a git source.  The following command worked for me
to get a successful build:

guix build emacs-eglot
--with-git-url=emacs-eglot=https://github.com/joaotavora/eglot.git
--with-commit=emacs-eglot=000b7fdce93ed29c505a7fa75baaf87094fd690a

Hope this was useful!

- Dave

Re: Enterprise Guix Hosting?

[Thompson, David]

Hi Olivier,

On Wed, Aug 31, 2022 at 7:42 AM Olivier Dion  wrote:
>
> On Wed, 31 Aug 2022, "Thompson, David"  wrote:
> > Hey that's a real nice starting point for a container management tool!
> >  So maybe there should be a system service to manage containers and
> > then a 'docker compose'-like tool for declaratively specifying
> > containers and their network bridging configuration that is a client
> > of the service?
>
> I think that a container composer à la `docker compose' but with
> Guile/Guix is easily done. Managing containers locally is trivial and a
> little web interface could be done to view/manager your contrainers.
> The service could even be a home-service.
>
> From there, a more mature container orchestrator that can scale
> to multiple nodes could be made.  Competing with Kubernetes.  Of course
> at that level things are not trivial anymore.

Just thinking about making something on the level of Kubernetes makes
me want to hide under a desk, but that is certainly more in line with
the subject of this email thread. :)

So who's going to start selling Guix Enterprise subscriptions?  It
would be a lot of fun.  You could have Guix Solution Architects and
other fun corporate titles!

- Dave

Re: [EXT] Unable to reconfigure guix system (wrong type to apply)

[Thompson, David]

Hi Luis,

On Tue, Aug 30, 2022 at 9:32 AM Luis Felipe
 wrote:
>
> But now I'm getting the following error when I try to reconfigure the system:
>
> ★★
> sudo guix system reconfigure my-system.scm
>
>
> Backtrace:
>   16 (primitive-load "/home/yo/.config/guix/current/bin/guix")
> In guix/ui.scm:
>2263:7 15 (run-guix . _)
>   2226:10 14 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/status.scm:
> 835:3 12 (_)
> 815:4 11 (call-with-status-report _ _)
> In guix/scripts/system.scm:
>1274:4 10 (_)
> In ice-9/boot-9.scm:
>   1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/store.scm:
>659:37  8 (thunk)
>1298:8  7 (call-with-build-handler # …)
>   2168:25  6 (run-with-store # …)
> In guix/scripts/system.scm:
>   1298:15  5 (_ _)
> 829:5  4 (perform-action reconfigure #< name: #f format:…> …)
> In guix/scripts/system/reconfigure.scm:
> 375:4  3 (check-forward-update _ #:current-channels _)
> 375:4  2 (check-forward-update _ #:current-channels _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Wrong type to apply: (#< name: guix url: 
> "https://git.savannah.gnu.org/git/guix.git"; branch: "master" commit: 
> "3f171587bc6a47bb056f3e699e17e05f5832aea5" introduction: #f location: 
> ((filename . "gnu/services.scm") (line . 466) (column . 5))>)
> ★★
>
> Is this a problem in Guix's channel definition?

This looks like the problem described in
https://issues.guix.gnu.org/issue/57480 in which the regression was
identified and reverted.  Try 'guix pull' again and see if your system
reconfigure works this time.

Hope this helps,

- Dave

Re: [EXT] Re: Enterprise Guix Hosting?

[Thompson, David]

On Wed, Aug 31, 2022 at 2:40 AM Ricardo Wurmus  wrote:
>
> Another thing that seems to be missing is a way to supervise and manage
> running containers.  I use a shepherd instance for this with
> container-specific actions like this:

Hey that's a real nice starting point for a container management tool!
 So maybe there should be a system service to manage containers and
then a 'docker compose'-like tool for declaratively specifying
containers and their network bridging configuration that is a client
of the service?

- Dave

Re: Enterprise Guix Hosting?

[Thompson, David]

Hi Ricardo,

On Fri, Aug 26, 2022 at 3:43 AM Ricardo Wurmus  wrote:
>
>
> Hi Yasu
>
> > Our idea is at the coop is that we want to develop software
> > development acceleration tools, and a major part would be
> > container-less software provisioning so that composition would not
> > mean more and more layers of technical debt...
>
> Don’t discount containers too soon.  Guix has “guix system container”,
> which spins up lightweight Guix System containers that share /gnu/store.
> You only need to set up a bridge interface on the host and create a
> network device pair and move one end into the container’s net namespace.

I thought for sure that 'guix system container' would be something
people would love, but it doesn't seem to get much use!  Having all
containers share the store eliminates several problems that come with
Docker's primitive layer approach.  When I realized all we had to do
was bind mount store items into the container I couldn't believe it
was so simple.

> You can do containers and compose them without layers upon layers of
> file system blobs.  The reasons why this is not commonly done on
> existing commercial platforms:
>
> - container images are often provided from different origins, so there
>   is no trust and thus no way to have them share the same files or
>   common packages
>
> - without reproducible builds trust cannot be established
>
> - container images are erroneously considered a requirement for
>   isolation, but it is not actually required to use them even in the
>   presence of an unshared mount namespace.

All true.  "Container" has come to mean the image more than the
execution environment, so Guix containers not being based on disk
images makes them not fit in.

> Using a shared /gnu/store as a big cache for all containers can be a
> real asset.  We can learn lessons from the HPC experience here.

What might have a positive impact is if Guix had an answer to 'docker
compose'.  Most of the pieces are there already.  Such a tool could be
combined with 'guix shell' so you could get all the tools needed for
local development *and* automatically start any necessary daemons,
like database servers, in isolated containers.

- Dave

Re: “Managing Servers with GNU Guix: A Tutorial”

[Thompson, David]

Hi Hartmut,

On Tue, Nov 5, 2019 at 3:09 AM Hartmut Goebel
 wrote:
>
> Am 04.11.19 um 15:36 schrieb Ludovic Courtès:
> > Jakob wrote a great tutorial on how to use ‘guix deploy’ to deploy Guix
> > System to one machine or to several virtual private servers (VPSs):
> >
> >   https://guix.gnu.org/blog/2019/managing-servers-with-gnu-guix-a-tutorial/
>
> Great tutorial! Thanks.
>
> On questions: For the first example: Does guix installed on the manged
> host need to be up-todate? Or will the update be done as part of the
> "operating system closure", which is send to the managed host?
>
> I spotted a minor error/typo, which is a tiny bit confusing for newbies:
> In the first example it reads "|(define os …" whereas in the text below
> "%system" is referenced. (Also ||"/home/alyssa/.ssh/server_key" is a bit
> misleading. I suggest "…/key-for-server")|

Thanks for catching those issues that I missed while editing. I'll try
to fix them today!

- Dave

Re: Building "special" binary bundles (i.e. not using guix pack)

[Thompson, David]

On Mon, Nov 4, 2019 at 9:53 AM Thompson, David  wrote:
>
> Sure, I could just grab a bunch of pre-built stuff from Debian's
> repositories and stuff it in a tarball, but I want to use Guix in
> order to have a reproducible toolchain and because this bundle will
> include several Guile libraries that would be a pain to build without
> Guix.  I want to be able to say "Here, use this convenient binary
> bundle.  If you're curious what's   Furthermore, I really want to see
> Guix fill this particular niche because it could lead to an
> Appimage-like feature in Guix itself.

Oops!  Looks like I accidentally deleted some text here.  The part in
quotes should read:

"Here, use this convenient binary bundle.  If you're curious what's
inside and how it is made, here is the code used to build it."

Yours in neverending typos,

- Dave

Building "special" binary bundles (i.e. not using guix pack)

[Thompson, David]

Hello all,

First, context and parameters:

I have a project for which I'd like to release pre-built binaries that
will "just work" on major FHS-based distributions such as Ubuntu and
Fedora.  As far as native executables go, this bundle requires Guile
and roughly a dozen C shared libraries.  The goal is to compile guile
and the additional libraries in such a way that there is *no* runpath
information embedded in the ELF files.  The goal is *not* to ship a
complete graph, down to glibc, like 'guix pack' would do.  Instead,
I'm taking the more traditional approach of bundling only the
libraries that I cannot assume will be on the user's system (say,
libvorbis) and assuming that others (like libx11) will be there.
Everything included in the bundle needs to be built against a glibc
version that is the most compatible across other distros right now.
I believe that version is 2.27.

Sure, I could just grab a bunch of pre-built stuff from Debian's
repositories and stuff it in a tarball, but I want to use Guix in
order to have a reproducible toolchain and because this bundle will
include several Guile libraries that would be a pain to build without
Guix.  I want to be able to say "Here, use this convenient binary
bundle.  If you're curious what's   Furthermore, I really want to see
Guix fill this particular niche because it could lead to an
Appimage-like feature in Guix itself.

Now, onto my issues.  I have experimented with a few different
approaches for building the bundle but haven't had success with any:

1) Using Guix packages as-is and using patchelf to strip runpath
information.  This honestly came very close to working for me, and I
think I could probably make it work with a little more debugging, but
it's very hacky and unsatisfying.  The biggest issue is that because
Guix builds everything with glibc 2.29 these days, I have to bundle
glibc 2.29, *including the dynamic linker* so I can actually run
Guile.  I sent a bundle to a friend to test and it didn't work, but
they couldn't tell me what the backtrace was because their system
locales were incompatible and thus Guile couldn't failed to print a
backtrace.  I could ship glibc 2.29 locales in the bundle, too, but
that was the last straw for me.  How much more stuff would I have to
shove into this bundle before it worked reliably? When the easy but
hacky solution starts to lose the easy part, it's time to move on.

2) Use a special GCC toolchain sans ld-wrapper and with a few other
tweaks to keep runpaths away.  This seemed promising but, because
there's no runpaths, configure scripts would fail. Although the
scripts could compile test programs, running those test programs
failed because they were unable to find libraries.  Setting
LD_LIBRARY_PATH doesn't work because then the configure script doesn't
work at all because now binaries built against glibc 2.29 are trying
to link against libraries built against 2.27 and everything explodes.
I was able to hack around this for a little while by passing
"LDFLAGS=-static-libgcc" to configure scripts, but eventually I ran
into a configure script that linked against more than libgcc in its
test programs (if you're curious, libvorbis builds a program linked
against libogg when running ./configure) and I was out of luck.  When
autoconf-generated configure scripts cannot run test executables, they
say something to effect of "are you cross-compiling? use the --host
flag".  So, I got to thinking: Should I reframe this as a
cross-compilation?  It certainly seems like I'm dealing with a special
target system.  Which leads me to...

3) Performing a cross-build.  It seems a little weird to cross-compile
for x86_64 on a machine that is natively x86_64, but I suppose it
makes sense because I'm targeting a foreign type of system.  However,
I was unable to get this to work because Guix was trying to build tons
of stuff from source, from gcc to Linux headers.  I assumed I was
doing something wrong and aborted this process.  I'm not so good at
navigating the cross-compilation code in Guix right now.

So, now I'd like to ask: Does anyone which approach I *should* be
taking here?  Does anyone have any experience they can offer?  Carl
Dong shared his approach to building bitcoin using Guix with me (see:
https://github.com/dongcarl/bitcoin-guix/blob/master/packages.scm)
which enabled me to try out approach #2 and #3, but it doesn't seem
like an exact fit, though I could just be misunderstanding something.
My hunch is that #3 is the correct approach, but it's unclear how I
setup the proper cross-compilation environment with my special gcc
toolchain.

I hope I've explained myself somewhat clearly.  Any guidance
appreciated!  If you've read this far, thank you!

- Dave

Re: Joint statement on the GNU Project

[Thompson, David]

Stop sending these incoherent essay length rants to the Guix mailing
lists.  You've made your point dozens of times.  Thanks in advance.

- Dave

Re: “Guix Profiles in Practice”

[Thompson, David]

On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> Practice”:
>
>   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
>
> A great discussion on the benefits of manifests and on ways to manage
> several profiles!

Great article!

I spotted a typo in the first paragraph: "on a same system" should be
"on the same system."

The section below reminds me about some unfinished work from back when
I wrote 'guix environment':

Eventually, we set to work on that project again, so we run guix
environment -m manifest.scm. But now we have to wait for Guix to
build and install stuff!

This is indeed a frustration.  It takes a bunch of extra switches to
have 'guix environment' create a profile and even I don't bother with
it, just opting to build a new profile if I've upgraded guix since the
last time I worked on the project.  This gets me into trouble when I
upgrade guix and decide that I want to work on the project while I'm
somewhere with no network connection or too slow of a connection to
download everything in a reasonable time.  It has happened to me
multiple times while commuting by train.

'guix environment' is a very composable command, and it's not clear to
me how I would add the stuff I want onto it and it's even less clear
if it's a good idea.  Probably not.  So, I wonder if maybe a new
subcommand, say 'guix develop', could address this common development
use-case while allowing 'guix environment' to continue being the swiss
army knife that it is.  Some simple naming conventions could make this
tool "just work."  Running 'guix develop' would check for a profile
symlink with some canonical name, for example '.guix-develop-profile'.
If it exists, it applies the environment variables and spawns a
subshell.  If it doesn't exist, it looks for a 'develop.scm' file
(canonical name TBD), builds the profile, symlinks it to
'.guix-develop-profile', and then does the prior steps.  The tool
would provide a mechanism to update, etc. and it could even be
expanded later to spawn services like databases.

- Dave

Re: GNU Guix 1.0.0 released

[Thompson, David]

Congrats everyone! What an accomplishment!

- Dave

Re: MTP & Guix

[Thompson, David]

On Sat, Jun 23, 2018 at 2:02 PM, Pierre Neidhardt  wrote:
> Personally I'd prefer that it'd be mounted just like any other folder so that 
> I
> can browse with Emacs for instance.

Yeah, that's what I'm after as well. There's some missing integration here.

- Dave

Re: MTP & Guix

[Thompson, David]

Hi Pierre,

On Sat, Jun 23, 2018 at 10:22 AM, Pierre Neidhardt
 wrote:
>
> Hi there!
>
> Do you people have recommendations when it comes to MTP (file sharing
> with mobile devices) support on GuixSD?
>
> Ideally I'd like something as straightforward as an auto-mounted folder
> which I can browse with my favourite file browser.
>
> I see Guix offers a few options:
>
> - jmtpgs
> - gmtp
> - libmtp
>
> What's your setup, people?

I've been using gmtp for the time being, which works but I don't like
it very much. I'm not sure what to do in order to make the GNOME file
manager auto-mount MTP devices like I'm used to in mainstream distros.
Does anybody else have this working?

- Dave

Re: Cannot build guile-chickadee.

[Thompson, David]

Hey Ricardo,

On Wed, Jun 20, 2018 at 5:27 AM, Ricardo Wurmus  wrote:
>
> Ricardo Wurmus  writes:
>
>>> Yes, last time I tried I had a similar issue: this is because you need
>>> the latest guile-sdl2 and guile-opengl.
>>
>> There does not seem to be a more recent guile-opengl.  I have added
>> guile-sdl2-devel, which is built from the latest git commit.
>>
>> I also updated guile-chickadee to use the latest version from git.
>> Unfortunately, it still won’t build.
>>
>>> As I mentioned in an e-mail I've sent recently, I'd like to update the 2
>>> package definitions in Guix and add Chickadee to the Guix repo.
>>> What do you think?
>>
>> I’d prefer to use only released versions in Guix unless it cannot be
>> avoided to use development versions.
>
> Turns out that the Makefile of guile-sdl2 needed to be patched.  After
> the patch Chickadee can be built with the release tarball.
>
> I’ll push the package definition shortly.

Could you tell me the commit id when you push it? I'd like to just
sort out the issues you were having and make new releases of
guile-sdl2 and chickadee so that Guix can have clean packages with no
hackery involved.

Thanks,

- Dave

Re: Cannot build guile-chickadee.

[Thompson, David]

On Wed, Jun 20, 2018 at 8:37 AM, Ricardo Wurmus  wrote:
>
> Hey Dave,
>
>>> Turns out that the Makefile of guile-sdl2 needed to be patched.  After
>>> the patch Chickadee can be built with the release tarball.
>>>
>>> I’ll push the package definition shortly.
>>
>> Could you tell me the commit id when you push it? I'd like to just
>> sort out the issues you were having and make new releases of
>> guile-sdl2 and chickadee so that Guix can have clean packages with no
>> hackery involved.
>
> I’ve pushed guile-chickadee with commit
> 00fca594da4c63a976e1c67ec3caab47f2a38d87.  The patch to guile-sdl2 is in
> commit e5b77ccfe861545a61f6c6355f5c9fb712bc4894.  After that I noticed
> that the package might also need a build phase to fix the installation
> location:
>
> --8<---cut here---start->8---
> diff --git a/gnu/packages/game-development.scm 
> b/gnu/packages/game-development.scm
> index b428fa77f..f8c6583f9 100644
> --- a/gnu/packages/game-development.scm
> +++ b/gnu/packages/game-development.scm
> @@ -1248,7 +1248,16 @@ a 2D editor view.")
>  "10qx0ha5gsayybd186r1my7vc7rf5fbzp9jvmc4xg9a8wz8rqhah"
>  (build-system gnu-build-system)
>  (arguments
> - '(#:make-flags '("GUILE_AUTO_COMPILE=0")))
> + '(#:make-flags '("GUILE_AUTO_COMPILE=0")
> +   #:phases
> +   (modify-phases %standard-phases
> + (add-after 'configure 'patch-makefile
> +   (lambda _
> + ;; Install compiled Guile files in the expected place.
> + (substitute* '("Makefile")
> +   (("^godir = .*$")
> +"godir = $(moddir)\n"))
> + #t)
>  (propagated-inputs
>   `(("guile-opengl" ,guile-opengl)
> ("guile-sdl2" ,guile-sdl2)))
> --8<---cut here---end--->8---

Okay, I will make this change upstream.

> Unfortunately, I still cannot use it as the example fails with OpenGL
> errors, e.g.:
>
> chickadee/window.scm:56:21: In procedure open-window:
> Throw to key `sdl-error' with args `("make-window" "failed to create 
> window: ~A" "Couldn't find matching GLX visual")'.
>
> So I picked the first of the visuals that glxinfo outputs:
>
> export SDL_VIDEO_X11_VISUALID=0x022
>
> But then I get another error:
>
> chickadee/window.scm:60:21: In procedure open-window:
> Throw to key `sdl-error' with args `("make-gl-context" "failed to create 
> OpenGL context: ~A" "Could not create GL context")'.
>
> And that’s probably because something somewhere decides that the
> graphics chip in my Librem 13 does not support OpenGL 3.3(?), even
> though glxinfo says this:
>
> --8<---cut here---start->8---
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Intel Open Source Technology Center (0x8086)
> Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)  (0x1916)
> Version: 17.3.8
> Accelerated: yes
> Video memory: 3072MB
> Unified memory: yes
> Preferred profile: core (0x1)
> Max core profile version: 4.5
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.2
> …
> OpenGL vendor string: Intel Open Source Technology Center
> OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
> OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.3.8
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> --8<---cut here---end--->8---
>
> Not sure if this is a problem with my setup here.

Hmm, there's no problem with your setup. Your GPU supports a higher
version of OpenGL that mine does so it should just work. I'll let you
know if I can find anything that might resolve this issue.  SDL is
being less than helpful with its error message.

Thanks,

- Dave

Re: How do I check out a package w/o installing it?

[Thompson, David]

On Mon, Jan 29, 2018 at 7:47 PM,   wrote:
>
> So 'guix package -i znc' implicitly adds man-db and info-reader.
>
> Maybe 'guix environment --add-hoc znc' should do that too?

Sorry, that's not quite right.  Running 'guix package -i znc' will
install znc and *nothing* else. Only by additionally installing man-db
to your profile will you have MANPATH configured properly.  'guix
package' and 'guix environment' are consistent with each other since
they both use the same underlying profile management code.

Hope this clears things up further,

- Dave

Re: How do I check out a package w/o installing it?

[Thompson, David]

On Mon, Jan 29, 2018 at 2:20 PM, Arun Isaac  wrote:
> George myglc2 Clemmer  writes:
>
>> I tried to use 'guix environment' to check out znc this way ...
>>
>> guix environment --ad-hoc znc -- emacs -nw
>>
>> the znc man is unavailable ...
>
> I have been wondering the same. It would be nice if at least the man and
> info documentation was available somehow. What needs to be done in this
> regard?

If you want to use 'man', include the man-db package in your
environment. If you want to use 'info', include the info-reader
package (I think).

To be more general, there isn't any "magic" here.  The znc package
includes man pages in its output directory, but 'man' won't know about
it unless it's on $MANPATH.  In order to make Guix set the proper
MANPATH, you need to include man-db because that package is the one
that defines the native search path for MANPATH.  Check out the man-db
package recipe in gnu/packages/man.scm to see how we encode these
details.

Hope this helps,

- Dave

Re: Generating Amazon Machine Images from Guix?

[Thompson, David]

Hey Ricardo,

On Thu, Jan 25, 2018 at 8:01 AM, Ricardo Wurmus
 wrote:
> Hi Guix,
>
> I may need to provide Amazon Machine Images (AMIs) allowing the
> execution of a Guix package on the Amazon compute services.
>
> There only seems to be a very convoluted way to produce AMIs from raw
> virtual machine images[1], so I wonder if we could generate AMIs
> directly with Guix.
>
> Has anyone of you played with this successfully?
>
> [1]: https://www.wavether.com/2016/11/import-qcow2-images-into-aws

I'm very interested in this, too, but haven't followed through with
writing a script to do it.  NixOps works on EC2 so I looked into how
they do it, only to find that the NixOS developers generate a public
base AMI whose id is stored in the NixOps code. Not the solution I was
expecting.  So I found the nixpkgs script that generates the base
NixOS AMIs. Maybe reading it will help you:

https://github.com/NixOS/nixpkgs/blob/master/nixos/maintainers/scripts/ec2/create-amis.sh

- Dave

Re: openssh installed, but ssh-daemon not starting

[Thompson, David]

Hello Marco,

On Fri, Nov 10, 2017 at 3:16 AM, Marco van Hulten  wrote:
> ```
> 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?

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.

Hope this helps,

- Dave

Re: What about dependency resolution à la apt?

[Thompson, David]

Hi Tobias,

On Thu, Mar 16, 2017 at 4:28 PM, Tobias Geerinckx-Rice  wrote:
> Amirouche,
>
> On 16/03/17 19:52, Amirouche wrote:
>> Héllo,
>
> Hi!
>
> I'm not the most technically qualified person to answer this, nor the
> most articulate, but I'm mainly curious and slightly puzzled as to why
> this question keeps popping up. I hope others will join in, since I fear
> this hints at some fundamental misunderstandings about Guix that might
> hurt world d^W^W adoption.

A big +1 from me.  I wanted to write something similar but you summed
it up better than I would have.  Thanks!

- Dave

Re: string-append plus package

[Thompson, David]

On Thu, Dec 8, 2016 at 12:46 PM, Hartmut Goebel
 wrote:
> Am 08.12.2016 um 18:28 schrieb Thompson, David:
>> This isn't a bug.  string-append is a procedure provided by Guile and
>> it only works on strings.
>
> I don't care whether this is a bug or not. I need to get the package's
> directory. And i works when using in a package definition.

Apologies Hartmut, I misread this as being sent to bug-guix.

- Dave

Re: string-append plus package

[Thompson, David]

On Thu, Dec 8, 2016 at 12:01 PM, Hartmut Goebel
 wrote:
> Hi,
>
> I'm confused about string-append working inconsistently:
>
> In package definitions, I'm used to write '(string-append PKG "…")'. But
> when I use this for defining a service, I get an error:
>
> In procedure string-append: Wrong type (expecting string): # nginx@1.11.6 gnu/packages/web.scm:124 42449c0>
>
> What is going on here?
>
> Here is the service-definition I use:
>
>  (nginx-service #:vhost-list
>(list (nginx-vhost-configuration
>   (root (string-append nginx "/share/nginx/html"))
>   (https-port #f)
>   (ssl-certificate #f)
>   (ssl-certificate-key #f

This isn't a bug.  string-append is a procedure provided by Guile and
it only works on strings.

- Dave

Re: guix with guile-next

[Thompson, David]

On Fri, Oct 7, 2016 at 12:19 PM, Catonano  wrote:
> If I do
>
> $ guix environment --ad-hoc guix guile
> $ guile
>> (use-modules (guix http-client))
>
> it's ok.
>
> If I do
>
> $ guix environment --ad-hoc guix guile-next ;; <-- note the "-next"
> $ guile
>> (use-modules (guix http-client))
>
> Then there is no code for module http-client

This is because Guix is built with Guile 2.0, not Guile 2.1.  You need
to make a variant of the guix package that uses guile-next.

- Dave

Re: "--pure" won't work

[Thompson, David]

On Tue, Oct 4, 2016 at 4:42 PM, Catonano  wrote:
> In exploring Culturia, here
>
> https://github.com/amirouche/Culturia/
>
> I reach this line
>
>
> guix environment --ad-hoc --pure guile-next
>
>
> what happens is this (I'm not on Fedora anymore but rather on Ubuntu 16.04)
>
>
> Command 'lesspipe' is available in the following places
>  * /bin/lesspipe
>  * /usr/bin/lesspipe
> The command could not be located because '/usr/bin:/bin' is not included in
> the PATH environment variable.
> lesspipe: command not found
> Command 'dircolors' is available in '/usr/bin/dircolors'
> The command could not be located because '/usr/bin' is not included in the
> PATH environment variable.
> dircolors: command not found
> Command 'ls' is available in '/bin/ls'
> The command could not be located because '/bin' is not included in the PATH
> environment variable.
> ls: command not found
>
>
>
> Without the "--pure" it works like a charm
>
> Is this normal ? Or is there anything wrong ?

Guix isn't doing any of this, your shell is.  Check your .bashrc or
the equivalent file for whatever shell you use.

- Dave

Re: which of the two ArchLinux PKGBUILDs is better ? -- guix on Arch su errors

[Thompson, David]

On Wed, Sep 7, 2016 at 5:49 AM,   wrote:
>
>> ArchLinux installers of guix should be aware that the standard size of
>> /tmp on a 4 GB computer is too small for a full install of guix.
>>
>> Please enlarge your swap file and resize /tmp to like 20 GB, else
>> you will repeatedly break during
>>
>> guix package -i hello
>>
>> After those mods I successfully ran guix on Manjaro (Arch derivate).
>
> What exactly goes wrong when /tmp is less that 4 GB? There are a handful
> of packages that require more than 4 GB of storage while building, but I
> don't believe any of them are required to build hello.
>
>
> after
> guix package -i hello
>
> there was 3 hours of building on a desktop machine. looked like a
> make world
> build was going on.
>
> I wonder why, since on a guixSD it installing hello was much faster.

You don't have substitutes enabled.  Enable them.  See the manual for details.

- Dave

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 11:55 AM, Thompson, David
 wrote:

> I'd also like to point out that you can already use 'guix gc
> --referrers /gnu/store/-foo-1.0' to find out which store items
> depend on the one passed in.

I realize this is redundant with what I wrote above.  Hasty writing...
Sorry for the noise.

- Dave

Re: Reverse dependencies

[Thompson, David]

On Fri, Aug 12, 2016 at 5:27 AM, Vincent Legoll
 wrote:
> Hello,
>
>> I think you mean inkscape is pulled when you build the system.  Then you
>> will not find it like this.  It is needed to build the fancy grub image,
>> and it is "pulled" by the system building code (specifically by
>> 'svg->png' procedure in (gnu system grub) module).  If you want to avoid
>> it, you can specify an "empty" theme for example:
>>
>>   (bootloader (grub-configuration (device "/dev/sda")
>>   (theme (grub-theme
>
> Thanks for that information, that was what I wanted to know (both the where
> does it come from, and the how to avoid it being pulled in)
>
> I think a "guix revdep $PKG" should be a valuable tool

While we can certainly make learning about this stuff easier, but
making a new subcommand with a cryptic name just for this purpose
wouldn't be a very good UI.

> it should work:
> 1 - globally in the list of defined packages
> 2 - locally in the list of packages from the current user's profile
> 3 - systemly, from the list of installed packages in the system profile

What do you define "dependencies" to be?  Using your situation as an
example, inkscape is *not* a dependency of the built system, but it is
a dependency of the *derivation* that builds the system.  Using
profiles wouldn't work because profiles may contain references to
store items that the current Guix has no knowledge of.  package
expression -> built package is a one way transformation.  What you can
do, however, is use 'guix gc --referrers' to get a list of store items
that refer to the store item passed in.  This still doesn't help you
in the inkscape case because the built system has no reference to
inkscape, it was just used in the build script.

I think the "right thing" here is to add features to 'guix graph' so
that it can make a referrer graph using the Scheme package graph.
'guix system' has graph subcommands already, so we could add one that
produces a full package dependency graph which would show you who
depends on inkscape.

Any volunteers? :)

I'd also like to point out that you can already use 'guix gc
--referrers /gnu/store/-foo-1.0' to find out which store items
depend on the one passed in.

- Dave

Re: recordmydesktop doesn't work with sound.

[Thompson, David]

Hi Dmitry,

On Thu, Jul 21, 2016 at 3:58 PM, Dmitry Nikolaev  wrote:
> Hi. I wanted to make a screencast about GuixSD, but recordmydesktop couldn't
> record sound.

I don't know the answer to your question, unfortunately, but I wanted
to recommend another tool as a workaround for now: Open Broadcaster
Software.  Install with 'guix package -i obs'.  I like it quite a bit.

- Dave

Re: AUR for GuixSD (was: GuixSD on arm (ng0))

[Thompson, David]

On Wed, Jul 6, 2016 at 8:15 AM, David Craven  wrote:
> I was under the impression that that was one of the statements Jookia
> made. You calling it the gnu system reinforced that impression. Sorry
> if I misunderstood. Glad to hear that's not the case. :-) Big
> discussion over nothing then =P

I recall Jookia interacting in #guix and possibly on the mailing
lists, too.  IIRC, they got frustrated with our project (I think with
how we do patch review) and stopped participating.  Unfortunately, it
seems they drew a number of false conclusions about our goals
before/after they left.  From reading the threads about Guix on reddit
and elsewhere I see that there's actually a few people (that aren't
contributors AFAICT) that leave numerous comments about how Guix
works, socially and technically.  They often get it wrong, and I often
don't have the time to correct them.

Anyway, thanks for writing to this list and getting answers to your
questions from the core developers.

- Dave

Re: chicken scheme

[Thompson, David]

On Fri, Jul 1, 2016 at 8:11 AM, John J Foerch  wrote:

> First a question about /var/lib, and please excuse the newbie question.
> If chicken extensions were installed to /var/lib, wouldn't that go
> against the spirit of guix of keeping every program isolated?  Isn't
> /var/lib global state?

Yes, but this program is not Guix. It's a completely separate package
manager, and it should work as intended.

- Dave

Re: 'guix system vm' questions

[Thompson, David]

On Wed, Jun 29, 2016 at 2:57 AM, myglc2  wrote:
> I have a headless server running Guix/Debian 8.3 on which I would like
> to run some guix vms. So far, I have a script (see mkvm.sh, attached)
> that runs a single vm. It has some issues:
>
> 1) lsh-service hangs waiting for keystrokes on the QEMU console

LSH needs to be initialized with a key on first boot, which is why you
need to type to create entropy.  This sucks for automation, so I would
recommend OpenSSH instead, but we don't have an openssh-service yet.

> 2) passwords need to be set in the QEMU console

What is the QEMU console?  If you mean user passwords, it is possible
to specify the hashed password in a user account in your OS config
file, IIRC.

> 3) on the vm, 'guix package -i' throws an error, e.g.,
>
>(on the console)
>v1 login: u1
>password: 
>$ guix package -i
>accepted connection from pid 390, user u1
>guix package: error: build failed: changing ownership of '/path/store': 
> Read-only file system

The VMs created with 'guix system vm' are immutable.  Copying the
result of 'guix system vm-image' is probably what you want.

> 4) I can't log in to the vm like I expected, e.g. 'ssh u1@10.0.2.15'
>times out

Sounds like you have a QEMU networking issue to figure out.  Doesn't
seem related to Guix at all.

> 5) I would like to have the user 'u1' share read/write access to the
>$HOME directory and be able to use $HOME/.ssh credentials

Once you have a writable disk image, you can just write files to the
home directory as you please.  GuixSD does not manage files in
stateful directories like $HOME.

HTH,

- Dave

Using source code URIs with HTTP basic auth

[Thompson, David]

I'm trying to download a source tarball from a private server that
happens to use HTTP basic auth.  I tried doing the usual
"https://user:passw...@example.com/foo.tar.gz"; but it doesn't seem to
work.  This URI format works just fine when doing authenticated Git
downloads.  Does anyone know what is needed to make this work?
AFAICT, the code in (guix build download) does indeed carry along the
"userinfo" as it manipulates the URI.

Thanks,

- Dave

Re: General Question: Execution of binaries not built for GuixSD

[Thompson, David]

On Wed, Jun 22, 2016 at 9:27 AM, Florian Paul Schmidt
 wrote:
> See the attached file for reference. Put it into a guix checkout under
>
> nonfree/packages/
>
> Does that help as a starting point?

Do the upstream Firefox and/or Thunderbird contain nonfree components?
 If so, please do not promote such software on this list.

I really really really cannot recommend this approach to packaging,
because it goes against one of the core properties of Guix:
reproducibility.  Taking someone else's binary and hacking it until it
works isn't a real solution.  The proper way to do this is to build
binaries from source that are compatible with Guix.

Thanks,

- Dave

Re: General Question: Execution of binaries not built for GuixSD

[Thompson, David]

On Tue, Jun 21, 2016 at 7:21 PM, christoph vogelsberg
 wrote:
> Hello
>
> I have a fresh installation of GuixSD and I'm keen of learning more. I 
> struggle with a concept and don't know how to circumvent best:
>
> Binaries built for ordinary Linux's (as, in my case, Firefox Developer 
> Edition) expect libraries on certain standard pathes which doesn't exist on 
> GuixSD. I found three possibilities that might work:

To be clear, an "ordinary" GNU/Linux system is one which uses the
Filesystem Hierarchy Standard, which GuixSD deliberately does not
conform to.

> * use fakechroot to make my user profile a pseudo root (disadvantage: I have 
> no experience, it seams there is no package for that)
> * create symbolic links (disadvantage: new builts get a new path with a hash 
> value and must be re-linked properly)
> * install a minimal Linux and use Guix instead of GuixSD (disadvantage: this 
> would the point where I had capitulated)
>
> My question: is there an already elabored way, documentation and so on, for 
> this specific problem?

The solution is to build the software from source to produce a binary
that is compatible with GuixSD.  Guix has a GNU Icecat package that
may provide a good base for this.

HTH,

- Dave

Re: Non-privileged daemons and offloading

[Thompson, David]

On Mon, Jun 20, 2016 at 4:05 AM, Ludovic Courtès  wrote:
> The Nix daemon recently switch to user namespaces:
>
>   https://github.com/NixOS/nix/commit/c68e5913c71badc89ff346d1c6948517ba720c93
>
> We could backport this.  However, running builds with UID 0 is
> potentially disruptive: some packages are sensitive to this and behave
> differently under UID 0 (I remember Coreutils’ test suite does.)  Also,
> this patch switches to user namespaces, but not specifically
> _unprivileged_ user namespaces.

It should be possible to create a new user within the container (say,
UID 1000) and map it to a "guixbuild" user on the host system,
avoiding this problem.

- Dave

Re: some code

[Thompson, David]

On Mon, Jun 6, 2016 at 11:05 AM, Catonano  wrote:
> There's a piece of code (in the Emacs build system) I don't understand
>
> In "guix/build-system/emacs.scm" on line 97 there's a call to a function
> called "emacs-build"

That's not a procedure call, actually, because the entire form is
quoted starting on line 95.  This code is generating a Guile script
that will be used by guix-daemon to build an Emacs package.  The
"emacs-build" referenced within is actually the procedure found in
(guix build emacs-build-system).

> Also what's with that "define*" ? Is there a manual page describing it ? I
> couldn't find it

See section 6.9.4.1 of the Guile manual:


http://www.gnu.org/software/guile/manual/html_node/lambda_002a-and-define_002a.html#lambda_002a-and-define_002a

Hope this helps,

- Dave

Re: How to force rebuilding a pacakge?

[Thompson, David]

On Thu, Jun 2, 2016 at 10:14 AM, Hartmut Goebel
 wrote:
> Am 02.06.2016 um 15:03 schrieb Thompson, David:
>> First, why do you think you want to "force rebuild" something?
>
> E.g. to inspect the build log.

See 'guix build --log-file'

- Dave

Re: How to force rebuilding a pacakge?

[Thompson, David]

On Thu, Jun 2, 2016 at 8:57 AM, Hartmut Goebel
 wrote:
> Hi,
>
> I just try (force-) rebuilding some package (python-scikit-learn), I do
> not succeed:
>
> - guix build … simply fetches the package from hydra
> - guix build --no-substitutes … rebuilds an lot of other stuff , e.g.
> fontforge-dist
> - guix build --check … does not provide a meaningful build log
> - guix build --check --log-file … does not provide a meaningful build
> log either
>   guix gc -d /gnu/store/*python-scikit-learn* does not change this
>
> Any help?

You are misundering many things about Guix here.  First, why do you
think you want to "force rebuild" something?  If you've made a change
to a build recipe, then that will naturally change the identity of the
build, thus getting a new build.  If you haven't changed the package
recipe, but want to build *just* that package from source for some
reason, you could try the following hack:

guix environment --search-paths python-scikit-learn
guix build --no-substitutes python-scikit-learn

The first command will fetch all the dependencies for the package,
taking advantage of substitutes.  The second command will then build
python-scikit-learn without substitutes, but it won't build anything
except python-scikit-learn because you just got all the necessary
dependencies with the prior command.  Finally, if the package build is
already present in the store, then you need to use the garbage
collector to remove it.

- Dave

Re: How to remove old (test) builds from store?

[Thompson, David]

On Thu, Jun 2, 2016 at 8:51 AM, Hartmut Goebel
 wrote:
> Am 02.06.2016 um 14:02 schrieb Ludovic Courtès:
>> Alternately (ah ha!):
>>
>>   guix gc -d $(guix build foo)
>
> This would build remove the packages just build, wouldn't it? But I want
> to clean up old test builds
>
> It's not about determinism and not about free disk-space :-) It's just
> about removing stuff which I know is outdated.

Then just run 'guix gc' and it will remove everything that isn't
currently included in a profile.

- Dave

Re: cleaning the store

[Thompson, David]

On Thu, May 26, 2016 at 2:16 PM, Catonano  wrote:
>
> So which profile is pointing to those things ?

'guix gc' will tell you this.

guix gc --referrers /gnu/store/...-cider-x.y.z

- Dave

Re: how to fix the store after using rm to remove packages

[Thompson, David]

On Tue, May 24, 2016 at 5:13 AM, Myles English  wrote:
>
> Hello, I had a problem with a python application and deleted (with rm,
> instead of 'guix package -r') the packages I wanted to rebuild.
>
> Now the store is broken.  I have just started down the guix road so
> don't mind starting again with a clean store.  Or I could try and fix
> the problem.  I haven't found any information on how to start again, but
> have tried fixing it and have got stuck on how to delete derivations.
> Can anyone help please?

Start over.  The store is immutable for a good reason.

- Dave

Re: Question about package environment variables

[Thompson, David]

On Wed, May 18, 2016 at 4:23 PM, Matthew Jordan
 wrote:
>
> Hi David Thompson,
>
> Thanks for your response, guess I'll have to use envstore or or create
> file I can source into my current shell session.

Why would you want this?  I don't understand.

- Dave

Re: Question about package environment variables

[Thompson, David]

On Wed, May 18, 2016 at 2:24 PM, Matthew Jordan
 wrote:
> Good Day everyone,
>
> I would like to know is it possible to set any environment variable to
> any value from guix package.  The usecase I am thinking of is for a
> project. Let's say you had a guix package file to automate and document
> project dependencies.
>
> Let's say I wanted to declare a variable in project package file so that
> "eval `guix environment --search-paths ...`" would set up the
> environment with the needed variables plus the ones I wanted.
>
> Example environment variable;
>
> export MSG='Hello world!'

See the 'native-search-paths' field of package objects.  From
environment variables that aren't search paths, like the above $MSG,
those have nothing to do with packages so they wouldn't need to use
anything from Guix at all.

Also, why the use of 'eval' here?  Just 'guix environment my-package'
would spawn a shell (or any program you wanted) with access to the
package's dependencies.

I use this all the time in my personal projects, where I keep a
'guix.scm' file in the root of the source tree that I can make
environment's from like so:

guix environment -l guix.scm

Additionally, I can also build and/or install development snapshots:

guix build -f guix.scm
guix package -f guix.scm

Here's a full example:

https://git.dthompson.us/haunt.git/blob/HEAD:/guix.scm

Hope this helps!

- Dave

Re: environment --container not working after upgrading Ubuntu

[Thompson, David]

On Sat, Apr 30, 2016 at 8:17 PM, Ben Woodcroft  wrote:
> Hi,
>
> I upgraded to the just-released Ubuntu Xenial yesterday, seems nice and
> snappy. The only issue I've had with it so far is that 'guix environment
> --container' run from a git checkout doesn't work. There's no error given,
> it simply exits:
>
> $ ./pre-inst-env guix environment --container coreutils
> [..]
> $ echo $?
> 1
>
> Any ideas on debugging this? I tried 'make clean; make'. My daemon is a
> little out of date, but it was working before the upgrade.

Could you prefix that command with 'strace -f -o /tmp/container.log'
and send the generated log file?  This way we'll see the system calls
that are failing.

Thanks,

- Dave

Re: guix environment --ad-hoc should work the other way round

[Thompson, David]

On Sun, Apr 24, 2016 at 8:09 AM, Hartmut Goebel
 wrote:
> Hi,
>
> being quite new to guix and playing around with `guix environment`. I
> find it confusing and IMHO it is working the wrong way round:
>
> I'd expect it to get me an environment where the specified packages are
> installed. So I could easily test if a new version of a program works as
> expected. Instead I get an environment where the tools for building
> these packages are installed.
>
> What I actually need to type  | What I'd expect to type
> --
> guix env --ad-hoc python-2.7  | guix env python-2.7
> guix env python-2.7 --ad-hoc git  | guix env git --XXX python-2.7
>
> (Where XXX is placeholder for something like --for-building ;-)
>
> So basically I'd expect the meaning for the packages in front of
> `--ad-hock` exchanged with those behind.
>
> Please note that these are two different views on environments: The
> currently implemented view i the one of a developer, who wants to set up
> an environment for building quick. The other view is the one of a user,
> who wants to test packages.
>
> I'm in favor of changing `guix environment` to take the seconds view,
> since I assume, this will be the case uses much more often. (Even given
> that there ought to be no difference between developers and users, as
> most users simply will not even think about something like a
> build-environments.)

I disagree.  One of the main use-cases of 'guix environment' is
including a "guix.scm" file in your project's source code repository
that includes a development package so new developers can run 'guix
environment -l guix.scm' to get all of the dependencies of that
package and start hacking.

I think the current behavior should remain unchanged.

- Dave

Re: Cannot clone repositories over HTTPS with Git

[Thompson, David]

On Wed, Apr 20, 2016 at 5:32 AM, Roel Janssen  wrote:
> Dear Guix,
>
> With the Git provided by GNU Guix, I cannot seem to clone repositories
> over HTTPS:
> fatal: unable to access 'https://github.com/roelj/inklingreader.git/': server 
> certificate verification failed. CAfile: none CRLfile: none
>
> Am I missing a package that provides common CA files?

GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt

This "just works" on GuixSD.

Re: Error testing libarchive during SD installation.

[Thompson, David]

On Thu, Mar 17, 2016 at 6:37 PM, Alex McGrath Kraak  wrote:
> Hi!,
>
> I'm running into an error while trying to install guixsd. the installation
> fails when testing libarchive. "test_format_newc" is the failing test.

This indicates to me that you are building the entire distro from
source.  You probably don't want this, so you should run 'guix pull'
before installing to get the latest version of Guix.  Due to limited
disk space, we can only retain pre-built binaries for a short period
of time, and the binaries for 0.9.0 have been garbage collected by
now.

Hope this helps.

- Dave

Re: gnome unable to remove application

[Thompson, David]

On Tue, Mar 8, 2016 at 8:00 AM,   wrote:
>
> First i remove evince applicattion:
>
> $ guix package -r evince
> nothing to be done

Yes, because evince is *not* in your user profile.

> Later i type the command 'evince', and the command still exists:
>
> $ evince
> evince  evince-previewerevince-thumbnailer
> $ evince

Yes, because evince is in the *system profile*, which is distinct from
your user profile.  Remove the GNOME package and reconfigure.  If you
just want to remove evince, then you'll want to create a variant of
the GNOME package and reconfigure with that instead.

- Dave

Re: Screenshot GuixSD Gnome

[Thompson, David]

On Mon, Feb 22, 2016 at 9:00 AM, Daniel Pimentel  wrote:
> Guixs,
>
> Attach a file with a screenshot using Gnome-Shell and GuixSD. I believe that
> Guix/GuixSD site should show a Gnome screenshot too. What you thing about
> it? Send more screenshot using Gnome + GuixSD?
>
> Thanks and I sorry (I sent to guix-devel too, I sorry for it.)

I think you forgot the attachment. :)

- Dave

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Thompson, David]

On Thu, Feb 11, 2016 at 5:40 PM, Ludovic Courtès  wrote:
> "Thompson, David"  skribis:
>
>> On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès  wrote:
>>> Christopher Allan Webber  skribis:
>>>
>>>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>>>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>>>> things were fine!
>>>
>>> Indeed.  However, since Haunt ships a command-line tool, we should fix
>>> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
>>> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>>>
>>> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)
>>
>> I don't understand why this would require an upstream fix for what
>> seems to be a Guix-specific quirk.  Could you elaborate?
>
> I think stand-alone commands like ‘haunt’ should ensure that they’ll
> find their modules rather than assume that the user defined
> ‘GUILE_LOAD_PATH’ & co. appropriately.
>
> This is particularly important when users are likely to use exclusively
> the CLI (the same is also true of ‘skribilo’, ‘guix’, ‘herd’, etc.)

Thanks for the explanation, I am convinced and will (eventually) fix
in Haunt and my other Guile applications.  Does this also apply to the
applications dependencies, or just the modules for itself?  If the
former, I'm actually not sure how to do the relevant autotools magic
to make it work.

- Dave

Re: Any clue why $GUILE_LOAD_PATH not propagated with Haunt?

[Thompson, David]

On Wed, Feb 10, 2016 at 9:17 AM, Ludovic Courtès  wrote:
> Christopher Allan Webber  skribis:
>
>> Just for posterity, Dave helped me figure out what was wrong.  I missed
>> putting guile-2.0 in my inputs.  Critical!  Well, once I did that,
>> things were fine!
>
> Indeed.  However, since Haunt ships a command-line tool, we should fix
> the Haunt package in Guix to wrap ‘bin/haunt’ such that the tool has
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly set.
>
> Done in 4ecbf6d.  I think it should be fixed upstream though.  :-)

I don't understand why this would require an upstream fix for what
seems to be a Guix-specific quirk.  Could you elaborate?

> BTW, ‘guix build haunt --with-input=guile=guile-next’ fails at configure
> time (it insists on 2.0.)

Thanks, Ludo.  I noticed that in another project of mine.  I guess I'm
using the wrong autoconf macro to check for the version being greater
than 2.0.x.  I'll have to figure out what the correct thing is.

- Dave

Re: Why is /gnu/store writable by the guixbuild group?

[Thompson, David]

On Fri, Jan 22, 2016 at 9:41 AM, Steven Allen  wrote:
> All,
>
> While the builders run in containers, it still feels like a really bad
> idea. Being able to write to /gnu/store gives one the power to overwrite
> any binary. Furthermore, it makes grsecurity's TPE mad :(.

On GuixSD, /gnu/store is mounted *read-only* and remounted read/write
for the purposes of the daemon only.  So, for any particular build, a
build user can *only* write to their specific output directories and
nothing else.

Note as well that the items in the store are owned by root and cannot
be touched.  The only user that can trash things is the superuser, if
they so choose.

> So, why exactly does the guixbuild group need write access to this
> directory? I'd think that the guix-daemon would be responsible for
> moving finished builds into the store, not the builders themselves.

Builders write directly to their output directories.  In GNU terms,
this is the directory used for './configure --prefix=/gnu/store/foo'.
I don't see an issue with this.

> On a related note, why do all builders use guixbuild as their primary
> group. It would be safer to make guixbuild a supplementary group and
> give every build user it's own primary group. This way, any group
> writable files that the build process happens to create will not be
> writable by all build users.

In the long term, it would be cool to just use user namespaces instead
of build users, but this would cause issues for a number of Guix users
(and some of our donated build slaves) who do not have a new enough
kernel.  Some day.

- Dave

Re: Deleting services from %desktop-services in operating system declaration

[Thompson, David]

On Wed, Jan 20, 2016 at 7:42 AM,   wrote:
> Hi
>
> I have trouble getting the syntax right to delete avahi and wicd from my
> config.scm.
>
> This did not work (inspecting with the REPL):
>   (services (cons* (tor-service) %desktop-services))
>   (modify-services (alist-delete
>  wicd-service
>  %desktop-services))
>   (modify-services (alist-delete
>  avahi-service
>  %desktop-services))
>
> Neither this:
>   (services (cons* (tor-service) %desktop-services))
>   (modify-services (alist-delete
>  wicd-service
>  avahi-service
>  %desktop-services))
>
> The manual does not yet have examples of how to delete one or more entries
> from the %base-services or other lists.
>
> Help would be appreciated :)

First of all, %desktop-services is *not* an alist, so using
alist-delete certainly won't work.  Second, modify-services is
*syntax*, so the form (alist-delete ...) is surely the wrong syntax.

Below is the docstring for modify-services:

Modify the services listed in SERVICES according to CLAUSES.  Each clause
must have the form:

  (TYPE VARIABLE => BODY)

where TYPE is a service type, such as 'guix-service-type', and VARIABLE is an
identifier that is bound within BODY to the value of the service of that
TYPE.  Consider this example:

  (modify-services %base-services
(guix-service-type config =>
   (guix-configuration
(inherit config)
(use-substitutes? #f)
(extra-options '(\"--gc-keep-derivations\"
(mingetty-service-type config =>
   (mingetty-configuration
(inherit config)
(motd (plain-file \"motd\" \"Hi there!\")

It changes the configuration of the GUIX-SERVICE-TYPE instance, and that of
all the MINGETTY-SERVICE-TYPE instances.

This is a shorthand for (map (lambda (svc) ...) %base-services).



Hopefully that provides enough of an example for you!  You can
retrieve the documentation associated with an object at the Guile
REPL.  Here's how you'd get this one:

$ ./pre-inst-env guile
GNU Guile 2.0.11
Copyright (C) 1995-2014 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use (gnu services)
scheme@(guile-user)> ,describe modify-services

- Dave

Re: question re. installing software & init system

[Thompson, David]

On Fri, Jan 1, 2016 at 12:52 PM, Miles Fidelman
 wrote:
> Thanks!  Some follow-ups inline, below
>
>
> On 12/31/15 5:41 PM, Thompson, David wrote:
>>
>>> Several specific questions:
>>>
>>> The recent PPT presentation on GUIX (to Inria) implies that packaging can
>>> be
>>> as simple as writing a config file that tells GUIX to do a "config; make;
>>> make install" on a source file built with the GNU tools
>>> - do I NEED to package something or can I simply do a basic download,
>>> untar,
>>> config, make, make install on a running system?
>>
>> No, you don't have to make a package to use software.  GuixSD is,
>> after all, a GNU/Linux system where you can build and run custom
>> software without ever telling the package manager about it.  Do note
>> that we have no global /usr directory, so you'd want to choose where
>> 'make install' will install things by running './configure
>> --prefix=/whatever' when building software that uses the GNU build
>> system.  Ideally, you'd want everything to be managed by Guix so that
>> you could benefit from all the nice features like transactional
>> upgrades and rollbacks, but for quick one-off hacks you can go rogue
>> just as you could on Debian or Trisquel or any other distro.
>
>
> Does GuixSD respect the LSB, and in particular /usr/local/ ?

No.  We don't use LSB, nor do we conform to the FHS, because they
conflict with functional, stateless system management.  Of course, you
could 'mkdir -p /usr/local' on a GuixSD system and do whatever you'd
like.  In Guix, all software builds are kept in /gnu/store, and each
user on the system maintains one or more "profiles" that reference
some subset of the software available in the store.  This gives each
user the freedom to use the software of their choosing, without
worrying about global conflicts with the system or other users.  Thus,
/usr is obsoleted.

For more information about profiles and other per-user package
management features, see:
https://gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#Invoking-guix-package

>>> - does dmd handle standard sysvinit files (as are still most commonly
>>> included in source packages)?
>>
>> No, dmd services are Scheme expressions, rather than ad-hoc Bash
>> scripts.  For example, here's a custom dmd service I wrote awhile back
>> to manage my music player daemon:
>>
>>  (make 
>> #:provides '(mpd)
>> #:requires '()
>> #:start (lambda args
>>   (define (scope file)
>> (string-append (getenv "HOME") "/.config/mpd/" file))
>>
>>   (unless (file-exists? (scope "playlists"))
>> (mkdir (scope "playlists")))
>>   (touch-file (scope "database"))
>>   (fork+exec-command
>>(list "mpd" "--no-daemon"(scope "mpd.conf"
>> #:stop (make-kill-destructor))
>>
>> The dmd manual can be found here:
>> http://www.gnu.org/software/dmd/manual/html_node/index.html
>
>
> I was afraid of that.  It's pretty standard for source code to include
> sysvinit files; I doubt anybody includes dmd service files. Kind of breaks
> most standard service installs.

GuixSD has a service API built into the system configuration system.
The reason for using an init system written in Guile Scheme is that we
get a much better programming interface (Scheme vs. Bash) and can
share a great deal of code between Guix and the service layer.
Sysvinit, systemd, etc. are just not a good fit for us.

> It doesn't look like sysvinit is packaged for GuixSD - it sure would be nice
> to support compatibility.  That would go a long way toward making GuixSD a
> usable distribution.  (One man's opinion.)

Well, one should be able to easily package sysvinit for Guix, but
GuixSD will never use it as PID 1 because it doesn't meet our needs.
Sysvinit is, IMO, antiquated and undesirable.

>>> - and the there's the whole set of issues, recently raised, related to
>>> language systems that maintain their own repos and build systems (e.g.,
>>> CPAN) -- somehow, partial import of dependencies into the GUIX
>>> environment
>>> does not seem usable
>>
>> Like other distros, we work on providing a means to package any type
>> of software with Guix.  We have defined build systems to build
>> software in a variety of languages like Python, Ruby, Perl, R, and
>> Emacs 

Re: question re. installing software & init system

[Thompson, David]

Hello Miles,

On Thu, Dec 31, 2015 at 12:26 PM, Miles Fidelman
 wrote:
> Hi Folks,
>
> One thing that is very murky in the documentation is how to install software
> that isn't packaged.  I can't seem to find any clear documentation on the
> process.

Packaging instructions can be found here:

https://gnu.org/software/guix/manual/html_node/Defining-Packages.html#Defining-Packages

> Several specific questions:
>
> The recent PPT presentation on GUIX (to Inria) implies that packaging can be
> as simple as writing a config file that tells GUIX to do a "config; make;
> make install" on a source file built with the GNU tools
> - do I NEED to package something or can I simply do a basic download, untar,
> config, make, make install on a running system?

No, you don't have to make a package to use software.  GuixSD is,
after all, a GNU/Linux system where you can build and run custom
software without ever telling the package manager about it.  Do note
that we have no global /usr directory, so you'd want to choose where
'make install' will install things by running './configure
--prefix=/whatever' when building software that uses the GNU build
system.  Ideally, you'd want everything to be managed by Guix so that
you could benefit from all the nice features like transactional
upgrades and rollbacks, but for quick one-off hacks you can go rogue
just as you could on Debian or Trisquel or any other distro.

> - does dmd handle standard sysvinit files (as are still most commonly
> included in source packages)?

No, dmd services are Scheme expressions, rather than ad-hoc Bash
scripts.  For example, here's a custom dmd service I wrote awhile back
to manage my music player daemon:

(make 
   #:provides '(mpd)
   #:requires '()
   #:start (lambda args
 (define (scope file)
   (string-append (getenv "HOME") "/.config/mpd/" file))

 (unless (file-exists? (scope "playlists"))
   (mkdir (scope "playlists")))
 (touch-file (scope "database"))
 (fork+exec-command
  (list "mpd" "--no-daemon"(scope "mpd.conf"
   #:stop (make-kill-destructor))

The dmd manual can be found here:
http://www.gnu.org/software/dmd/manual/html_node/index.html

> - and the there's the whole set of issues, recently raised, related to
> language systems that maintain their own repos and build systems (e.g.,
> CPAN) -- somehow, partial import of dependencies into the GUIX environment
> does not seem usable

Like other distros, we work on providing a means to package any type
of software with Guix.  We have defined build systems to build
software in a variety of languages like Python, Ruby, Perl, R, and
Emacs Lisp.  Additionally, we have a tool called 'guix import' to help
automate some of the package recipe writing process by using the data
available on PyPI, RubyGems, CPAN, CRAN, ELPA, etc.

Why do you think that using Guix for languages beyond C isn't usable?

> And a general comment on the documentation:  Given that this is a (sort-of)
> new distro, that does things VERY differently from previous distros - it
> sure would be helpful to have the install documentation provide both a very
> clear overview of the conceptual approach/architecture (vs. items spread
> around various ppts)

We have a section dedicated to the features:
https://gnu.org/software/guix/manual/html_node/Features.html#Features

Are there any specific things that you would change about this section?

> , AND very clear step-by-step instructions for:
> - basic install & configuration

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

https://gnu.org/software/guix/manual/html_node/System-Installation.html#System-Installation

> - installing & configuring packages (both those that run as services and
> those that don't; including later re-configuration)

https://gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#Invoking-guix-package

https://gnu.org/software/guix/manual/html_node/System-Configuration.html#System-Configuration

> - installing & configuring software that isn't packaged

Linked earlier in the message.

> - with particular attention to how the installer, package system, and init
> system work together
> - and with attention to how these all work with other build systems
> You know - something like the Debian install instructions or the FreeBSD
> handbook.
>
> Granted that documentation generally follows code; when doing things
> radically differently, there's a lot to be said for writing documentation
> FIRST - doing so provides a really good check on conceptual clarity and
> usability.  (It kind of makes it hard to do any kind of testing, evaluating,
> or contributing without a good starting point.)

In addition to all of the above-mentioned documentation sections, we
also have a contributing section:
https://gnu.org/software/guix/manual/html_node/Contributing.html#Contributing

Our doc

Re: container issues

[Thompson, David]

On Thu, Dec 31, 2015 at 8:00 AM, Ben Woodcroft  wrote:
> Hey,
>
> I'm on newest master (45147b0), is something amiss?
>
>
> $ ./pre-inst-env guix environment --ad-hoc -C ruby
> In execvp of fsck.none: No such file or directory
> 'fsck.none' exited with code 127 on /home/ben/git/guix; spawning REPL
> GNU Guile 2.0.11
> Copyright (C) 1995-2014 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)>
>
>
>
> I also cannot quit this terminal as it keeps respawning. Any ideas?

I'm able to reproduce this on my GuixSD laptop, but not on my
Guix+Ubuntu system.  Very interesting.  I will try to investigate
further when I get a chance.  Anyone should feel free to fix it before
I do. ;)

Thanks for the report,

- Dave