Re: Building a Docker image for GitLab-CI

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> In the past I used a script to install guix using the shell script and
> then ran guix pull before building my package.  I suppose you could use
> a Debian image and run 'guix pull' first before building something.

I could… but that’d be cheating.  :-)

Ludo’.

Building a Docker image for GitLab-CI

[Ludovic Courtès]

Hello Guix!

Has anyone succeeded in building a Docker image suitable for use in
GitLab-CI?  I haven’t.  Here’s what I tried.

Initially, I built an image with ‘guix system image -t docker …’ but
that doesn’t work because then the image’s “entry point” is shepherd,
but shepherd never returns.  Thus, GitLab-CI would spawn the image and
eventually time out.

So I tried this instead:

  guix pack guix bash-minimal coreutils-minimal grep net-base \
--save-provenance -S /bin=bin -S /share=share -S /etc=etc \
-f docker --max-layers=100

… with ‘.gitlab-ci.yml’ doing something like this:

--8<---cut here---start->8---
build:
  image: registry.gitlab.inria.fr/…
  tags: ["ci.inria.fr", "linux"]
  before_script:
- echo "nameserver 10.0.2.3 # XXX" > /etc/resolv.conf
- guix archive --authorize < /share/guix/ci.guix.gnu.org.pub
- guix archive --authorize < /share/guix/bordeaux.guix.gnu.org.pub
- guix-daemon --disable-chroot &
  script:
- guix shell -m manifest.scm -- rubber --pdf article.tex
  artifacts:
paths:
  - article.pdf
--8<---cut here---end--->8---

Problem is, name resolution appears to fail in the container image; the
‘resolv.conf’ trick was a crude attempt to work around it, but it
failed.  I guess the problem is that I don’t know how GitLab-CI or
Docker is supposed to set up networking inside those containers.

Thoughts?

Neat tip to upload your Guix-built image to a registry: use Skopeo.

  guix shell skopeo -- skopeo login registry.gitlab.inria.fr
  guix shell skopeo -- skopeo copy \
docker-archive:///gnu/store/…-docker-image.tar.gz \
docker://registry.gitlab.inria.fr/… \
--insecure-policy

(“Insecure policy”, what could possibly go wrong?)

Ludo’.

Re: home-syncthing-service-type wants /root paths, yet syncthing can work

[Ludovic Courtès]

Hi,

Tomas Volf <~@wolfsden.cz> skribis:

> Hi,
>
> On 2024-01-05 15:05:38 +0100, Sébastien Lerique wrote:
>> Hi Guix! And dear helpers and devs,
>>
>> I'm running into a weird failure of home-syncthing-service-type.
>>
>> Running syncthing manually from the terminal works fine (here's an example
>> log: ).
>>
>> So I Ctrl-C syncthing, then add home-syncthing-service-type to my
>> home-configuration 
>> 
>> (bottom lines).
>>
>> After restarting, home-syncthing-service-type fails synchronizing because it
>> bases all user folders inside /root, to which it doesn't have writing
>> rights. This happens whether all syncthing configurations in
>> `.local/state/syncthing` had been removed in the meantime or not. Here's a
>> log: 
>>
>> Could this be a bug? A mistake in the configuration files?
>
> After some digging in the source code, I managed to pinpoint the cause.  Your
> configuration does not set user nor home, which causes Guix to call (getpw 
> #f).
> That returns the root user.  I would say this is a bug.  The code probably
> should be something like this (untested):
>
> (or #$home (passwd:dir (getpw (if (and #$home-service? (not #$user)) 
> (getuid) #$user

Agreed.  Sébastien, could you confirm and send a patch?

Thanks,
Ludo’.

Re: How to find a package file from substitute servers

[Ludovic Courtès]

Hello,

Pan Xie  skribis:

> Unfortunately, I can't find a way to do the similar thing on GuixSD. I
> know there is a “guix locate” to find files from store items, but
> those store items must be already present in my gnu store.

There’s a plan to allow ‘guix locate’ to download a file database from
the build farm (for example) but unfortunately that has yet to become a
reality.  So for now, there’s now built-in way to fetch such a database.

Ludo’.

Re: bug#56556: texlive-babel-dutch with and without texlive-hyphen-dutch: No hyphenation patterns were preloaded

[Ludovic Courtès]

Hello Josselin and all,

I was just bitten by the infamous:

  Package babel Warning: No hyphenation patterns were preloaded for
  […]

That’s a real issue because it makes modular TeX Live pretty much
unusable for languages other than English.

Josselin Poiret  skribis:

>> Thirdly, formats are apparently not handled right. The main issue is with
>> hyphenation (hence the cc on an open issue): hyphenation patterns need to be
>> compiled into the formats to be available in documents, so the format files
>> should be built depending on which `texlive-hyphen-something` packages are
>> installed. Currently this is not the case:
>>
>> ```
>> $ guix shell --pure coreutils texlive-base texlive-latex-base -- /bin/sh -c 
>> 'realpath $GUIX_TEXMF/web2c/pdflatex.fmt'
>> /gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
>> $ guix shell --pure coreutils texlive-base texlive-latex-base 
>> texlive-hyphen-base texlive-hyphen-french -- /bin/sh -c 'realpath 
>> $GUIX_TEXMF/web2c/pdflatex.fmt'
>> /gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
>> ```
>>
>> If the format is always the same, then no modular installation can do any
>> hyphenation, as reported in https://issues.guix.gnu.org/56556. There might be
>> other things than hyphenation that require similar treatment.
>
> I don't really know how we could fix this: maybe build the formats with
> all the hyphenation packages enabled?

The intertubes suggest running ‘fmtutil --all’ to get hyphenations
packages straight.  Is this something we should do in the TeX Live
profile hook for example?

Emmanuel, is this what you had in mind when you wrote about compilation
of hyphenation patterns above?

(Cc’ing Maxim who has experience with TeX Live.)

Thanks,
Ludo’.

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

[Ludovic Courtès]

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.

HTH,
Ludo’.

Re: Is there any way to change what /bin/sh is inside `guix shell [--container]` ?

[Ludovic Courtès]

Hi Zack,

"Zack Weinberg"  skribis:

> I'm doing experiments with using `guix shell --container` for isolated, 
> reproducible build environments.  I've noticed that no matter how I set up 
> the container, `/bin/sh` points to a full-fat bash, even if the full bash 
> package was not included in the container profile.

That’s correct.  There’s correctly no way to change that, but we could
definitely add an option to do that.

Would you like to give it a try?  People on IRC and the mailing list can
provide guidance.

Thanks,
Ludo’.

Re: Grub installation and configuration

[Ludovic Courtès]

Hi Emmanuel,

Emmanuel Beffara  skribis:

> - Install the keymaps in the EFI partition like the Grub modules, so that the
>   proper keymap is setup early in the boot process.

[...]

> - Set the terminal_output before any user input is required (and in particular
>   the passphrase request), for proper interaction.

[...]

> - Offer the option to put kernels and initrds in the EFI partition (and also
>   any resource needed by Grub like the background picture, locales etc), so
>   that Grub can be fully functional without decrypting. Apart from solving the
>   issue of having to enter the passphrase twice and with different keymaps,
>   this would also allow having Guix System in an encrypted partition while
>   allowing to boot other systems without requiring its passphrase.
>
> I would love to propose patches for that but I am too much of a beginner with
> Guix to be able to do that right now…

All good points!

Maybe what you can do, then, is report each issue to bug-g...@gnu.org
separately and provide guidance for the GRUB side of things: what should
the generated ‘grub.cfg’ look like after each of these points is
addressed?

In return, an experienced Guix person can provide guidance on the Guix
side of things so we converge towards an actual patch set.

Deal?  :-)

Ludo’.

Re: %current-system and --system

[Ludovic Courtès]

Hi,

Greg Hogan  skribis:

> From my x86_64 machine I am executing offload builds targeting an
> aarch64 machine:
>
> $ guix build --system=aarch64-linux --manifest=manifest.scm
>
> Several packages do not build for aarch64 and need to be filtered out.
> %current-target-system is #f as these are offload builds not cross
> compilation, and %current-system is reported as "x86_64-linux". How
> can I access the current "build system"?

Not via ‘%current-system’ because at the time the manifest is evaluated,
it can be bound to anything, as you saw.

What you could do is wrap packages in ‘let-system’, which lets you check
the “current system” as the time the object is “lowered” (untested):

  (define (package-or-emptiness p)
(let-system system
  (if (supported-package? p system)
  p
  (plain-file "emptyness" "Nothing to see here."

   (manifest
(map (lambda (p)
   (manifest-entry
 (inherit (package->manifest-entry p))
 (item (package-or-emptiness p
 the-packages))

Obviously that’s not great because you still end up with entries for
non-existing packages.  It’s good enough for ‘guix build -m’ though.

HTH!

Ludo’.

Re: streamlining custom package development

[Ludovic Courtès]

Hi,

Przemysław Kamiński  skribis:

> 3. I run `guix build -L  -m manifest.scm
> (manifest only contains a reference to ghc-stuff.scm)
> 4. I get an error which looks like this:
> View build log at
> '/var/log/guix/drvs/j2/wa3vw49l78m85z74x91sklqxwhx87y-ghc-hwodr-0.1.0.drv.bz2'
>
> so I fire up
>
> bunzip --stdout
> '/var/log/guix/drvs/j2/wa3vw49l78m85z74x91sklqxwhx87y-ghc-hwodr-0.1.0.drv.bz2'
>
> and see that I am missing some Haskell packages.

Note that the build log should be just above the “View build log” line
if you scroll up a little bit.  :-)

Otherwise, like Simon said, I’d recommend getting package definitions by
running ‘guix import hackage -r’, assuming said packages are on Hackage.
That should simplify things.

HTH,
Ludo’.

Re: Wrong type argument: package-input-rewriting/spec with inferior

[Ludovic Courtès]

Hi Greg,

Greg Hogan  skribis:

> Having failed a year ago to build the latest gcc and latest clang
> together using "with-c-toolchain",

Is there a bug report on this?  I’m curious what might be wrong;
‘with-c-toolchain’ should be the tool of choice for this use case.

[...]

> On master I modify the manifest to create an inferior for glibc@2.35
> from core-updates, but receive the following error when attempting to
> use the inferior as a package. A similar question went unanswered on
> StackOverflow last year
> (https://unix.stackexchange.com/questions/699148/how-to-use-an-inferior-when-input-rewriting-in-guix).

[...]

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure package-properties: Wrong type argument:
> #

As you found, package input rewriting doesn’t work with inferior
packages.

However it’s a case where it may be easier to provide a glibc@2.35
package on ‘master’ and to use that.

But then again, I wonder why you end up rebuilding glibc.  For example,
this would only rebuild LLVM and everything above:

--8<---cut here---start->8---
$ guix build clang --with-c-toolchain=llvm=gcc-toolchain@12 -n
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
The following derivations would be built:
  /gnu/store/hrpn8c11x52b9yax44x0spya90q6c3z0-clang-15.0.7.drv
  /gnu/store/f95nrszbdj72wbb22irvq230nm6ci07h-clang-runtime-15.0.7.drv
  /gnu/store/kxbjlkv9yjyg149aj6zc0w0sdgpdwhzn-llvm-15.0.7.drv
109.4 MB would be downloaded:
  /gnu/store/66sfk0k8419xvl7kg7r631z9yf9cpy3f-llvm-project-15.0.7-checkout
  
/gnu/store/i291yk8ka6hamma955zgr2jh6cn21ybf-clang-tools-extra-15.0.7.src.tar.xz
  /gnu/store/gm15qsiiy3jz3ainp6nv082m7lh9nx4p-rhash-1.4.2
  /gnu/store/j65q3aw414010gdfvmsynwpzfb2jyyd3-cmake-minimal-3.21.4
  /gnu/store/1yq0yi6hjbfhw578c4973454iwxc248n-module-import-compiled
--8<---cut here---end--->8---

Maybe I’m overlooking something though.

HTH,
Ludo’.

Re: The Guix Days! (FOSDEM 2023)

[Ludovic Courtès]

Hello,

Pjotr Prins  skribis:

> Just a heads up: we are excited to have Guix days and the FOSDEM
> devroom in Brussels Feb 2-5!!
>
> If you want to attend Guix days, please add to this list (the login is
> a bit hidden). We can only have limited people and catering. If we run
> over the max room number we'll have a problem:
>
> => https://libreplanet.org/wiki/Group:Guix/FOSDEM2023
>
> The programme for the devroom runs partially virtual and partially
> live. The lineup is great as ever:
>
> =>
> https://fosdem.org/2023/schedule/track/declarative_and_minimalistic_computing/

I booked my train, yay!!

It’s that time of the year where we usually have a blog post inviting
people to meet us at FOSDEM and at the Guix Days.  :-)

  https://guix.gnu.org/en/blog/2022/meet-guix-at-fosdem-2022/
  source: 
https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/meet-guix-at-fosdem-2022.md

Who’s in to prepare this year’s post?

Ludo’.

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hi Jim,

Jim Newsome  skribis:

> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:

That’s another good example, thanks for sharing!  It’s especially
interesting because the Tor project vets the binaries they provide.

Ludo’.

GNU Guix 1.4.0 released

[Ludovic Courtès]

We are pleased to announce the release of GNU Guix 1.4.0!

This release corresponds to more than 28,000 commits over 18 months by
453 people.  It adds new tools such as ‘guix shell’ for environment
management and ‘guix home’, which lets you declare your home
environment.  It refines the user and packager experience and improves
performance.  This release also includes many new packages and services
along bug fixes—see below for a list of changes.

Read more about today’s announcement at:

  https://guix.gnu.org/en/blog/2022/gnu-guix-1.4.0-released/


• About

  GNU Guix is a transactional package manager and an advanced
  distribution of the GNU system that respects user freedom.  Guix can
  be used on top of any system running the Hurd or the Linux kernel, or
  it can be used as a standalone operating system distribution for i686,
  x86_64, ARMv7, AArch64, and POWER9 machines.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  When used as a
  standalone GNU/Linux distribution, Guix offers a declarative,
  stateless approach to operating system configuration management.  Guix
  is highly customizable and hackable through Guile programming
  interfaces and extensions to the Scheme language.

  https://guix.gnu.org


• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz   (39MB)
https://ftp.gnu.org/gnu/guix/guix-1.4.0.tar.gz.sig

  Here are the bootable USB installation images and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso   
(778MB)
https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.i686-linux.iso.sig
https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso   
(814MB)
https://ftp.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso.sig

  Here is the QCOW2 virtual machine (VM) image and its signature[*]:
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2 
(1.2GB)

https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.4.0.x86_64-linux.qcow2.sig

  Here are the binary tarballs and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz   (94MB)
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.aarch64-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz   (92MB)
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.armhf-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz   (98MB)
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.i686-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz   
(98MB)
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz   (98MB)
https://ftp.gnu.org/gnu/guix/guix-binary-1.4.0.x86_64-linux.tar.xz.sig

  Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

  Here are the SHA256 hashes:

  43c769cbf632ef05449ac1fa48c1ba152c33494c6abc7e47137bba7b2149f8a4  
guix-1.4.0.tar.gz
  72d807392889919940b7ec9632c45a259555e6b0942ea7bfd131101e08ebfcf4  
guix-binary-1.4.0.aarch64-linux.tar.xz
  162c114ffcd5d331ec4c2974fcdca09e601e0e62950925a1d839584a7c720130  
guix-binary-1.4.0.armhf-linux.tar.xz
  1e6124e917288097ef94eebd175bf1bc73f5be67a20e98fec7d33368050fd02d  
guix-binary-1.4.0.i686-linux.tar.xz
  a0c54a0af8b0ae3097bfd33ddf408503a5df2d98b0848a83bb7e8da5c8d1a7fa  
guix-binary-1.4.0.powerpc64le-linux.tar.xz
  236ca7c9c5958b1f396c2924fcc5bc9d6fdebcb1b4cf3c7c6d46d4bf660ed9c9  
guix-binary-1.4.0.x86_64-linux.tar.xz
  07a5484d5c8f11294fabe0d32b422bdfd966ed9d8faf396cbedd0b6e3c39c740  
guix-system-install-1.4.0.i686-linux.iso
  087a97dba2319477185471a28812949cc165e60e58863403e4a606c1baa05f81  
guix-system-install-1.4.0.x86_64-linux.iso
  905dbdf0d32490eda66c4afdba98a80d0c3e50358b1a868423771af0a8561cae  
guix-system-vm-image-1.4.0.x86_64-linux.qcow2

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify guix-1.4.0.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.openpgp.org \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  and rerun the ‘gpg --verify’ command.


• Changes in 1.4.0 (since 1.3.0)

  ** Package management
  *** New ‘guix home’ command, for home environment management
  *** New ‘guix shell’ command, the successor to ‘guix environment’
  *** New ‘guix system edit’ command, to edit services
  *** New ‘deb’ format for the ‘guix pack’ command
  *** New ‘guix import minetest’ command, to import Minetest 

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hello!

John Kehayias  skribis:

> First, let's dive right into a big one: the popular VSCodium editor. This is 
> a freely licensed build of VS Code: 
> 
>
> This comes in AppImage format. Downloading it and making it executable (with 
> a 'chmod +x') I can run it in a container as
>
> guix shell -CNF -D ungoogled-chromium gcc:lib \
>  --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY \
>  --preserve='^DBUS_' --expose=/var/run/dbus \
>  --expose=/sys/dev --expose=/sys/devices --expose=/dev/dri \
>  -- ./VSCodium-1.74.0.22342.glibc2.17-x86_64.AppImage 
> --appimage-extract-and-run

The code in that AppImage is free software, right?

> Another example is to get the latest nightly builds of Rust, via 
> 

That’s a nice one too!

> Happy to try other examples and to hear feedback on these!

I think these are two good examples, likely to correspond to the kind of
thing people may want to try.

>> Actually you can use or get inspiration from this animated GIF if you
>> like:
>>
>>   
>>
>
> Either I forgot to save this or wasn't able to access it before, and can't 
> access it now.

Yeah, the TLS setup on that machine is broken, so you’d have to “Accept
the risk and continue”; I sent you a copy off-list.

If we release on Monday, it would be great to have it published…
tomorrow (Friday).  Otherwise next Friday maybe?

Thanks!

Ludo’.

GNU Guix 1.4.0rc2 available for testing!

[Ludovic Courtès]

Hello Guix!

The second release candidate of the upcoming 1.4.0 release is now
available for testing, fixing issues that were reported for rc1:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.4.0rc2.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc2.x86_64-linux.tar.xz

  system installation:
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.i686-linux.iso
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc2.x86_64-linux.iso

  virtual machine image:

https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2

SHA256 hashes:

  3b6c676615ce0b9de7c66ead528a91bb8520b74d2c391edac8d4c76d2d52  
guix-1.4.0rc2.tar.gz
  3566bfe5f0615f9b2167db7d1a2f1c88c02e8cc5013563b3e1eb95636a58f850  
guix-binary-1.4.0rc2.aarch64-linux.tar.xz
  18741b6780e9d0f8985d2514e5dff32110091cdf4da106062d1a2cf5cd6ed6a4  
guix-binary-1.4.0rc2.armhf-linux.tar.xz
  3d8348c2dbed8f9c6ab90f2ddc0df8c10d45c042612aed1fe7dcc7eabbc18b70  
guix-binary-1.4.0rc2.i686-linux.tar.xz
  4731126cc4f3f22265ae430e2acc3f67489ec311e42de346b634656740258033  
guix-binary-1.4.0rc2.powerpc64le-linux.tar.xz
  542e53a09fddedbddd75dfc745509ad9365cb7a76750d9bf8575b589c97dc286  
guix-binary-1.4.0rc2.x86_64-linux.tar.xz
  b35f94609942b9715acefa978166189c5505934c9576b1c3e14417beb5c48d6d  
guix-system-install-1.4.0rc2.i686-linux.iso
  880a1ee977f6999f63535d5667930d1d859a607c723573c86bd9f6c2ae69  
guix-system-install-1.4.0rc2.x86_64-linux.iso
  8bc98e42ba9370f49cfc2b051083121d8682c760ac3dac614b3f478d174c8756  
guix-system-vm-image-1.4.0rc2.x86_64-linux.qcow2

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
 [0].

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download  and uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org.  It
 should pick up 1.4.0rc2 automatically.

  2. Testing the graphical installer of Guix System (the ISO images).

  3. Testing the VM image, along the lines of
 .

Please report success to guix-de...@gnu.org, and report bugs and
annoyances to bug-g...@gnu.org.

If not serious problems are reported, we may release 1.4.0 on Dec. 19th.

Thanks in advance!

Ludo’.

[0] Replacing https://sv.gnu.org/people/viewgpg.php?user_id=127547 by
https://sv.gnu.org/people/viewgpg.php?user_id=15145 in the
instructions.  This will only be reflected on the website after the
release is made.


signature.asc
Description: PGP signature

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hello!

John Kehayias  skribis:

> One question: what is appropriate or recommended for examples concerning 
> things like pre-built binaries? As an example, I had tested the FHS container 
> by running the Siril appimage, which has since been packaged for Guix (nice 
> work!). There are ones that I don't see that happening for anytime soon, like 
> an Electron-based app. Something like VSCodium is very popular, free (as in 
> freedom and I believe the FSDG sense), but just not something you can package 
> fully from source due to JavaScript as I understand it. It runs in the FHS 
> container.

A good example might be a free application not currently packaged in
Guix, for example due to being full of JavaScript, or nightly builds as
you wrote provided by an upstream project.

> Here is a current (rough!) draft. For the ease of plain text email I've 
> exported from the org source to text with some light edits:

Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
export works well.

¹ https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts

The post looks great to me!  I have minor suggestions below:

> GNU Guix is different from most other GNU/Linux distributions and
> perhaps nowhere is that more obvious than the organization of the
> filesystem: Guix does not conform to the [File Hierarchy Standard]
> (FHS). In practical terms, this means there is no global `/lib'

It’s “Filesystem Hierarchy Standard”.

> To that end, we've [recently added] a new option for Guix containers,
> `--emulate-fhs' (or `-F'). This will set up an environment in the

Perhaps s/Guix containers/`guix shell`/ and add a few words about what
‘guix shell --container’ does (you can link to the manual or blog post).

> container that follows FHS expectations, so that libraries are visible
> in `/lib' in the container, as an example. Additionally, for the more
> technically-minded, the [`glibc' used in this container] will read from
> a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
> otherwise].

Since the ld.so.cache issue is more involved (compared to simply having
/lib and /bin), maybe you can move it after the “ls /bin” example?

> Contrast that with `/bin' on a Guix system:
> ,
>  ls /bin -la
> `
>
> lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  
> /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

You can show ‘ls /lib’ too.  :-)

Actually you can use or get inspiration from this animated GIF if you
like:

  https://web.fdn.fr/~lcourtes/tmp/guix-shell-fhs.gif

> useful. For example, there may be software that is free and conforms to
> the FSDG Guix follows, yet is not feasible to be [packaged] by our

s/FSDG/Free System Distribution Guidelines (FSDG)/

Thanks,
Ludo’.

Re: Installing guix on a cluster

[Ludovic Courtès]

Hi Reza,

Reza Housseini  skribis:

> I installing guix on our institutes cluster and followed the
> instructions in this blog post [1]. But there are a couple of problems
> I stumbled upon:
>
> - There is no mention how to mount the nfs shares on the nodes. I
>   added them to the /etc/fstab file but I'm unsure about the mount
>  options

Just mount /gnu/store and /var/guix as NFS.  The store should be mounted
read-only; /var/guix must be writable.  But that’s about it, no special
options are needed.

> - Thers is no guix binary on the nodes. I added a symlink to
>   /var/guix/profiles/per-user/root/current-guix/bin/guix in
>   /usr/local/bin

Yes, that’s what needs to be done.

> but when I try to install a package from a node I get an open-file
> permission denied for
> /var/guix/profiles/per-user/root/guix-profile.lock

It looks like you’re running ‘guix’ on the node as root.  Try running it
as non-root instead.

(If you really want to be able to run ‘guix’ as root on the nodes, then
you need to pass the ‘norootsquash’ (not sure about the spelling) option
for the /var/guix NFS mount.  That’s not a great idea though.)

> - In this email [2] it was mentioned I don't have to pass listen to
>   the guix-daemon, as the socket gets shared over nfs, but when I
>   remove the listen argument and try to install a package from a node
>   I get a failed to connect to /var/guix/daemon-socket/socket:
>  connection refused

Unix-domain sockets cannot be shared over NFS.  You have to use the
‘--listen’ option and set ‘GUIX_DAEMON_SOCKET’ as explained in
.

HTH!

Ludo’.

Re: RedShift

[Ludovic Courtès]

Hi,

Raghav Gururajan  skribis:

> 2022-11-18 21:52:18 Service redshift has been started.
> 2022-11-18 21:52:18 [redshift] `RANDR Query Version' returned error -1
> 2022-11-18 21:52:18 [redshift] Initialization of randr failed.
> 2022-11-18 21:52:18 Service redshift (PID 832) exited with 1.

That probably means that the ‘DISPLAY’ environment variable (for X11)
isn’t set, and thus redshift cannot do anything.

In my case, Home’s shepherd starts after X11 has been initialized, so
‘DISPLAY’ is set and all is well.

HTH!

Ludo’.

GNU Guix 1.4.0rc1 available for testing!

[Ludovic Courtès]

Hello Guix!

The first release candidate of the upcoming 1.4.0 release is now
available for testing:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.4.0rc1.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc1.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc1.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc1.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc1.powerpc64le-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.4.0rc1.x86_64-linux.tar.xz

  system installation:
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc1.i686-linux.iso
https://alpha.gnu.org/gnu/guix/guix-system-install-1.4.0rc1.x86_64-linux.iso

  virtual machine image:

https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.4.0rc1.x86_64-linux.qcow2

SHA256 hashes:

  2d9486b0689bf74d38ed4e09b020543d66cc1d9f2ec64e82557f6bebcf54c711  
guix-1.4.0rc1.tar.gz
  3853608a25e3540270900060e34b8ac973d69d2d64b2fc65981e2578fd4c09ba  
guix-binary-1.4.0rc1.aarch64-linux.tar.xz
  1f871cd1a54b347c6311503ed4d68a663af74c187131477d4d067221692e3eee  
guix-binary-1.4.0rc1.armhf-linux.tar.xz
  5abe711d2570032e807db1740b6c3d44ca3ecc552ff3677180c07cc39a4476ff  
guix-binary-1.4.0rc1.i686-linux.tar.xz
  4425d3d3e6c5a9f8a3aacab9579d7a96180e6dac7f60a04d2360dd5d1409b96d  
guix-binary-1.4.0rc1.powerpc64le-linux.tar.CZ
  63ac7e299c9d6cfc185d8f49c5672656c8836531e1c25566861899d6f72d0bad  
guix-binary-1.4.0rc1.x86_64-linux.tar.xz
  b13f8d65a05afc1ca178617d9e8e6e55d399717a114f90048e519d21800904f1  
guix-system-install-1.4.0rc1.i686-linux.iso
  57367f2a89f1c0a6929f363bf19ec4b73bef443ffb84c6c5ddbdd76e96adc7c0  
guix-system-install-1.4.0rc1.x86_64-linux.iso
  e1751326b5d1849dc7b21454c45decf9489e57b2049b49ffe7e77258dba5  
guix-system-vm-image-1.4.0rc1.x86_64-linux.qcow2

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
 [0].

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download  and uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org.  It
 should pick up 1.4.0rc1 automatically.

  2. Testing the graphical installer of Guix System (the ISO images).

  3. Testing the VM image, along the lines of
 .

Please report success to guix-de...@gnu.org, and report bugs and
annoyances to bug-g...@gnu.org.

Thanks in advance!

Ludo’.

[0] Replacing https://sv.gnu.org/people/viewgpg.php?user_id=127547 by
https://sv.gnu.org/people/viewgpg.php?user_id=15145 in the
instructions.  This will only be reflected on the website after the
release is made.


signature.asc
Description: PGP signature

Re: warning: failed to install locale: Invalid argument

[Ludovic Courtès]

Hi,

jgart  skribis:

> guile: warning: failed to install locale

This means that data for the locale you chose is cannot be found by the
C library used by Guile.

Typically, one chooses locale data by setting environment variables such
as ‘LC_ALL’ or ‘LANG’.

In Guix, locale data is provided separately from the C library (glibc).
You can either get it from the ‘glibc-locales’ package, which contains
all existing locales, or, on Guix System, you’ll get the locales you
asked for under /run/current-system/locale.

The manual has more details on setting up locales.

HTH!

Ludo’.

Re: question on setting up guix.scm for project development

[Ludovic Courtès]

Hi,

Andy Tai  skribis:

> guix.scm---
> (use-modules (guix packages)
>)
>
> (define-public d2-0.1.4
>(package
>(name "d2")
>(version "0.1.4")
>
>...
> )
>
>
> (define-public my-package
>(package
>   (name "my-package")
>   (version "0.1")
>  ...
>
>
>  (input (list d1 d2-0.1.4 d3...)
> 
> ))
>
> my-package
>
> ---end guix.scm--
>
>
> and if I use
>
> guix shell -f -d ./guix.scm
>
> this does not seem to generate an environment that contains the new
> dependency, that is d2 version 0.1.4

‘guix shell -f guix.scm’ generates an environment that contains the
package returned by ‘guix.scm’.

Conversely, ‘guix shell -D -f guix.scm’ produces the development
environment of the package returned by ‘guix.scm’.

HTH!

Ludo’.

Re: RedShift

[Ludovic Courtès]

Hi,

Raghav Gururajan  skribis:

> I'm trying to use the redshift home-service
> [https://git.savannah.gnu.org/cgit/guix.git/commit/?id=39e8025d3b40a0079f75e0ce9a91b6dad6766773],
> but `herd status` always show it as stopped. Unlike the 'manual'
> location-provider example mentioned in the commit, I'm using geoclue.
>
> Do you happen to have an example for redshift with geoclue?

I don’t use Geoclue; instead, I specified my coordinates and I stay
home.  ;-)

If ‘herd start redshift’ fails, there should be more info in
~/.local/var/log/shepherd.log.  Could you check that and share your
findings?

HTH,
Ludo’.

Re: Configuring nscd cache for mDNS

[Ludovic Courtès]

Hi Trevor,

Trevor Vallender  skribis:

> I have a Docker container which advertises its name using mDNS,
> e.g. hostname.local. However, when I restart the container,
> Docker assigns the container a new IP (not sure why, doesn't
> happen on other distros but that's probably not the point
> here). nscd has the old IP cached and doesn't refresh even though
> the container is advertising the new IP. I'm not sure why this
> behaviour is occurring, or if it is the expected behaviour?

I think so.

> I'm don't know the correct fix here but am open to suggestions. I
> presume one of the following:
>
> - Configure nscd not to cache mDNS addresses
> - Shorten the length of time these addresses are cached for
>
> If someone could suggest why this is occurring, or provide an
> example of how to do one of the above, that would be brilliant.

You can clear nscd’s host name cache with:

  sudo herd invalidate nscd hosts

Better, you can configure nscd to disable caching along these lines:

  (operating-system
;; …
(services
  (modify-services %base-services  ;or ‘%desktop-services’, etc.
(nscd-service-type
 config => (nscd-configuration
 (inherit config)
 (caches '()))   ;zero caches

More details here:

  
https://guix.gnu.org/manual/devel/en/html_node/Base-Services.html#index-nscd_002dconfiguration

HTH!

Ludo’.

Re: How to avoid downloading qtbase:debug

[Ludovic Courtès]

Hi!

kiasoc5  skribis:

> =guix shell qtbase= downloads the entire debug output of qtbase even
> though I didn't write down qtbase:debug. That's hundreds of megabytes
> of bandwith I didn't want to use. How do I avoid downloading the debug
> output? Is this a bug?

Yes, it’s an unfortunate bug:

  https://issues.guix.gnu.org/30952

Would be good to look into it again with a fresh mind!

Ludo’.

Re: Guix Home question ?

[Ludovic Courtès]

Hi,

jordi  skribis:

>   While starting to enjoy 'guix home' superpowers i created this git 
> repository
>
> https://codeberg.org/Fenix/home-config-at-mercurio
>
> taking care of my old laptop's config.
>
> I might be missing some basics here...
> First question that comes to my mind is... how to avoid the .bash_aliases 
> imported by my current .bashrc to mess with the services at 
> home-configuration.scm file ?

How does ‘.bash_aliases’ mess with the services in your Home config
file?

At any rate, ‘.bash_aliases’ is most likely useless now that aliases
have been imported in your ‘home-configuration.scm’.

HTH,
Ludo’.

Re: Lost all my guix home application packages from channels after guix update (pull, reconfigure)

[Ludovic Courtès]

Hi,

"Sebastien Rey-Coyrehourcq" 
skribis:

> I used guix home without problem last month but with a recent guix pull, guix 
> system reconfigure, guix home reconfigure, all my package defined into guix 
> home manifest disapear !! 

What do you mean by “disappear”?  What does this report:

  guix home describe --list-installed

?

Thanks,
Ludo’.

Re: Trivia question: What does the "G" in G-expressions stand for?

[Ludovic Courtès]

Ekaitz Zarraga  skribis:

>> Hi!
>> 
>> jgart jg...@dismail.de skribis:
>> 
>> > Does the G in G-Expressions stand for Guix?
>> 
>> 
>> No, it stands for “G”, just like the “s” in “s-expression” stands for
>> nothing (AFAIK). :-)
>> 
>> Ludo’.
>
> In s-expression it doesn't stand for symbolic expression?

Ah well, “G” might stand for “golden” or “great” then.  :-)

Ludo’.

Re: lock files

[Ludovic Courtès]

Hi,

Dominic Martinez  skribis:

> jgart  writes:
>
>> Does Guix have a concept of lock files?
>
> In Guix, instead of locking specific packages, you lock an entire Guix
> installation. You can see the "lock" for your current installation with
> the 'guix describe' command.

Yes.  To complement that, see:

  https://guix.gnu.org/manual/devel/en/html_node/Replicating-Guix.html

BTW, I know it’s become widespread, but I find “lock file” to be a
confusing term (and indeed, Ricardo understood the historical meaning of
that term).  “Version pinning” sounds like a more accurate description
of the concept to me.

HTH!

Ludo’.

Re: Combine locales

[Ludovic Courtès]

Hi,

Fredrik Salomonsson  skribis:

> One thing I cannot figure out is how to setup the operating-system to
> use English as the language but use Swedish for the date format. Similar
> to what is described in Locale Names[0] in the libc manual.
>
> I.e. on my foreign distro I have /etc/locale.conf define:
> ---✀
> LANG=en_US.UTF-8
> LC_TIME=sv_SE.UTF-8
> 

I think we’re missing an easy way to configure this.  One way to do it
system-wide would be (untested):

  (simple-service 'locale-setup session-environment-service-type
  '(("LANG" . "en_US.UTF-8")
("LC_CTIME" . "sv_SE.UTF-8")))

That way, all sessions would get these environment variables by default.

HTH!

Ludo’.

Re: how to fix this G-exp?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sat, 24 Sep 2022 at 20:40, Csepp  wrote:
>
>> As you can see, that is an unqouted list.  The fix should be pretty
>> simple: just add an extra quote.  Haven't tested it, but one of these
>> should work:
>> ```
>> (define (something) ''(42))
>> ;; or
>> (quote #+(something))
>> ```
>
> The extra quote does not work.

I think Csepp was on the right track though.

Attached is a version where I added that quote:

  #~(begin
  …
  (define that
'#+(something))
  …)

AFAICS, that was the only fix that needed to be made.  (I also removed
(json) from the imported modules; it’s already taken care of by
‘with-extensions’.)

Pro tip: to debug code staging issues like this, where you end up
staging code that doesn’t behave as you would expect, it’s useful to
check what the staged code looks like, like so:

--8<---cut here---start->8---
$ cat $(guix gc -R $(guix build -m /tmp/zimoun.scm -d)|grep example-json-build)
(begin (use-modules (guix build utils) (json)) (define that (quote (42 43 44))) 
(define file-name (string-append ((@ (guile) getenv) "out") "/example.json")) 
(mkdir-p (dirname file-name)) (with-output-to-file file-name (lambda () 
(scm->json (list->vector that)
--8<---cut here---end--->8---

That ‘example-json-builder’ file contains the staged version of your
code.  We can see '(42 43 44) there; if we remove the quote mentioned
above, we get:

  (define that (42 43 44))

which leads to a wrong-type-to-apply error.

HTH!

Ludo’.

(use-modules (srfi srfi-1)
 (ice-9 match)
 (guix packages)
 (gnu packages))

(define (package+propagated-inputs package)
  (match (package-transitive-propagated-inputs package)
(((labels packages) ...)
 (cons package packages

(define (something)
  (list 42 43 44))

(define (an-example)
  (define build
(with-extensions (package+propagated-inputs
  (specification->package "guile-json"))
  (with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils)
 (json))

(define that
  ;; 'something' returns a list of integers; we need to quote
  ;; that list: it's data, not code, that we are inserting here.
  '#+(something))

(define file-name
  (string-append #$output "/example.json"))

(mkdir-p (dirname file-name))
(with-output-to-file file-name
  (lambda ()
(scm->json (list->vector that

  (computed-file "example-json"
 build))

(manifest
 (list (manifest-entry
 (name "bang")
 (version "0")
 (item (an-example)

Re: Trivia question: What does the "G" in G-expressions stand for?

[Ludovic Courtès]

Hi!

jgart  skribis:

> Does the G in G-Expressions stand for Guix?

No, it stands for “G”, just like the “s” in “s-expression” stands for
nothing (AFAIK).  :-)

Ludo’.

Re: How does a gexp relate to a derivation?

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> I recommend the paper on Gexps that walks you through the alternatives
> and motivates the design of Gexps: https://hal.inria.fr/hal-01580582/en

The manual has a few examples to illustrate that:

  https://guix.gnu.org/manual/devel/en/html_node/G_002dExpressions.html

As an exercise, try to see how you’d write these examples if you were to
use sexps instead of gexps.  This is what Guix did before gexps, and it
was tedious and error-prone (the article above has more about it).

HTH,
Ludo’.

Re: Initramfs dropbear remote crypt unlock

[Ludovic Courtès]

Hi,

Nick  skribis:

> Is it possible in Guix to activate dropbear in initramfs to remotely unlock
> fully encrypted disk (root) setup? (Like it done in Debian
> dropbear-initramfs package with cryptroot-unlock command)

There’s nothing to do that out of the box, but starting Dropbear from
the initrd is feasible.  In a nutshell, you could take a look at
‘raw-initrd’ in (gnu system linux-initrd) and insert a snippet that
spawns Dropbear there.  Or maybe ‘luks-device-mapping’ could have an
option for remote unlocking over SSH.

HTH,
Ludo’.

Re: managing waiting patches

[Ludovic Courtès]

Hi,

Nicolas Graves  skribis:

> Is there a requirement to help with patch reviewing? I feel I can tackle
> python or rust packages unless they are weird, I need not to spend too
> much time on that, but if it's just advising new beginners (I'm myself
> a 9 month old Guix user but went cold turkey on my main machine, while
> my first patches were a nightmare, now I hope/believe they are quite
> clean) or trying to patch and build locally for <1h a day, with
> proper guidelines I might be able to help here.

Your help reviewing would be much welcome.

Currently there’s no strict “requirement” to help with patch review, but
the manual reads this (info "(guix) Commit Access"):

  One last thing: the project keeps moving forward because committers not
  only push their own awesome changes, but also offer some of their time
  _reviewing_ and pushing other people’s changes.  As a committer, you’re
  welcome to use your expertise and commit rights to help other
  contributors, too!

That hasn’t had the desired effect though—still too few reviewers among
the ~40 committers.  I’m not opposed to discussing whether to turn it
into a “requirement”.  A hot topic for those of us who’ll be in Paris
soonish!

Ludo’.

Re: Enterprise Guix Hosting?

[Ludovic Courtès]

Hi Phil,

Phil  skribis:

> Comments inline.  I'm also aiming to be at the Guix 10 Year thing in
> Paris - sadly only for the Friday, so happy to discuss this informally
> there too!

Looking forward to chatting there!

[...]

> Whilst I like Guix's own documentation, some developers did feedback to
> me that it was to complex for people who just wanted to get-on and use
> Guix, rather than setup, understand and maintain Guix.  So this is the
> area I ended-up documenting - "Guix Up-and-running for Python
> Developers". One day I'd like to publish it properly, but it's very much
> a WIP at the moment!

Publishing such a document (either standalone or as part of the
cookbook) would be great; it’d certainly be a gentle way to get started
for many developers out there.

> One advantage I did have is that I rewrote the CI/CD system
> to work around Guix, and the old system was showing it's age, so people
> were happy to trade Python venvs, for a better build and deployment 
> experience.

Yes, that too is a use case that we should document better (some years
ago I used Guix at work for CI, testing a piece of C++ code under a
variety of configurations—tedious to do without Guix.)

> We now have 5 developers working at least part of the time writing
> Guix packages, or tweaking small bits of the Guix core code (I keep
> meaning to make more of an effort to get our efforts back into Guix
> proper!).  As more developers slowly try-out more advanced stuff in Guix
> this number is growing, and most developers that invest the time end up
> liking Guix - so I think there's plenty of hope to grow it further!

Neat!

[...]

> 3 things which lowers the barrier to entry in my experience commercially
> would be:
>
> - Push button WSL support (I know this has some momentum eg
>   https://lists.gnu.org/archive/html/guix-patches/2022-08/msg00945.html).
>   At the moment I tend to use a custom image I made which is just WSL on
>   top of Ubuntu.  I have made it work with busybox, but it's not yet
>   robust enough to wheel out over the enterprise like this.
> - Perhaps a set of videos aimed directly at converting a vanilla Python
>   environment into one running in Guix.  Try to entice the communities
>   off their current tooling by making it as easy as possible to switch.
>   I even went as far as writing a requirements file to guix package
>   converter at work to help with this.
> - Excellent Javascript support would help.  I'm aware of some of the
>   difficulties this presents Guix, and am not a fan of npm, etc - but
>   it's so often used by developers I think not having support for it is
>   always going to be tricky to sell to a wider audience.

This is sorted in order of increasing difficulty (maybe exponentially
increasing, even :-)) but yes, these sound like good action items.

Thanks for your feedback!

Ludo’.

Re: [EXT] Re: Enterprise Guix Hosting?

[Ludovic Courtès]

Hello!

"Thompson, David"  skribis:

> 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?

Agreed!  We could turn Ricardo’s code into ‘container-guest-service’ or
something and have ‘containerized-operating-system’ add it
automatically.

Ludo’.

Renaming ‘master’ to ‘main’

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> On 2022-08-06, Tobias Geerinckx-Rice wrote:
>> On 2022-08-06 20:48, Tobias Geerinckx-Rice wrote:
>>>   guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723
>>>   not signed by an authorized key:
>>>   2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0
>>
>> I tried a few other random things to wriggle out of this but I think 
>> we're stuck (which is, design-wise, probably a good thing).
>
> What a great opportunity to switch to using "main" instead of "master"
> anyways. :)

Yes, this is something we should do.  There’s preliminary work here:

  https://issues.guix.gnu.org/49252

I eventually lost track of what the problem was, but we should resume.

Ludo’.

Re: managing waiting patches

[Ludovic Courtès]

Hello Nicolas,

Thanks for your message.  Patch review is overall rather slow due to a
mixture of Guix being a victim of its success and (perhaps more
importantly) having too few people devoting time to patch review, and
too few committers committing.

This was discussed recently on guix-devel and I hope we can collectively
improve on that.  The new teams that we devised (see ‘etc/teams.scm’)
should help, though we have yet to document them and publicize them.

Nicolas Graves via  skribis:

> 1) how to manage and track series of patches one makes in his local repo
> copy.
>
> For that, I will take a practical example.
>
> I made some rust patches a few days ago. The final goal of these first
> patches would have been to add the package swayr@0.20, which is huge
> when imported with recursive guix import (~2k lines). So I did split the
> task in a few subgoals, by trying to first update packages that are
> already present. By only doing that, I already had a stack of ~15
> commits. I couldn't contribute more at that moment, so I sent them in
> the hope that they would get merged before a next partial goal.

I don’t have any great suggestion here—you already seem to be doing
things rationally.  In general, short, to-the-point patch series are
more likely to be reviewed quickly, so that’s one strategy you can adopt
here.  And then you can locally keep branches for each part of the
broader patch series, possibly rebasing them until they’re applied.

> 2) how to get one's patches to pass.
>
> Another problematic I encounter is having to wait for a patch series to
> pass to send another one. Another example.
>
> I'm developing in my free time for an organisation using wagtail CMS for
> its website. I thought that it would be a great occasion to send some
> packages for guix, and get some experience with packaging. So I worked
> on that and send some patches (55476 55475 55474 55473). They are pretty
> clean (almost all tests enabled, tested as a user) (except maybe for
> descriptions, I'm not sure I remember for that).
>
> At some point, wagtail made an upgrade to version 3.0.1, and I started
> to update my packages locally, but don't want to make a totally new
> series of patches while the previous was not accepted. In the meantime,
> I send patches 56296 which would have been useful for later and actually
> fixes some failing packages. I'm now stuck on this contributing task
> because of this.

I can sympathize.  :-/

You could send an updated patch series with the new version as v2; that
would also serve as a reminder for reviewers.

Using ./etc/teams.scm you can also look for people working in this area
that you could ping.

Last, if you’re on IRC, you’re welcome to occasionally ping people
there.

[...]

> What should I do in this case? Should I try to become a committer
> myself? Have a "committer buddy" that can merge my sent packages? Keep
> working in a personal channel or a channel like guixrus and rely on that
> additionally to relying on guix? Other options?
>
> Thanks a lot for your answer, sorry if I don't have very acute developer
> workflows, I'm only doing this in my free time ;)

Understood!  You can always keep your work in a channel of yours until
it’s merged.  I do encourage you to work to get it in Guix proper
though, because in the end everyone benefits.  I hope we can all work to
reduce the bottleneck.

Thanks,
Ludo’.

Re: Enterprise Guix Hosting?

[Ludovic Courtès]

Hi Phil,

Phil  skribis:

> My own experience is that whilst it doesn't require a PhD to setup Guix
> for the enterprise, it is a non-trivial journey, and it does require
> a fair amount of time and effort to create something that regular
> developers/scientists (i.e. non-Guix converts who just want to get on with 
> their
> day-jobs) accept is as good or better than regular tooling they are used
> to.  There's certainly a barrier to entry for people who don't want to
> do a deep-dive and just want tooling to support them in their professional
> role, without them having to think about it too much.
>
> Upselling the real benefits of Guix like rollbacks, profiles, perfectly
> reproducable builds, swapping one dependency for another - even in a
> scientific/tech-savvy company with lots of PhDs took a bit of persuading
> from me. Even now I think our company is only using perhaps 30% of the
> true power of Guix.  Making all that power accessible to people who just
> want to get on with their jobs in an easy, intuitive way is a challenge
> I'm continuously trying to address.  I also hope things like PantherX
> might help bridge the gap in the near future! 

>From your experience, would you say that persuading was hard primarily
because Guix was unknown (to them), or because getting started is
difficult?

Personally I think we need to make Guix approachable to a wide audience,
meaning not just developers—that goes beyond your target audience, let’s
be ambitious!  I’d like to think that ‘guix install’, ‘guix shell’, and
the likes have a rather low barrier to entry to someone who’s use the
command line before, but I’ve also seen newcomers confused because
“environment variables are hard” and get in the way.

Are there any takeaways from your experience in terms of UX/UI
improvements we could work on?

Thanks,
Ludo’.

Re: partial guix pack?

[Ludovic Courtès]

Hi,

Andy Tai  skribis:

> Can a guix pack be partial?  By that I meant one package that is not
> completely stand alone but only contains a subset of needed software,
> bundled libraries.  for example, one that bundles specific version of
> gtk+ but not glibc?  Of course such a package depends on host glibc
> and may have the risk of breakage but it is likely low risk if the
> main problem is it needs specific version of gtk+.

Currently there’s no way to do that.

We could implement a feature that removes certain store items from the
pack, say glibc.  But then, all the binaries in the pack have Guix’s
glibc in their RUNPATH and executables have its loader as an ELF
interpreter.  So that process would need to rewrite RUNPATHs and INTERPs
to those commonly found on FHS distros… not impossible, but a bit
tedious just to end up with binaries that may or may not work.

Ludo’.

Re: uninstall/unmanage guix home on my foreign system

[Ludovic Courtès]

Hi jgart,

jgart  skribis:

> How can I "uninstall" guix home or have it not manage my dotfiles or a 
> particular subset of dotfiles that I no longer want managed?

Good question; I don’t think there’s an easy way to escape, it’s a bit
of a trap.  :-)

What I would do is something like this (untested):

  1. Make sure packages you need are installed on the system or in
 ~/.guix-profile, by running, say:

   guix package --export-manifest -p ~/.guix-home/profile/manifest > \
 ~/my-manifest.scm

   guix package -m ~/my-manifest.scm

   2. Restore dot files that were managed by Guix Home, for example by
  copying your original dot files from a backup such as the one
  created by ‘guix home reconfigure’:

for i in .bashrc .bash_profile # add others here
do
  rm "$HOME/$i"
  cp -v "$HOME/guix-home-backup-whatever-its-called/$i" "$HOME"
fi

   3. Remove your home profile:

   rm -v ~/.guix-home /var/guix/profiles/per-user/$USER/guix-home*

IWBN to have a ‘guix home’ subcommand to do that automatically.

HTH!

Ludo’.

Re: Garbage Collector

[Ludovic Courtès]

Hi,

Felix Lechner via  skribis:

> On Mon, Jul 25, 2022 at 2:52 AM Gottfried  wrote:
>>
>> The manual says that it is dangerous to use: "guix gc"
>> because it can delete too much.
>
> I agree that 'guix gc' deletes too much, but it's probably not
> dangerous. You will just see some downloads and builds repeated when
> reconfiguring later.

Indeed, it’s not dangerous, and I don’t think the manual suggests that.

To avoid collecting things just to redownload/rebuild them later, I
usually ask ‘guix gc’ to free up some amount of space, as in:

  guix gc -F20G

That ensures 20G (more or less) are available on my disk and doesn’t try
to collect more than that.

Thanks,
Ludo’.

Re: Debugging cross-compilation dependencies

[Ludovic Courtès]

Hello!

"Philip McGrath"  skribis:

> Much to my surprise, I discovered I can avoid the problem by changing code 
> for #:make-flags like this:
>
> ```
> #~(string-append "ZUO="
>   #$(this-package-native-input "zuo")
>   "/bin/zuo"))
> ```

You should prolly use ‘ungexp-native’ (aka. #+) instead of ‘ungexp’ (#$).

  #~(string-append … #+(this-package-native-input "zuo") …)

HTH!

Ludo’.

Re: Debugging cross-compilation dependencies

[Ludovic Courtès]

Hello!

"Philip McGrath"  skribis:

> Much to my surprise, I discovered I can avoid the problem by changing code 
> for #:make-flags like this:
>
> ```
> #~(string-append "ZUO="
>   #$(this-package-native-input "zuo")
>   "/bin/zuo"))
> ```

You should prolly use ‘ungexp-native’ (aka. #+) instead of ‘ungexp’ (#$).

  #~(string-append … #+(this-package-native-input "zuo") …)

HTH!

Ludo’.

Ten Years of Guix: preliminary program available!

[Ludovic Courtès]

Hello!

We’re excited to announce a preliminary program for the Ten Years of
Guix event that will take place in Paris, France, Sept. 16th–18th!

  https://10years.guix.gnu.org/program/

On Friday, scientists and practitioners will talk about how they address
computational reproducibility in their domain, using Guix and using
other tools, including Nix and Maneage.

We’ll also see how Software Heritage helps bridge the gap, both at a
technical level and for software citation and referencing, and we’ll
learn about OCaml bootstrapping and a vision for RISC-V and Guix.

The community-oriented program for Saturday and Sunday is work in
progress and there’s already a good set of topics brought to the table,
whether you want to learn about Guix, to get started contributing, to
discuss ways to improve it, or to dive into technical matters.

Please email guix-birthday-ev...@gnu.org if you’d like to facilitate a
brainstorming session or a hacking session, or if you’d like to share
about your favorite use case, Guix subsystem, and whatnot!

Make sure to register so you get your share of the birthday cake! :-)

Ludovic, Simon, and Tanguy.


signature.asc
Description: PGP signature

Ten Years of Guix: Call for contributions

[Ludovic Courtès]

Hello Guix!

The Ten Years of Guix  event in Paris, 16–18 September, is shaping up,
and you can register!

  https://10years.guix.gnu.org/

(There’s spam in the comment section of the registration form that we
can’t fully block, but it’s functional.)

We’re planning to announce the program for Friday 16th, which focuses on
uses of Guix in research, within a couple of weeks.  There will be room
for lightning talks too.

For Saturday/Sunday, we already have a couple of nice talks and
discussions scheduled (surprise! :-)), but we’d love to have more of
them from you!  It could be “getting started” kind of talks for
newcomers, demos, discussions on specific topics; for Sunday, it could
be more in-depth hacking sessions or community discussions.

Email Simon, Tanguy, and myself at guix-birthday-ev...@gnu.org or reply
to this thread for proposals and questions.

Ludo’.

Re: bug#55359: How do I extend openssh-service-type ?

[Ludovic Courtès]

Hi,

Oleg Pykhalov  skribis:

>> (service-extension openssh-service-type
>>(const `(("charlie"
>>  ,(local-file "charlie.pub")
>> #+end_quote
>
> […]
>
> Seems like extend-openssh-authorized-keys procedure does not use keys
> argument. We could fix it like:

For the record, this bug (dismissing the ‘keys’ argument) was introduced
in b4b2bbf4fb74c9f3e93d64863ab9b38957494b49 (Oct. 2021).

How come nobody noticed then?

The reason is that starting from
b4b2bbf4fb74c9f3e93d64863ab9b38957494b49, ‘authorized-key-directory’
would create an empty directory.  That directory would then be copied by
‘openssh-activation’ to /etc/ssh/authorized_keys.d; since
/etc/ssh/authorized_keys.d would typically already contain the relevant
keys, nothing bad would happen.

Oleg’s commit 1f29ed4a812f86c45e2d9c37fd9f80f6d0418293 introduced
another bug though: we’d create an authorized-key directory that
included keys brought by extensions, but each of these files would be
empty (because ‘extend-openssh-authorized-keys’ would dismiss key files
associated with user names), which could lock yourself out.

Fixed in 0dc63ce519c5f98b2186d1871176e2fac3a6926b.  Reconfiguration
recommended before you’re locked out!

Thanks,
Ludo’.

Re: bug#55359: How do I extend openssh-service-type ?

[Ludovic Courtès]

Hi,

Oleg Pykhalov  skribis:

> Seems like extend-openssh-authorized-keys procedure does not use keys
> argument. We could fix it like:
>
> diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm
> index 7fbbe383e5..4bb3969b95 100644
> --- a/gnu/services/ssh.scm
> +++ b/gnu/services/ssh.scm
> @@ -558,7 +558,7 @@ (define (extend-openssh-authorized-keys config keys)
>(openssh-configuration
> (inherit config)
> (authorized-keys
> -(match (openssh-configuration-authorized-keys config)
> +(match (append (openssh-configuration-authorized-keys config) keys)
>(((users _ ...) ...)
> ;; Build a user/key-list mapping.
> (let ((user-keys (alist->vhash

Indeed.  Please push!

Thanks,
Ludo’.

Re: Packaging Slurm

[Ludovic Courtès]

Hi!

Jean-Christophe HAESSIG  skribis:

> # strace -f -E GUIX_EXECUTION_ENGINE=fakechroot -E 
> LD_LIBRARY_PATH=/opt/slurm/gnu/store/j417whqiy5gz2rbmlnknla3wl43jgk1z-profile/lib/
>  
> /opt/slurm/sbin/slurmdbd -D

[...]

> The program hangs from there and is inoperative. The socket to the 
> database, which is in mode ugo+rwx is successfully used once, then the 
> program fiddles with its groups, gid, uid and then can't open it 
> anymore. I see that the /tmp/guix-exec- directory is created with 
> 0700 rights, which means it cannot be traversed anymore when the uid of 
> the program has changed.

Woow, interesting.  Clearly relocatable packs were primarily intended
for “regular” programs (not daemons), which is why you’re making these
interesting discoveries.  :-)

Off the top of my head, I’m not sure what the solution could be.  If you
feel so inclined, you can take a look at run-in-namespace.c in Guix,
which implements those execution engines.

>> Where “battle from /gnu/store” is the chicken-and-egg when booting,
>> right?  (That is, if /gnu/store is on NFS, then how do you boot.)
>
> Sure, it is even a problem with guix on a foreign distro, if you need 
> some of the software to be managed locally and the rest by shared nfs.
> My best bet would be to have guix recompiled to use an alternate 
> location as the store and the statedir, have it manage the local system 
> and let regular users take advantage of substitutes. I don't feel this 
> would be straightforward however.

Indeed; in general, using a non-standard store directory is a bad idea,
for many reasons (no substitutes, risks of failing builds just because
of the different store directory length, etc.).

I wonder if there might be a solution where you’d overlay the local
/gnu/store on top of the NFS-mounted store, something like that.  But I
don’t have the full picture of the setup you have.

Thanks,
Ludo’.

Re: Packaging Slurm

[Ludovic Courtès]

Hello,

Jean-Christophe HAESSIG  skribis:

> I don't really know what the implications of this would be. I continued 
> exploring packaging Slurm with Guix and deploying it on Debian.
> I feel what i'm trying to do is slightly out of scope of Guix's intent : 
> I used guix pack with various options -R, -RR but these are made to 
> enable regular users to run software from guix packages. When the 
> software is intended to be run by root, things seem to go awry. I had 
> errors because the program tries to switch user and groups.
>
> --
> mount("none", "/tmp/guix-exec-C6ZnPc", "tmpfs", 0, NULL) = 0
> clone(child_stack=NULL, flags=CLONE_NEWNS|CLONE_NEWUSER|SIGCHLD) = 4061
> openat(AT_FDCWD, "/proc/4061/setgroups", O_WRONLY) = 3
> write(3, "deny\0", 5)   = 5
> close(3)= 0
> getuid()= 0
> --
>
> and later :
>
> --
> [pid  4061] newfstatat(5, "", {st_mode=S_IFREG|0644, st_size=10406312, 
> ...}, AT_EMPTY_PATH) = 0
> [pid  4061] setgroups(2, [3000, 51692]) = -1 EPERM (Operation not permitted)
> [pid  4061] poll([{fd=2, events=POLLOUT}], 1, 5000) = 1 ([{fd=2, 
> revents=POLLOUT}])
> [pid  4061] newfstatat(2, "", {st_mode=S_IFIFO|0600, st_size=0, ...}, 
> AT_EMPTY_PATH) = 0
> [pid  4061] write(2, "slurmdbd: fatal: Failed to set s"..., 89slurmdbd: 
> fatal: Failed to set supplementary groups, initgroups: Operation not 
> permitted
> --

Can you try with:

  GUIX_EXECUTION_ENGINE=fakechroot ./bin/sulrmbdb …

assuming you’re using a -RR pack?

> When the program is directly run with its final system user account, it 
> starts correctly, still complains about not being able to fiddle with 
> groups but doesn't crash:
>
> slurmdbd: Not running as root. Can't drop supplementary groups
>
> I only got this to work with -RR. -R got me other permission errors 
> about not being able to setup subuid/subgid. System is Debian 10.9 with 
> kernel 4.19. I expected containers to be well available and didn't know 
> if the errors could come from what the program tries to do as root so I 
> didn't check thoroughly yet.

Yeah, presumably things running in an unprivileged user namespace (this
is the case with -R and also with GUIX_EXECUTION_ENGINE=userns) can’t
call setgroups(2).

>> This would be a welcome change, though it would have a noticeable impact
>> on the closure size:
>> 
>> --8<---cut here---start->8---
>> $ guix size slurm |tail -1
>> total: 134.7 MiB
>> $ guix size slurm mariadb |tail -1
>> total: 421.4 MiB
>> --8<---cut here---end--->8---
>
> I don't know if this could change anything but AFAIK mariadb is a 
> dependency of slurmdbd only. Debian has separate packages for the 
> accounting daemon, the controller daemon (slurmctld) and the client 
> (slurmd) but there still is one source package.

Here we could have a separate output maybe:

  
https://guix.gnu.org/manual/devel/en/html_node/Packages-with-Multiple-Outputs.html

[...]

> For the time being, I'm still confident it can be done somehow, at least 
> temporarily to enable a smooth upgrade. There are some minor hurdles 
> e.g. Debian decided to change the paths in etc, var and the like to 
> slurm-llnl. I managed to build several versions from git, I'm still 
> blocked with 18.08 which doesn't compile because of "multiple definition 
> of 'opt'". Only thing I can think of is something is too recent wrt 
> slurm version.

FWIW I recently fixed that build error in Guix:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=dd98dc42fe8d898bbdf8b3f988120a81bb145f77

> I guess running Guix system would remove many problems but I'm not ready 
> for that and since I'm interested in the shared software use case for a 
> cluster, there would still remain the "battle for /gnu/store" issue.

Where “battle from /gnu/store” is the chicken-and-egg when booting,
right?  (That is, if /gnu/store is on NFS, then how do you boot.)

HTH,
Ludo’.

Re: Replacing a package system-wide

[Ludovic Courtès]

Hello,

Dominic Martinez  skribis:

> One of the things I love about Guix is how easy it is to modify 
> dependencies, a feature I use fairly often on individual packages 
> or manifests. However, I'm struggling to get a similar effect 
> system-wide.
>
> Grafts do exactly what I want, but since they are defined in the 
> upstream package definition I can't set them for my personal 
> system. Package rewriting lets me do this on a plain list of 
> packages, but it's really difficult to do the same for services 
> and not possible for guix shell/other command line usage.
>
> #+begin_src scheme
> (operating-system
>  ;; Package rewriting makes this fairly straight-forward
>  (packages (fix-pkg %my-packages))
>
>  ;; But for packages deep in the dependency tree, you have to
>  ;; track down every service that has this package as a transient
>  ;; dependency and fix it.
>  (services
>   (service some-pkg-service-type
>(some-pkg-service-configuration
> (some-pkg-service (fix-pkg pkg
>
>   ;; Repeat ad-nauseum
>   ))
> #+end_src

This is correct: there’s currently no general package-rewriting
mechanism for ‘operating-system’ as a whole.  As a result, you have to
customize individual services like you show above.

I agree it would be nice to offer a programatic way to replace packages,
though I’m not sure what it should look like.

Right now it’s tricky to peek at all the packages that services refer
to, because in the end, these references are embedded in gexps that are
“lowered” to files such as Shepherd service definitions.  We would need
a hook (at the gexp level? at a higher level?) to interpose on all
package references that get lowered.

Food for thought…

Ludo’.

Re: Problem when packaging Avizo

[Ludovic Courtès]

Hi Pier-Hugues,

Pier-Hugues Pellerin  skribis:

> In guix/status.scm:
>645:15  4 (_ (build-log 4365 "[1/11] Generating avizo-resource…") #)
>179:23  3 (update-build #< building: () downloadin…> …)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1 (expecting
> struct): #f

It looks like you hit a genuine bug, similar to
.

Does it happen every time you try to build this package?

Does it happen when you build with ‘--max-jobs=1 --no-offload’?

Thanks in advance,
Ludo’.

Re: Can't open a container-shell

[Ludovic Courtès]

Hi,

Dominic Martinez  skribis:

> Is there a specific reason you included the --profile flag? I think
> you'll probably get the behaviour you imagine without it.

Agreed, you should drop ‘--profile’, Cássio.

HTH,
Ludo’.

Re: missing files from aspell-dict package

[Ludovic Courtès]

Hi,

vapnik spaknik  skribis:

> I have installed the latest versions of aspell & aspell-dict-en via guix on a 
> foreign distro:

Normally ~/.guix-profile/etc/profile does:

  export ASPELL_DICT_DIR="$HOME/lib/aspell“

Can you confirm that’s the case?

[...]

> The aspell installation contains cset & cmap files in its lib/aspell-0.60/ 
> subdir, but no dat files, whereas the aspell-dict-en contains dat files but 
> not cset or cmap files. However, aspell expects them to be in the same 
> directory, as they are in the debian aspell package (in /usr/lib/aspell).

I’m not familiar enough with Aspell.  Do you think this is a
misconfiguration of the ‘aspell-dict-en’ package and possibly other
‘aspell-dict-’ packages?

--8<---cut here---start->8---
$ find $(guix build aspell-dict-fr ) -name \*cset
$ find $(guix build aspell-dict-fr ) -name \*cmap
$ find $(guix build aspell-dict-en ) -name \*cmap
--8<---cut here---end--->8---

Let us know if you have clues on how to fix it.

TIA,
Ludo’.

Re: Nss libraries not found when using guix pack

[Ludovic Courtès]

Salut Jean-Christophe,  :-)

Jean-Christophe HAESSIG  skribis:

> On 02/03/2022 10:46, Jean-Christophe HAESSIG wrote:
>
>> I tried to deploy Slurm using guix pack :
>> guix pack -R -S /sbin=sbin -S /bin=bin slurm@19.05.8 nss-pam-ldapd sssd
>> 
>> User and authentication data comes from ldap (sssd). The libraries are
>> present but the Slurm binary does not find them, and fails with an
>> invalid user error.
>
> I jumped that hurdle with LD_PRELOAD, but this is not an acceptable fix 
> of course.

Yeah, I did something similar in the past:

  https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00168.html

Maybe we could have a package transformation option, say
‘--with-nss-plugins=…’, that would wrap binaries to have LD_LIBRARY_PATH
pointing to the chosen NSS plugins.

Not pretty, but I’m afraid this is hardly avoidable.

Thoughts?

> However, I did that only to realize that Slurm in guix is compiled
> without mysql support, so I'll need to change the package, which I
> have never done.

This would be a welcome change, though it would have a noticeable impact
on the closure size:

--8<---cut here---start->8---
$ guix size slurm |tail -1
total: 134.7 MiB
$ guix size slurm mariadb |tail -1
total: 421.4 MiB
--8<---cut here---end--->8---

> I wanted to use Slurm from Guix because Debian does not provide every 
> possible Slurm version. This can be a problem when a Slurm cluster must 
> be upgraded without shutting it down completely. I hoped to gain some 
> independence from my host distribution but it appears that won't be so 
> simple...

Interesting.  From our earlier discussion, this sounds like quite an
endeavor, but I’d be curious to know what the stumbling blocks are and
how we can overcome them!

Thanks,
Ludo’.

Re: Run a system command in home configuration file

[Ludovic Courtès]

Hi,

Reza Housseini  skribis:

> I want to run a system command and use the output inside my ssh config
> file. Below is the service configuration I'm talking about and my current
> implementation which does not work, probably because the command is run
> from the daemon, but I need it to run from the current user. Has anyone an
> idea how to achieve this?
>
> (simple-service 'ssh-config
>  home-files-service-type
>  (list `("ssh/config"
>  ,(mixed-text-file "config" "
> Host *
>   IdentityAgent " #~(system* #$(file-append gnupg "/bin/gpgconf")
> "--list-dirs" "agent-ssh-socket") "
> "

Instead of #~(system* …) above, you could do something like:

  (let* ((pipe (open-input-pipe "gpgconf" …))
 (data (get-string-all pipe)))
(close-pipe pipe)
data)

The effect will be that ‘gpgconf’ will run when you invoke ‘guix system
reconfigure’, as the user who invokes it.  (You need the (ice-9 popen)
and (rnrs io bytevectors) modules.)

I can’t necessarily recommend it because it’s kinda wild, but it should
do the trick.

HTH,
Ludo’.

Re: libre office German and IceCat in German

[Ludovic Courtès]

Hallo Gottfried,

Gottfried  skribis:

> I installed libre office and it installed it in English.
> But I would need the German version
> How can I get the German version in guix?
>
> the same in IceCat

Unfortunately, we lack packages for “locale data” (translations) of
these two programs.  The reason is that they both have a peculiar way of
dealing with that, different from what other packages do.

I think we should fix it.

Thanks,
Ludo’.

Re: Changed tty setting upon exiting docker run

[Ludovic Courtès]

Hi,

phodina via  skribis:

> I've recently discovered an issue with running docker images. Upon exit I 
> can't see any characters I type. The settings of my tty are changed for some 
> reason.
>
> They can be fixed by running stty sane but I'd like to ask if somebody also 
> has this issue?
>
> Here's what happens:
>
> $ stty
> speed 38400 baud; line = 0;
> -brkint -imaxbel
> $ docker run --rm -it ubuntu
> root@a0a76c5fdd94:/# stty
> speed 38400 baud; line = 0;
> -brkint -imaxbel
> root@a0a76c5fdd94:/# exit
> $stty
> speed 0 baud; line = 0;uix$
> intr = ; quit = ; erase = ; kill = ; eof = 
> ; start = ; stop = ; susp = ;
> rprnt = ; werase = ; lnext = ; discard = ; min = 
> 0; time = 0;
> -brkint -icrnl -imaxbel
> -opost -onlcr
> -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
> $ stty sane
> $ stty
> speed 0 baud; line = 0;
>
> If I run the command without the '-t' argument it does not augment the tty 
> but also the tty in docker is not usable.

So it’s when you leave the container that tty properties change, right?

How did you create this container image?

If it was created with ‘guix system container’, it might contain (?)
Shepherd services like ‘term-tty1’, which I thought could interfere with
the host system, but I’m not sure.

Thanks,
Ludo’.

Re: Guix Channel News File Extension

[Ludovic Courtès]

Hi,

jgart  skribis:

> Do we still have to avoid calling the channel file with a .scm extension?
>
> I see that the manual specifies to avoid its use but if I look in a guix
> checkout I see that the channel file is called with a .scm extension:
>
> etc/news.scm

Good point.  The news file should either not have the .scm extension, or
it should live in a directory other than the module directory specified
in ‘.guix-channel’.

HTH!

Ludo’.

Re: Permanently available environments

[Ludovic Courtès]

Hi Konrad,

Time has passed…

Konrad Hinsen  skribis:

> Konrad Hinsen  writes:
>
>> 1. Containers can only be generated using "guix shell" or the older
>>"guix environment". There is no way to generate a container based
>>on a profile. Correct me if I am wrong!
>
> Thanks to Ricardo and Guillaume, who pointed out the –profile option to
> "guix shell", which does exactly what I need. I missed it because it is
> not mentioned in the manual. I just submitted a patch.

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

  guix time-machine -C channels.scm -- shell -m manifest.scm

Both tools cache their result, with a GC root (similar to what you would
do with ‘--root’), and reuse it (similar to ‘--profile’).  These two GC
roots may be removed if you’ve not touched them for some time, at which
point ‘guix gc’ can potentially remove these profiles.

Would it work for you?

I’m more comfortable recommending this than asking people to manually
manage cached profiles and GC roots.

Thanks,
Ludo’.

Re: Valgrind not working

[Ludovic Courtès]

Hi Andreas,

Andreas Enge  skribis:

> valgrind:  Fatal error at startup: a function redirection
> valgrind:  which is mandatory for this platform-tool combination
> valgrind:  cannot be set up.  Details of the redirection are:
> valgrind:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:  strlen
> valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
> valgrind:
> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
> valgrind:  package on this machine.  (2, longer term): ask the packagers
> valgrind:  for your Linux distribution to please in future ship a non-
> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind:  that exports the above-named function using the standard
> valgrind:  calling conventions for this platform.  The package you need
> valgrind:  to install for fix (1) is called
> valgrind:
> valgrind:On Debian, Ubuntu: libc6-dbg
> valgrind:On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
> valgrind:
> valgrind:  Note that if you are debugging a 32 bit process on a
> valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
> valgrind:  package (e.g. libc6-dbg:i386).
> valgrind:
> valgrind:  Cannot continue -- exiting now.  Sorry.

I’m late to the party, but here’s the trick you can use:

--8<---cut here---start->8---
$ guix build -e '(@@ (gnu packages commencement) glibc-final)' 
/gnu/store/xgarlnscgbm9l04karj15xpc4nn14ak1-glibc-2.33-debug
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33
/gnu/store/4jdghmc65q7i7ib89zmvq66l0ghf7jc4-glibc-2.33-static
$ valgrind 
--extra-debuginfo-path=/gnu/store/xgarlnscgbm9l04karj15xpc4nn14ak1-glibc-2.33-debug/lib/debug
 uname -o
==16741== Memcheck, a memory error detector
==16741== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16741== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==16741== Command: uname -o
==16741== 
GNU/Linux
==16741== 
==16741== HEAP SUMMARY:
==16741== in use at exit: 0 bytes in 0 blocks
==16741==   total heap usage: 2,813 allocs, 2,813 frees, 184,302 bytes allocated
==16741== 
==16741== All heap blocks were freed -- no leaks are possible
==16741== 
==16741== For lists of detected and suppressed errors, rerun with: -s
==16741== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--8<---cut here---end--->8---

I think the reason it no longer works out of the box is because we
now[*] use ‘--strip-unneeded’ instead of ‘--strip-debug’, since commit
e0f31baacc6ad30096a332b69433c85f5830bb2c.

We’d need to double-check the hypothesis and fix it on ‘core-updates’.

In the meantime, HTH!

Ludo’.

[*] Effective end of December 2021, when ‘core-updates’ was merged into
‘master’.

Re: packaging a golang package

[Ludovic Courtès]

Hi,

adfeno--- via  skribis:

> If by vendoring we mean bundling and also make users fetch data from places 
> not explicitly committed to the GNU FSDG, then allow me to jump in to add 
> some important notes.
>
> Em 27/01/2021 11:31, Katherine Cox-Buday escreveu:
>> As a packager for a distribution, I dislike vendoring because of the
>> reasons you outlined above, _but_ I also dislike building upstream
>> software with versions of dependencies that weren't approved, tested,
>> and verified, upstream. It seems to me like that's a recipe for
>> unstable, maybe even insecure, software.
>
> I also agree that this would be problematic, but I fear that if we surrender 
> to vendoring, we might defeat the purpose of GNU Guix.

I sympathize with that feeling.

It’s definitely a hard problem.  Even Debian, which has been a
lighthouse for many on these matters, recently gave up:

  https://lwn.net/Articles/843313/

I think both Katherine’s concerns and yours are valid.

IMO, the importer should be able to import things recursively and assume
we’re not going to bundle anything.  It’d be up to the packager, then,
to opt out and selectively use bundled copies of dependencies, if and
when that appears necessary.

> I'm OK with the importer approach but, *in my opinion*, I don't think this 
> tackles the true issue described on the 4th paragraph of the “License Rules” 
> described on the GNU FSDG ([1]), this is why I opened Guix bug #45450 ([2]).

IMO, ‘guix import’ does not “steer users towards obtaining any nonfree
information” any more than wget does.  It’s a tool for packagers that
returns a package definition or template thereof, and it’s up to the
packager to decide what to do with it.

Thanks,
Ludo’.

Re: Fast `guix environment --container' switch

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

> `guix environment --container ... -- my-foo-program` is great but a bit
> slow to start.
>
> Is there a way to speed this up?

The attached program (based on an experiment from 2018¹ with exciting
yet to date mythical prospects) picks a program from $PATH (typically
from your profile) and runs it in a container.  As in:

  guix run inkscape

It has less work to do compared to ‘guix environment’ so it is faster.

HTH!

Ludo’.

¹ https://lists.gnu.org/archive/html/help-guix/2018-01/msg00117.html

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018, 2019, 2020 Ludovic Courtès 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(define-module (guix scripts run)
  #:use-module (guix ui)
  #:use-module (guix utils)
  #:use-module (guix scripts)
  #:use-module (guix store)
  #:use-module (guix packages)
  #:use-module (guix derivations)
  #:use-module ((guix build utils) #:select (which mkdir-p))
  #:use-module (gnu build linux-container)
  #:use-module (gnu system file-systems)
  #:use-module (gnu packages)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-9 gnu)
  #:use-module (srfi srfi-11)
  #:use-module (srfi srfi-26)
  #:use-module (srfi srfi-37)
  #:use-module (ice-9 match)
  #:export (guix-run))

(define %options
  (list (option '(#\h "help") #f #f
(lambda args
  (show-help)
  (exit 0)))
(option '(#\V "version") #f #f
(lambda args
  (show-version-and-exit "guix run")

(define (show-help)
  (display (G_ "Usage: guix run PACKAGE COMMAND...
Run COMMAND from PACKAGE in a container.\n"))
  (newline)
  (display (G_ "
  -h, --help display this help and exit"))
  (display (G_ "
  -V, --version  display version information and exit"))
  (newline)
  (show-bug-report-information))



(define (bind-mount-spec/ro item)
  (and (file-exists? item)
   (file-system
 (device item)
 (mount-point item)
 (type "none")
 (flags '(bind-mount read-only))
 (check? #f

(define (bind-mount-spec/rw item)
  (and (file-exists? item)
   (file-system
 (inherit (bind-mount-spec/ro item))
 (flags '(bind-mount)

;; Safe in which applications run.
(define-immutable-record-type 
  (safe namespaces mappings)
  safe?
  (namespaces  safe-namespaces)
  (mappingssafe-mappings))

(define (application-safe items)
  "Return safe corresponding to the application whose dependencies are listed
in ITEMS."
  (define packages
(map (compose (cut package-name->name+version <> #\-)
  store-path-package-name)
 items))

  (define x11? (member "libx11" packages))
  (define dbus? (member "dbus" packages))
  (define alsa? (member "alsa-lib" packages))
  (define pulseaudio? (member "pulseaudio" packages))

  (define mappings
(let-syntax ((if (syntax-rules ()
   ((_ condition body)
(if condition
(or (and=> body list) '())
'()
 (ro (identifier-syntax bind-mount-spec/ro))
 (rw (identifier-syntax bind-mount-spec/rw)))
  `(,(rw "/var/run/nscd/socket")
,@(if x11? (rw (string-append (getenv "HOME") "/.Xauthority")))
,@(if x11? (rw "/tmp/.X11-unix"))
,@(if x11? (rw (string-append "/run/user/"
  (number->string (getuid)
,@(if dbus? (ro "/etc/machine-id"))
,@(if alsa? (rw "/dev/snd"))
,@(if pulseaudio? (rw (string-append (getenv "HOME") "/.pulse"))

  (define namespaces
;; X11 applications need to run in the same IPC namespace as
;; the server.
(if x11?
(fold delq %namespaces '(ipc net))
%namespaces))

  (safe namespaces mappings))

(define %not-colon
  (char-set-complement (char-set #\:)))

(define (guix-run . args)
  (define (parse-options)
;; Return the alist of option values.  With this hack, the first
;; non-option argument is considered to be the be

Re: Welcome to Grub!... for a minute

[Ludovic Courtès]

Hi Yasuaki,

Yasuaki Kudo  skribis:

> I just wanted to report (although this is probably already known) that I had 
> to wait for a long time (probably more than a minute) staring at "Welcome to 
> Grub!" screen upon reboot, after accumulating thousands of guix system 
> generations.  I was experimenting with something and I suspected that was the 
> cause - sure enough, after deleting them all with guix system 
> delete-generations command, the delay disappeared.

Oh, good to know.  I never went as far as having thousands (thousands,
really?) of system generations, so I never noticed (I probably have 15
or so at most), and probably that’s the case for most people.

Thanks,
Ludo’.

GNU Guix 1.2.0 released

[Ludovic Courtès]

We are pleased to announce the release of GNU Guix 1.2.0, which also
marks the eighth anniversary of Guix today.

This release corresponds to 10,248 commits over 6.5 months by 201 people.
It includes many new features, user interface and performance
improvements, as well as many bug fixes—see below for a list of changes.

Read more about today’s announcement at:

  https://guix.gnu.org/en/blog/2020/gnu-guix-1.2.0-released

• About

  GNU Guix is a transactional package manager and an advanced
  distribution of the GNU system that respects user freedom.  Guix can
  be used on top of any system running the Hurd or the Linux kernel, or
  it can be used as a standalone operating system distribution for i686,
  x86_64, ARMv7, and AArch64 machines.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  When used as a
  standalone GNU/Linux distribution, Guix offers a declarative,
  stateless approach to operating system configuration management.  Guix
  is highly customizable and hackable through Guile programming
  interfaces and extensions to the Scheme language.

  https://guix.gnu.org

• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/guix/guix-1.2.0.tar.gz
https://ftp.gnu.org/gnu/guix/guix-1.2.0.tar.gz.sig

  Here are the bootable USB installation images and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz
https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.i686-linux.iso.xz.sig
https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz

https://ftp.gnu.org/gnu/guix/guix-system-install-1.2.0.x86_64-linux.iso.xz.sig

  Here is the QCOW2 virtual machine (VM) image and its signature[*]:
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.2.0.x86_64-linux.xz
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.2.0.x86_64-linux.xz.sig

  Here are the binary tarballs and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.i686-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.i686-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.x86_64-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.x86_64-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.armhf-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.armhf-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.aarch64-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.2.0.aarch64-linux.tar.xz.sig

  Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
  
  Here are the SHA256 checksums:

  5ecdf7ced25b1fb0ca7c57e794b7b60c8a7adcb15261dec2af37925c838c6d74  
guix-1.2.0.tar.gz
  639cd9f4d55d59819a96eda966794be191378347cd857d2a47cbab6087a4b759  
guix-binary-1.2.0.aarch64-linux.tar.xz
  101fe55a68217ba213d68b53cf1935fe7119406d5652243b3d651beb3cb43f62  
guix-binary-1.2.0.armhf-linux.tar.xz
  4ab083925be76cd4887e44de0a3bd37aa6c89b09a9cbc9d897d0f701dbb0ddf6  
guix-binary-1.2.0.i686-linux.tar.xz
  58fecdbaa8bec3795930879fad4cf7c31d3291c363b6cced18e4f7008d7e0282  
guix-binary-1.2.0.x86_64-linux.tar.xz
  230a5662a78741629775c97564418836242d094d4f8db866c9e395e982298ef4  
guix-system-install-1.2.0.i686-linux.iso.xz
  a6ecc45084e6f3f93c1ed5fc5c6d2b8b3338f3c1875ed6d89e996df62aa40455  
guix-system-install-1.2.0.x86_64-linux.iso.xz
  468ddc396ad42a2fee60ccd9d249b760ac498109deea8b1c6b5d0be9c16f2f82  
guix-system-vm-image-1.2.0.x86_64-linux.xz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:
  
gpg --verify guix-1.2.0.tar.gz.sig
  
  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.openpgp.org \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
  
  and rerun the 'gpg --verify' command.

  To install the standalone Guix system, please see “System
  Installation” in the manual.  To install Guix on a running system, see
  “Installation” in the manual.

• Changes since version 1.1.0 (excerpt from the NEWS file)

  ** Package management
  *** ‘guix pull’ now crytographically authenticates channels
  *** ‘guix describe -f channels’ now shows “channel introductions”
  *** ‘guix describe -f channels-sans-intro’ omits channel introductions
  *** New ‘guix git authenticate’ command, to authenticate Git checkouts
  *** ‘guix pull’ and ‘guix system reconfigure’ detect attempts to downgrade
  *** New ‘--allow-downgrades’ option for ‘guix pull’ and ‘guix system’
  *** Guix build time reduced thanks to Guile 3.0.4’s “baseline compiler”
  *** New ‘--with-debug-info’ package transformation option
  *** New 

Re: Guix: The Platform Harmonizer

[Ludovic Courtès]

Hi Matias,  :-)

Julien Lepiller  skribis:

> Thank you for this presentation, it's really great!

+1, a refreshing perspective!

Thanks,
Ludo’.

Re: Exception on `guix import`

[Ludovic Courtès]

Hi,

Joseph LaFreniere  skribis:

> Running `guix import pypi black-macchiato` prints the following output
> (also attached):

[...]

> In guix/import/pypi.scm:
>   477:21  9 (_ _)
>121:9  8 (pypi-fetch "black-macchiato")
> In guix/import/json.scm:
> 45:2  7 (json-fetch _ #:headers _)
> In ice-9/boot-9.scm:
>  1736:10  6 (with-exception-handler _ _ #:unwind? _
>  #:unwind-for-type _)
> In guix/import/json.scm:
>50:19  5 (_)
> In guix/http-client.scm:
>87:25  4 (http-fetch _ #:port _ #:text? _ #:buffered? _
>#:verify-certificate? _ #:headers _)
> In guix/build/download.scm:
>436:4  3 (open-connection-for-uri _ #:timeout _
>#:verify-certificate? _)
>   437:14  2 (thunk)
>   361:16  1 (open-socket-for-uri _ #:timeout _)
> In ice-9/boot-9.scm:
>  1669:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

Do you still experience it?  It works for me:

--8<---cut here---start->8---
$ guix import pypi black-macchiato

Starting download of /tmp/guix-file.dsSsKz
>From 
>https://files.pythonhosted.org/packages/02/94/80b2df7480f5f4927fe7bfdd47a2e64eb3b7cc4b6cea0351b698f7b18b73/black-macchiato-1.3.0.tar.gz...
 …o-1.3.0.tar.gz  4KiB6.3MiB/s 00:00 [##] 100.0%

Starting download of /tmp/guix-file.3muMTA
>From 
>https://files.pythonhosted.org/packages/9f/12/06d383ecc3336abfce36c470a6a19b1b569126bfe4d28d4ca5a1b0528f6e/black_macchiato-1.3.0-py3-none-any.whl...
 ….0-py3-none-any.whl  4KiB   8.3MiB/s 00:00 [##] 100.0%
(package
  (name "python-black-macchiato")
  (version "1.3.0")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "black-macchiato" version))
  (sha256
(base32
  "1drp5p697ni1xn5y2lbjpalgpkzy2i4cyxjj5pk4dxr0vk97dd7i"
  (build-system python-build-system)
  (propagated-inputs
`(("python-black" ,python-black)))
  (home-page
"https://github.com/wbolster/black-macchiato;)
  (synopsis "Partial black formatting")
  (description "Partial black formatting")
  (license license:bsd-3))
$ guix describe
Generacio 163   Oct 11 2020 21:01:54(nuna)
  guix bf986c3
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bf986c3e4325594c1c6a43cf0b67b92262842863
--8<---cut here---end--->8---

Ludo’.

Re: Installing gcc debugging symbols?

[Ludovic Courtès]

Hi,

Simon South  skribis:

> Simon South  writes:
>> I could edit gnu/packages/gcc.scm to set the "stripped?" variable to
>> false...
>
> Of course if you're willing to make this change, you can just as easily
> remove the "hidden-package" wrapper around gcc 4.7's package definition
> and then install the debug symbols in the usual manner, i.e. with
>
>   ./pre-inst-env guix install gcc@7.5:debug
>
> At least, I assume this is going to work.
>
> Still, I wonder if there is a more "official" method that involves less
> hackery.

I’m afraid there’s no better method currently.  The new
‘--with-debug-info’ option wouldn’t help here since it’s compiled with
-g0 unless ‘stripped?’ is changed to #f.

We should make ‘stripped?’ a parameter somehow.

Ludo’.

Re: Helvetica in `guix graph`

[Ludovic Courtès]

Hi,

Fulbert  skribis:

>   When I pipe `guix graph hello | xdot -`, the characters are
> displayed as squares. Got to insert
> `… | sed "s/Helvetica/sans/g" | …` in the pipeline.
>
>   Not sure if this is a bug. Maybe my system should find a
> substitute for "Helvetica" automatically ?

It should definitely find a substitute automatically (Ghostscript knows
the replacements for the standard PostScript fonts).

Anyway, changing to “sans” as you suggest doesn’t hurt so I’ll make that
change.

Thanks,
Ludo’.

Re: failed to install the python-umap-learn package

[Ludovic Courtès]

Hi,

zimoun  skribis:

> Thank you for pointing out the issue.  Using the Guix Data Service,
>
>   
> https://data.guix.gnu.org/repository/1/branch/master/package/python-umap-learn/output-history

[...]

> From the Guix Data Service, the first offending commit is
> cac674d99dc4a332e6210c57ec7f1b8164f66642 which updates python-cython.

Neat!  We should put that that to good use somehow to quickly notice and
fix regressions: with IRC/email notifications, ‘guix weather’ reporting
info from the Data Service, things like that.

Ludo’.

Re: define udev-service-type fails with "did you forget to import.." error

[Ludovic Courtès]

Hi,

Stefan Huchler  skribis:

> I get following error:
> /etc/config.scm:128:0: error: udev-shepherd-service: unbound variable
> hint: Did you forget `(use-modules (gnu services base))'?

Could you send /etc/config.scm so we can see the context?

Thanks,
Ludo’.

Re: failed to install the python-umap-learn package

[Ludovic Courtès]

Hi,

"hong...@mdc-berlin.de"  skribis:

> I had a failure when installing python-umap-learn in guix. It took very long 
> time in the 'check' phase.
>
> The error does not change before and after 'guix pull'. Could you please tell 
> me how to solve this problem?
>
> Thanks in advance! Please see the screen output below:
>
>
> $ guix package -i python-umap-learn
>
> The following package will be installed:
>python-umap-learn 0.3.10
>
> The following derivations will be built:
>/gnu/store/4sbifbl79yy6xnbnkvj0hvc3i2mp6jcj-python-umap-learn-0.3.10.drv
>/gnu/store/ra7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv
> building 
> /gnu/store/ra7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv...
> - 'check' phasebuilder for 
> `/gnu/store/ra7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv' failed 
> with exit code 1
> build of /gnu/store/ra7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv 
> failed
> View build log at 
> '/gnu/var/log/guix/drvs/ra/7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv'.
> guix package: error: build of 
> `/gnu/store/ra7xx13ni736p0kvcsbhsl0g9yhy4d68-python-numba-0.46.0.drv' failed

It would seem that one of the tests of python-numba is failing, perhaps
in a non-deterministic way.

As a stopgap, you should be able to run:

  guix install python-umap-learn --without-tests=python-numba

Note that ‘--without-tests’ was added just a couple of days ago, so you
may need to run ‘guix pull’ to get a recent-enough Guix:

  
https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html

HTH,
Ludo’.

Re: How do I set LTDL_LIBRARY_PATH?

[Ludovic Courtès]

Hi,

divoplade  skribis:

> I have written a small C guile module to access (some parts of) the GNU
> nettle library. I can install it with guix, but then if I try to load
> it from within an environment:
>
> guix environment --ad-hoc guile guile-nettle -- guile < (load-extension "libguile-nettle" "init_nettle")
> EOF
>
> guile does not find "libguile-nettle" (In procedure dynamic-link: file:
> "libguile-nettle", message: "file not found")
>
> This is because guile expects it to be in LTDL_LIBRARY_PATH, and guix
> does not set that up.

Common practice is to arrange so that bindings refer to C libraries by
absolute file name.  For example:

--8<---cut here---start->8---
$ grep /libgcrypt $(find $(guix build guile-gcrypt) -name \*config.scm)
  "/gnu/store/qc3k3kd458pgrqsc7ih641160q81npwq-libgcrypt-1.8.5/lib/libgcrypt")
$ grep /libz $(find $(guix build guile-zlib) -name \*config.scm)
  "/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib/libz")
--8<---cut here---end--->8---

HTH!

Ludo’.

Re: aerosol package not available

[Ludovic Courtès]

Hi Matthieu,

Matthieu Haefele  skribis:

> Indeed, aerosol is still in the non-free package repository but this should 
> change by the end of this year with the intention to
> release a public version. I was always bothering Ludovic directly with my 
> questions and I decided to ask the mailing list properly
> this time instead. Maybe I will keep bothering him in the mean time.

It’s a great idea to ask the mailing list for questions that have to do
with Guix itself, just not for questions that have to do with external
channels not maintained by the Guix project, especially if they promote
non-free software.

Thank you!

Ludo’.

Re: Gitlab CI

[Ludovic Courtès]

Hi,

divoplade  skribis:

> Le vendredi 24 juillet 2020 à 16:30 +0200, Ludovic Courtès a écrit :
>> 
>> So presumably a better option is to use an image created like this:
>> 
>>   guix pack -f docker -S /bin=bin guix --localstatedir
>> 
> As you may know, most gitlab server will not let you use the provided
> docker registry, and so the only option will be to push to docker hub.

Yes.  What I had in mind was that you would create that image, upload it
to a registry GitLab-CI can pull from, and then refer to that image in
your ‘.gitlab-ci.yml’.

> I prefer the solution in which the pack is a .tar.gz that is directly
> untarred to /; this way it can be run on a shared unprivileged runner
> and the storage can be achieved in the runner itself, via the gitlab CI
> cache.

Ah yes, I guess that would also work, and it’s in fact less tedious.
That amounts to running https://guix.gnu.org/install.sh every time
though, no?

Thanks,
Ludo’.

Re: interactive input using guix-jupyter-kernel

[Ludovic Courtès]

Hi David,

david larsson  skribis:

> How can I ask for password input and get a password prompt in the
> notebook if I use the guix kernel in jupyter?
>
> ;;guix environment python-env <- python-ipython python-ipykernel
> import getpass
> password = getpass.getpass()
>
> using a regular python kernel this works fine but not with guix kernel.

Oh, it may be a bug in Guix-Jupyter.  I confirm I can reproduce the
issue; I get:

--8<---cut here---start->8---
guix[11012]: evaluating code in environment "python-env" (PID 11126)
guix[11012]: forwarding "status" from 11126, socket # to 
"316331366166623831663830343064353830626561353635636162366133"
guix[11012]: forwarding "execute_input" from 11126, socket # to 
"316331366166623831663830343064353830626561353635636162366133"
--8<---cut here---end--->8---

and then apparently the Python kernel never replies.

Looking at:

  
https://gitlab.inria.fr/guix-hpc/guix-kernel/-/blob/master/jupyter/messages.scm

I think the problem is just that ‘input_request’ messages aren’t
implemented:

  
https://jupyter-client.readthedocs.io/en/latest/messaging.html#messages-on-the-stdin-router-dealer-channel

I’m not sure I’ll look into it before I go on vacation, but you’re
welcome to give it a try!

Ludo’.

Re: Manifest Hooks?

[Ludovic Courtès]

Hi,

Steven Stallion  skribis:

> I've been looking into using manifests to help track some project
> dependencies and had a question for the list. Is it possible to add a
> shell hook similar to nix-shell when the packages specified by a
> manifest have been installed? In this specific case, I have a Python
> virtualenv I would like to activate when packages have finished
> installing without requiring additional scripting.

No, there’s no such thing.  I guess you could tweak ~/.bashrc to do that
based on $GUIX_ENVIRONMENT but it’s not very elegant.

Besides, I’d be interested in your thoughts as to whether/how ‘guix
environment’ could be improved to make virtualenv unnecessary.

Thanks,
Ludo’.

Re: Channel authentication: missing keyring branch

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> I recently added authentication to a Guix channel.
> On Guix pull, guix complained that the remote has no `keyring' branch.
> Indeed, creating an orphan `keyring' branch with all the public keys
> stored in it worked.
>
> This does not seems to be documented in the manual.

Oops, it’ll show up soon at:

  
https://guix.gnu.org/manual/devel/en/html_node/Channels.html#Specifying-Channel-Authorizations

> Besides, is there a convenient way to create the keyring branch and
> populate it with the public keys of all the committers so far?

No, but I guess you could take the output of ‘git shortlog -s --email’
and pass it to ‘gpg --export’ & co.

Thanks,
Ludo’.

Re: Knowing which services to restart

[Ludovic Courtès]

Hi,

Carlo Zancanaro  skribis:

> On Wed, Jul 08 2020, Pierre Neidhardt wrote:
>> Couldn't Guix be smarter about this?  Or at least provide a less puzzling 
>> message.
>
> This was brought up when we originally implemented upgrading of services on a 
> live system. The discussion about this starts in an email from Ludovic[1], 
> and proceeds from there (although you'll have to skip over some other 
> unrelated conversations).
>
> There are definitely ways that things can be improved. I made an attempt at 
> doing this at the end of 2018[2], but that didn't result in anything being 
> merged into Guix. I don't think we've yet settled on an approach for how to 
> resolve this (and the related issue of automatically upgrading services).
>
> Carlo
>
> [1]: https://issues.guix.info/22039#11
> [2]: https://issues.guix.info/33508

The general issue here is that we cannot safely stop+start a service
without notice, unless the user explicitly said this is OK.
Consequently, in practice, only services that the user explicitly ‘herd
restart’s are up-to-date.  It’s OK when you know you what service you
want to update here and now, but it’s suboptimal otherwise.

I figured there’s one way to mostly sidestep the issue: when we have
“socket activation” in the Shepherd, then unused services will be
“stopped” at reconfigure time and thus safe to upgrade.  Thus, in
practice, more services will be upgraded by default.

It’d still be up to the user to restart currently running services when
they deem appropriate.

Thanks,
Ludo’.

Re: Server mail setup?

[Ludovic Courtès]

Hello!

Christopher Lemmer Webber  skribis:

> Julien Lepiller writes:
>
>> Le 8 juillet 2020 03:50:08 GMT-04:00, Pierre Neidhardt  a 
>> écrit :
>>>Me too! :)
>>
>> I have this: 
>> https://framagit.org/tyreunom/system-configuration/-/blob/master/modules/config/mail.scm
>
> Oooh thank you, this looks helpful!

Any volunteer to turn it into a cookbook section?  That’d be sweet.  :-)

Ludo’.

Re: hash mismatch on permanently moved URL

[Ludovic Courtès]

Hi Giovanni,

Giovanni Biscuolo  skribis:

> yesterday I installed a new Guix System (on iron) using the installer
> (latest stable
> https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.x86_64-linux.iso.xz
> on USB)
>
> The installation is fine but when I try to guix pull I get this:
>
>
> ~$ sudo -i guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   b919d40
> building 
> /gnu/store/f99dg2cqqlskh5q07l9dw5la7l5s28lq-libgcrypt-1.8.4.tar.bz2.drv...
> downloading from 
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.4.tar.bz2...
> building /gnu/store/4582v7day5c4v9qaidlkwmd6kllks2y4-icu4c-64_2-src.tgz.drv...
> downloading from 
> http://download.icu-project.org/files/icu4c/64.2/icu4c-64_2-src.tgz...
> |sha256 hash mismatch for 
> /gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz:
>   expected hash: 0v0xsf14xwlj125y9fd8lrhsaych4d8liv8gr746zng6g225szb2
>   actual hash:   1qfbm2kh7hzd8752rky9dzis8qhgkhs6dkq71k8zar8y74nz7265
> hash mismatch for store item 
> '/gnu/store/0zh5mvhgcx0198k7j6p5pgrc5krgxyqj-icu4c-64_2-src.tgz'
> build of /gnu/store/4582v7day5c4v9qaidlkwmd6kllks2y4-icu4c-64_2-src.tgz.drv 
> failed

I looked into this.  Following
 I
found a revision around the one you were using and then reproduced the
issue using:

  guix time-machine --commit=897f303d2fa61497a931cf5fcb43349eb5f44c14 -- \
build -S icu4c@62.1 --check

(In the meantime, I had to fix …)

The core issue is that the web server returns 200 instead of 404:

--8<---cut here---start->8---
$ wget --debug -O /tmp/tgz 
http://site.icu-project.org/download/#/icu4c/62.1/icu4c-62_1-src.tgz
Setting --output-document (outputdocument) to /tmp/tgz
Setting --output-document (outputdocument) to /tmp/tgz
DEBUG output created by Wget 1.20.3 on linux-gnu.

Reading HSTS entries from /home/ludo/.wget-hsts
URI encoding = 'UTF-8'
--2020-07-24 17:14:24--  http://site.icu-project.org/download/
Ni solvigas site.icu-project.org (site.icu-project.org)... 
2a00:1450:4007:810::2013, 216.58.213.147
Caching site.icu-project.org => 2a00:1450:4007:810::2013 216.58.213.147
Konektado al site.icu-project.org 
(site.icu-project.org)|2a00:1450:4007:810::2013|:80... konektita.
Created socket 4.
Releasing 0x016bf6a0 (new refcount 1).

---request begin---
GET /download/ HTTP/1.1
User-Agent: Wget/1.20.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: site.icu-project.org
Connection: Keep-Alive

---request end---
HTTP peto sendita, ni atendas respondon...
---response begin---
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
X-Robots-Tag: noarchive
Last-Modified: Wed, 22 Jul 2020 18:34:34 GMT
Expires: Fri, 24 Jul 2020 15:14:24 GMT
Date: Fri, 24 Jul 2020 15:14:24 GMT
Cache-Control: private, max-age=5
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

---response end---
200 OK
Registered socket 4 for persistent reuse.
URI content encoding = 'utf-8'
Grando: nespecifita [text/html]
Ni konservas al: '/tmp/tgz'

/tmp/tgz [ <=>  

 ]  44.43K  --.-KB/sen 0.04s

2020-07-24 17:14:24 (1006 KB/s) - '/tmp/tgz' konservita [45498]

$ file /tmp/tgz
/tmp/tgz: HTML document, UTF-8 Unicode text, with very long lines
--8<---cut here---end--->8---

Someone™ should contact the icu-project.org admins.

The other issue is , which still
deserves a fix.

Anyway, the file is available at
.

Thanks,
Ludo’.

Re: Very slow download speed of substitutes

[Ludovic Courtès]

Hi,

Lo Peter  skribis:

> I am trying guix import from cran, and building some R packages, which
> sometimes needs to download substitutes. i noticed that the download
> speed can be ridiculously slow and seems especially during night in
> HKT.
>
> Here is a snippet of the downloading:
>
> substituting 
> /gnu/store/njhd9w4pvp2c6mbdngg1xvvld82a2c1l-ghc-ansi-wl-pprint-0.6.9...
> downloading from
> https://ci.guix.gnu.org/nar/lzip/njhd9w4pvp2c6mbdngg1xvvld82a2c1l-ghc-ansi-wl-pprint-0.6.9
> ...
>  ghc-ansi-wl-pprint-0.6.9  123KiB25KiB/s 00:05
> [##] 100.0%
>
> substituting 
> /gnu/store/p035ilg1b6ywpxxj8df494x8zxnnwg12-ghc-data-default-instances-containers-0.0.1...
> downloading from
> https://ci.guix.gnu.org/nar/lzip/p035ilg1b6ywpxxj8df494x8zxnnwg12-ghc-data-default-instances-containers-0.0.1
> ...
>  ghc-data-default-instances-containers-0.0.1  42KiB 37KiB/s 00:01
> [##] ghc-data-default-instances-containers-0.0.1
> 42KiB 37KiB/s 00:01 [##] 100.0%

These are all small files so the download speed that is displayed may be
inaccurate.  I’d encourage you to check and report the download speed
for large files, say LibreOffice.

That said, the code in Guix could be improved by arranging to keep the
HTTPS connection alive between downloads instead of reopening it every
time.  This is especially expensive when downloading lots of small files
as is the case above.

Thanks,
Ludo’.

Re: Building packages in REPL

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Fri, 26 Jun 2020 at 06:17, Julien Lepiller  wrote:
>
>> One way to do this with the guix API is to get the derivation, then build it:
>>
>> (use-modules (guix derivations) (guix store) (gnu packages bash))
>> (define package bash-minimal)
>> (define store (open-connection))
>> (define der (package-derivation store package))
>> (build-derivations store (list der))
>>
>> Is that what you want?
>
> Yes, but provides something like:
>
> (use-modules
>  (guix store)
>  (guix derivations)
>  (guix packages))
>  
> (define (build-packages packages)
>   (with-store store
> (let ((builds (map (lambda (package)
>  (package-derivation store package))
>packages)))
>   (build-derivations store builds
>
> (define (build-package package)
>   (build-packages (list package)))

(guix scripts) has a high-level ‘build-package’ procedure (initially
written for Emacs-Guix) that can be used like this:

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.4
Copyright (C) 1995-2020 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@(guix-user)> ,use(guix)
scheme@(guix-user)> ,use(guix scripts)
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (build-package coreutils)
$1 = #
scheme@(guix-user)> ,run-in-store (build-package coreutils)
/gnu/store/yvsd53rkbvy9q8ak6681hai62nm6rf31-coreutils-8.32-debug
/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32
$2 = #t
--8<---cut here---end--->8---

HTH!

Ludo’.

Re: Gitlab CI

[Ludovic Courtès]

Hello!

I’m late to the party but I’m interested in this discussion…  :-)

Jérémy Korwin-Zmijowski  skribis:

> I am experimenting with Gitlab CI for a Guile project I am working on.
> It is managed with Hall and I would like to benefit the Guix features.

GitLab CI can run jobs directly in a Docker image:

  https://docs.gitlab.com/ce/ci/docker/using_docker_images.html

So it would be interesting to have any easy way for people to create a
Docker image for this purpose.

Colleagues of mine tried ‘guix system docker-image’ for that but that
turns out to not quite work (IIRC gitlab-runner tries to do ‘docker exec
your build command’, which fails here because those images have shepherd
as their entry point).

So presumably a better option is to use an image created like this:

  guix pack -f docker -S /bin=bin guix --localstatedir

and then, in the image, you first need to spawn guix-daemon, perhaps
with ‘--disable-chroot’ because the image lacks build users.

It would be useful also to set the user under which commands run in the
image, similar to the ‘USER’ directive in Dockerfiles.

Thoughts?

It would be nice to make that as smooth as possible and to add a recipe
in the cookbook!

Ludo’.

Re: What's the license of Guix's blog?

[Ludovic Courtès]

Hello,

"Zhu Zihao"  skribis:

> I want to translate some of Guix's blog into another language, but I don't 
> know what license the articles in Guix'blog using, are they using GNU FDL?

Translations would be welcome!

Most articles do not have an explicit license.  However, I believe most
authors are still around and we should be able to agree on a default
license for all the articles.  We can add a note at the bottom of the
web page of each article stating that, unless otherwise stated, the
document is available under the agreed-upon license.

I would propose GFDLv1.3+ without invariant sections, since that can
then be relicensed to CC-BY-SA should anyone need it.

Thoughts?

Ludo’.

Re: Geiser and Guix - how to avoid long compilation steps?

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> This has been a source of headaches for me too.  I like to run Geiser
> to hack my Guix checkout.  But if I forget to compile a (big) scheme
> file, geiser will grind to a halt when switching to a module that
> depends on the uncompiled file.
>
> Something weird: If I repeat the module switch, Geiser still takes ages
> to do it, as if it didn't persist the .go files (normally in
> ~/.cache/guile/ccache?)
>
> In my understanding, the solution here is to run `guix environment
> guix -- make` all the time.
>
> Maybe I'll add an override for geiser-mode-switch-to-repl-and-enter that
> compiles Guix automatically.
>
> Any other tip?

I run “make” before starting the REPL to avoid the problem you mention
(bah!), but from there on I can happily hack on my stuff.

A little-known feature of Emacs-Guix is C-c . u (guix-devel-use-module),
which allows you to load a module without compiling it with C-c C-k.
It’s fast and non-intrusive, unlike C-c C-k.

Ludo’.

Re: guix completion in zsh

[Ludovic Courtès]

Hi,

"Reza Alizadeh Majd"  skribis:

> after replacing the default shell with `zsh`, I lost the tab completion
> feature for Guix commands. do I need to perform any specific configuration
> to enable this feature?

I think you need to make sure the Zsh completion file for Guix is
sourced.

Normally that happens by default on Guix System, but maybe something
broke?  (I don’t use Zsh.)

HTH,
Ludo’.

Re: Access custom images inside disk image

[Ludovic Courtès]

Hello,

"Reza Alizadeh Majd"  skribis:

> I built a modified version of Guix to have a series of custom Channels
> by default. using this modified version, everything is OK, and I have
> access to these custom channels by default.
>
> The problem is that when I create a disk image using this custom build
> of Guix, only default Guix channel  details is available during build, 
> and I need to perform a `guix pull` to make the profile cache updated 
> and install packages located in custom channels.
>
> is there any way that allow me to have these custom channels available
> by default in disk image?

To be clear, you don’t just want a predefined /etc/guix/channels.scm,
you want the actually channel bits as returned by ‘guix pull’, right?

This is currently not easy to do out of the box, but here’s a couple of
tricks to more or less do that:

  
https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/.guix.scm#n42
  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/ci.scm#n265

The 2nd one in particular would allow you to treat a “pulled Guix” as a
package.

HTH!

Ludo’.

Re: zlib licence

[Ludovic Courtès]

Hi,

Adam Kandur via  skribis:

> hi, it seems http://www.gzip.org/zlib/zlib_license.html returns 404.
> i suggest this link https://zlib.net/zlib_license.html

This is now fixed, thanks!

Ludo’.

Re: Vanilla Firefox recipe?

[Ludovic Courtès]

Hello!

Adonay is right that the project’s channels are not the place to discuss
third-party channels and distribution methods, especially channels and
tools that provide non-FSDG-compliant software.

As for Firefox, it pops up every now and then, but there seems to be a
lasting misunderstanding.  Firefox, as is, will not go into Guix because
it does not comply with several items of the FSDG, which the project is
committed to following (for example, by linking to Mozilla’s add-on
catalog, which contains non-free software.)

However, a version of Firefox stripped from the bits that make it
non-FSDG-compliant would be welcome.

This is essentially what IceCat is about, but IceCat is based on an LTS
version (I think that’s what you meant by “old”) and it enables various
privacy-enhancing plugins by default.

I think there were a few attempts to do that in the past, but they were
not completed, so we’re having this discussion again.  :-)
It might be that the “clean up” code we have for IceCat would work with
few modifications on the latest Firefox.

I hope this clarifies the situation!

Until then, happy web browsing.  :-)

Ludo’.

Re: Wi-Fi connection during gui-based installation

[Ludovic Courtès]

Hi Stephen,

Stephen Minton  skribis:

> I successfully put guix-system-install-1.0.1.x86_64-linux.iso on a mem stick 
> and booted.
>
> GUI installer hung up on connecting to wifi network (successfully found 
> interface and scanned, showing target wifi name) on message "connection in 
> progress  Connecting to ... please wait.

Yeah, unfortunately we discovered this bug in the 1.1.0 image (it’s now
fixed: ).

If it’s an option for you, I’d suggest installing over Ethernet.

> I went to manual install, network wifi and successfully entered a 
> wpa_supplicant.conf and connected (ping -c 3 gnu.org)
>
> I think the script's wpa_supplicant.conf is missing some parameter.  How do I 
> specify that, or break out of the script to connect to the network manually 
> and then return?  

What does ‘wpa_supplicant.conf’ contains?

> Is there some other forum to ask this question?

This is the right forum.

Thanks for your feedback, and apologies for the bug!

Ludo’.

Re: Italian translation

[Ludovic Courtès]

Hello Alessandro & all!

Miguel Arruga Vivas  skribis:

> Alessandro Cipriani  writes:
>> Hi guys,
>
> Ciao, Alessandro!
>  
>> i'm alessandro and i'm from italy. I'd like to participate in this 
>> project, i like it very much. I'm a software developer since 2007.
>
> I'm sure your work will be appreciated.  Please, make sure to read the
> section of the manual about contributions[1] and don't be afraid to
> ask.

Seconded!

There are several things up for translation:

  1. Messages printed by the commands:
 .

  2. Package descriptions:
 .

  3. The manual:
 .

  4. The Cookbook, which can be seen at
 , but I think it’s not on the
 Translation Project (yet?).  Julien and Florian should know more.

Looking forward to Italian translations!  :-)

Ludo’.

Re: Guixsd and meshlab ?

[Ludovic Courtès]

Hi,

Ekaitz Zarraga  skribis:

> On Tuesday, April 7, 2020 1:25 AM, Olivier Farges 
>  wrote:
>
>> Hi Guix,
>>
>> has anyone ever had the opportunity to install meshlab and could possibly 
>> provide a corresponding .scm file?

[...]

> I didn't but I'm interested on it and I would take the time to make one.
>
> If you are not in a hurry and can wait a couple of days I can make the 
> package for you.

I see you submitted it in the meantime:

  https://issues.guix.gnu.org/issue/40492

Almost there!  :-)

Thanks,
Ludo’.

Re: failure to create disk-image

[Ludovic Courtès]

Hi Roy,

Roy Lemmon  skribis:

> installing bootloader...
> Backtrace:
>1 (primitive-load "/gnu/store/abqhniaagz11v7w8kz83ha1s6fc…")
> In ./gnu/build/vm.scm:
> 590:6  0 (initialize-hard-disk "/dev/vda" #:bootloader-package _ …)
>
> ./gnu/build/vm.scm:590:6: In procedure initialize-hard-disk:
> Throw to key `srfi-34' with args `(# "'/gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install
> --boot-directory /fs/boot --bootloader-id=Guix --efi-directory /fs/dev/vda'
> exited with status 1; output follows:\n\n
>  /gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install:
> error:
> /gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/lib/grub/i386-pc/modinfo.sh
> doesn't exist. Please specify --target or --directory.\n"] 7fe479410240>)'.

I think the key issue here was GRUB failing to install itself.

Did you eventually find out wha was going wrong?

It looks like ‘grub-efi’ was chosen whereas the VM is actually “legacy
BIOS”, not EFI.

Thanks,
Ludo’.

Re: Guix does not find packages

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> Tobias Geerinckx-Rice  writes:
>
>> I *still* think we should either do nothing, or call $PAGER
>> automatically when stdout is a TTY.
>
> We should call $PAGER when it’s set.
>
> Isn’t there a bug report about this…?

I’m noticing this thread just now (oops!) and I think a bug report is in
order.  I didn’t know there was consensus on invoking $PAGER, but since
there is, let’s do that!

Ludo’, who would like to not prevent progress.  :-)

GNU Guix 1.1.0 released

[Ludovic Courtès]

We are pleased to announce the release of GNU Guix 1.1.0.

This release corresponds to 14,078 commits over 11 months by 201 people.
It includes many new features, user interface and performance
improvements, as well as many bug fixes—see below for a list of changes.

Read more about today’s announcement at:

  https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released

• About

  GNU Guix is a transactional package manager and an advanced
  distribution of the GNU system that respects user freedom.  Guix can
  be used on top of any system running the kernel Linux, or it can be
  used as a standalone operating system distribution for i686, x86_64,
  ARMv7, and AArch64 machines.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  When used as a
  standalone GNU/Linux distribution, Guix offers a declarative,
  stateless approach to operating system configuration management.  Guix
  is highly customizable and hackable through Guile programming
  interfaces and extensions to the Scheme language.

  https://guix.gnu.org

• Download

  Here are the compressed sources and a GPG detached signature[*]:
https://ftp.gnu.org/gnu/guix/guix-1.1.0.tar.gz
https://ftp.gnu.org/gnu/guix/guix-1.1.0.tar.gz.sig

  Here are the bootable USB installation images and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.i686-linux.iso.xz
https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.i686-linux.iso.xz.sig
https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.x86_64-linux.iso.xz

https://ftp.gnu.org/gnu/guix/guix-system-install-1.1.0.x86_64-linux.iso.xz.sig

  Here is the QCOW2 virtual machine (VM) image and its signature[*]:
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.1.0.x86_64-linux.xz
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.1.0.x86_64-linux.xz.sig

  Here are the binary tarballs and their signatures[*]:
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.i686-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.i686-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.x86_64-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.x86_64-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.armhf-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.armhf-linux.tar.xz.sig
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.aarch64-linux.tar.xz
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.aarch64-linux.tar.xz.sig

  Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
  
  Here are the SHA256 checksums:

  5c59106ff4ac497c6097686834b0c914109cf5e44eb6b94ebce818923043640f  
guix-1.1.0.tar.gz
  f81b529c4a94d0ab2cfc6df9819af3d7e2ccfcf17ef7f901e1d2df0a63516ab6  
guix-binary-1.1.0.aarch64-linux.tar.xz
  4d08782979383c2848ca1c0ca9478cbfb4f9181d94370f4226398fbb51fd1d24  
guix-binary-1.1.0.armhf-linux.tar.xz
  33472a26cdf515ba496f770602ead6369ee6dc3dc6b679c279e1f5c4d8cd63fa  
guix-binary-1.1.0.i686-linux.tar.xz
  eae0b8b4ee8ba97e7505dbb85d61ab2ce7f0195b824d3a660076248d96cdaece  
guix-binary-1.1.0.x86_64-linux.tar.xz
  848c9a6a73cf4cf6fe4e7d5815342a9c40ec01fd93c23b5d4e12d41b18b16bb5  
guix-system-install-1.1.0.i686-linux.iso.xz
  ff2d74f64d8e1545271ab0f46ee0e11ae96fbb09cb105c3d929c9e123ad00ce2  
guix-system-install-1.1.0.x86_64-linux.iso.xz
  519d93fb27d33a97db568225bfa4e84f0cfc95bd173f5bf8277cb4098ae46b43  
guix-system-vm-image-1.1.0.x86_64-linux.xz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:
  
gpg --verify guix-1.1.0.tar.gz.sig
  
  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.openpgp.org \
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
  
  and rerun the 'gpg --verify' command.

  To install the standalone Guix system, please see “System
  Installation” in the manual.  To install Guix on a running system, see
  “Installation” in the manual.

• Changes since version 1.0.1 (excerpt from the NEWS file)

  ** Package management
  *** New ‘guix deploy’ command to deploy several machines at once
  *** Channels can now provide news, viewed with ‘guix pull --news’
  *** ‘guix system reconfigure’ saves provenance data
  *** New ‘guix system describe’ command to view system provenance info
  *** New /run/current-system/{channels,configuration}.scm files
  *** New ‘guix time-machine’ command
  *** ‘guix pack’ has a new ‘--entry-point’ option
  *** ‘guix pack’ saves environment variables for ‘docker’ and ‘singularity’
  *** ‘guix pack’ provides a meaningful repository name for ‘docker’
  *** New ‘--target’ option for ‘guix system’
  *** ‘--no-build-hook’ was renamed to 

Re: Avoiding the garbage collector for the Guix Data Service

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> I think so, it at least seems to greatly reduce the chance the
> derivations get removed. I made the Guix Data Service change here [1],
> and I haven't seen the issue since.
>
> 1: 
> https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=f59354ed23a9c50e43b7aaaeaddb5365feda4e29

Good!  It looks like the right thing to do, to me.

Ludo’.

Re: Packaging a simple Guile library

[Ludovic Courtès]

Hi,

sirgazil  skribis:

> I thought using the "guile-build-system" would make this straightforward, but 
> it didn't work as I expected. I was hoping to say, "Hey, guile-build-system:"
>
> 1. "glab" is the library you should build and install.
> 2. "doc" is the texinfo documentation you should build and install
>
> But this build system compiles every scheme file in the source, which
> results in a build failure in the case of my package,

The #:not-compiled-file-regexp option allows you to specify files not to
compile.  Let me know if it works for you.

> and the documentation it installs is just the README file, not the
> info documentation.

Ah, that part is missing from the build system, we should probably add
it.  In the meantime, you can add a custom phase, as you wrote.

HTH,
Ludo’.

Re: How to get libtool for gcc-9?

[Ludovic Courtès]

Hi Moritz,

Moritz Lell  skribis:

> but libtool looks for gcc-7.4.0 libraries:
>
> grep 'gcc-.*\ ' `which libtool` | sed 's/ /\n  /g'
>
> # sys_lib_search_path_spec="[...]
> #   /gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/[...]"

The ‘libtool’ executable provided by the ‘libtool’ package doesn’t
really matter.

Normally, Libtool is copied in package sources using ‘libtoolize’; only
when you run ./configure is a ‘libtool’ script generated for the program
you’re about to build.

HTH!

Ludo’.