bug#41038: gcc creates binaries that don't find their shared libraries

[Bruno Haible]

Hi,

I'm using the recent guix-system-vm-image-1.1.0.x86_64-linux.

After installing a couple of package for development
$ guix install make gcc-toolchain binutils glibc gdb gettext m4 autoconf 
automake
I expected to be able to build GNU bison 3.5.91 from source. But I hit a build
failure, due to a program being linked against a shared library that cannot be
found.

How to reproduce (simple test case):

$ wget https://ftp.gnu.org/gnu/gettext/gettext-0.20.1.tar.gz
$ tar xfz gettext-0.20.1.tar.gz
$ cd gettext-0.20.1/libtextstyle/examples/color-hello
$ ./autogen.sh
$ ./configure
...
checking how to link with libtextstyle... -ltextstyle
...
$ make
...
gcc -g -O2 -o hello hello.o -ltextstyle
$ ./hello
./hello: error while loading shared libraries: libtextstyle.so.0: cannot open 
shared object file: No such file or directory
$ ldd hello
...
libtextstyle.so.0 => not found
...


Discussion
--

For packages *installed by the user*, the configure test has
code to add -Wl,-rpath,DIR options for appropriate directories.

However, here, the library has been installed by the system (through
'guix install gettext'). It appears that gcc, when searching for the
library, finds it. Whereas the dynamic loader (ld-linux-x86-64.so.2)
apparently does not find it.

It should be GCC's job to create binaries that work, when all
referenced libraries are system libraries. The ELF file format and
dynamic loader have enough facilities to make this possible (-Wl,-rpath
option, ld.so.conf, ld.so.cache).


Bruno

bug#41037: documentation for application developers?

[Bruno Haible]

Hi,

I'm searching for documentation for application developers, regarding
tips for porting from ordinary Linux distros to GNU guix.

I would expect to find these issues discussed, at least:
  - hard-coded program names like /bin/pwd
  - where is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ?
  - libtool, ldconfig issues

Haven't seen it in
  https://guix.gnu.org/
nor
  https://guix.gnu.org/manual/en/guix.html

Bruno

bug#41035: [Error] No upgrade after pull

[louishp via Bug reports for GNU Guix]

Hello,

I've just installed GuixSD on a virtual machine (by Virtual Box on Windows 10), 
and got some strange errors with guix upgrade.

The first commands I use after the first login (as root) is : `guix pull`, 
which pulls many packages, and `guix upgrade` which does nothing. It says to me 
that :

"guix upgrade: warning: Consider running `guix pull` followed by
 'guix package -u' to get up-to-date packages and security updates"

But I've just guix-pulled.

During the installation, I've used all the by default choices, except when I 
say I want the SSH.

Here the result of guix system describe : https://paste.debian.net/1144431/
Here the result of tree in the guix folder : https://paste.debian.net/1144432/

Thanks for all your work, Guix powerness really hypes me.
Louis

bug#40977: --load-path does not honor ~

[Ludovic Courtès]

zimoun  skribis:

> On Sat, 2 May 2020 at 15:14, Ludovic Courtès  wrote:
>
>> It’s admittedly annoying, but it’s not something Guix itself should
>> paper over.  Doing that would open a can of worms, as illustrated by the
>> example Tobias gave.
>
> Instead of 'notabug' , I propose to tag this bug as 'wontfix' and
> retitle it as: "Tilde-expansion in --long-options=".
>
> Is it ok?

Sure.

Ludo’.

bug#22883: Authenticating a Git checkout

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Next steps:
>
>   • Clean up the (guix openpgp) API a bit, for instance by using proper
> SRFI-35 error conditions.

Done the API cleanup.  I’ll go ahead and push the current ‘wip-openpgp’
branch (squashing commits marked as such) tomorrow if there are no
objections.

The formats and mechanisms are not set in stone until this is
generalized to channels, but we’re getting there.  Now’s a good time to
raise any concerns you may have, comrades!

Ludo’.

bug#40872: Subject: [PATCH] gnu: system: Fix PATH export if the profile has no bin directory.

[Stefan]

* gnu/system.scm (operating-system-etc-service): Testing for $profile/bin.

Fixes .
---
 gnu/system.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 540f0e4a9e..0eb5731c82 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -725,7 +725,8 @@ do
 # Load the user profile's settings.
 GUIX_PROFILE=\"$profile\" ; \\
 . \"$profile/etc/profile\"
-  else
+  fi
+  if [ ! -d \"$profile/bin\" ]
 # At least define this one so that basic things just work
 # when the user installs their first package.
 export PATH=\"$profile/bin:$PATH\"
-- 
2.26.0

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Christopher Baines]

Noticed this when testing guix system build with core-updates. Here's a
small example which reproduces the issue:


(use-modules (guix channels)
 (guix inferior))

(define channels
  (list (channel
 (name 'guix)
 (url "https://git.savannah.gnu.org/git/guix.git;)
 (commit
  "e02c2f85b36ce1c733bd908a210ce1182bdd2560"

(define inferior
  (inferior-for-channels channels))

(first (lookup-inferior-packages inferior "linux-libre" "5.2.21"))


If you save that as a file then attempt to build it:


→ guix build -f test.scm 
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Backtrace:
   4 (primitive-load "/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r?")
In ice-9/eval.scm:
619:8  3 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
   182:19  2 (proc #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
   142:16  1 (compile-top-call # ?)
In unknown file:
   0 (%resolve-variable (7 . call-with-new-thread) #)

ERROR: In procedure %resolve-variable:
Unbound variable: call-with-new-thread
guix build: error: You found a bug: the program 
'/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r6z5hw-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"e02c2f85b36ce1c733bd908a210ce1182bdd2560"; system: "x86_64-linux";
host version: "a8cb1e72ef351330d1521833c1b270dcc0da593f"; pull-version: 1).
Please report it by email to .


signature.asc
Description: PGP signature

bug#32182: Login fail after core-update without reboot

[Ludovic Courtès]

Hi, old bug!  :-)

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

> I can think of several solutions:
>
>   1. Arrange for services to refer to /gnu/store/…-pam.d instead of
>  /etc/pam.d.  This can maybe be achieved by modifying PAM such that
>  these applications honor $PAM_DIRECTORY or something like that.

We should look into that.

>   2. Add support for “service chain-loading” in the Shepherd and/or
>  GuixSD.  The idea is that, for services that cannot be restarted
>  right away because they are currently running, register code to
>  upgrade the service next time it is restarted (see
>  ).  That way, when ‘login’ restarts
>  after ‘reconfigure’, it’s the new ‘login’ service that would be
>  restarted.

That bit was implemented long ago with Shepherd service replacements.
So at least, now, one can run ‘herd start term-tty1’ or similar to get a
working login:

  https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00496.html

Ludo’.

bug#40872: First installed package on guix system is not instantly usable

[Marius Bakke]

Stefan  writes:

> Hi Marius!
>
>> This is odd, as /etc/profile contains a workaround for this exact
>> problem (notice the else clause):
>> 
>> # Arrange so that ~/.config/guix/current comes first.
>> for profile in "$HOME/.guix-profile" "$HOME/.config/guix/current"
>> do
>>  if [ -f "$profile/etc/profile" ]
>>  then
>># Load the user profile's settings.
>>GUIX_PROFILE="$profile" ; \
>>. "$profile/etc/profile"
>>  else
>># At least define this one so that basic things just work
>># when the user installs their first package.
>>export PATH="$profile/bin:$PATH"
>>  fi
>> done
>> 
>> Can you investigate why this is ineffective on your system?
>
> Previously I had some packages installed, but I rolled-back to generation 0. 
> I found this in my scroll-back buffer:
>
> stefan@guix ~/development/guix$ guix package --roll-back
> Folgende Ableitung wird erstellt:
>/gnu/store/l0n6l104ldj7nz6kdyi7l8v5yjnc9p9g-profile.drv
> building profile with 0 packages...
> Von Generation „1“ zu „0“ gewechselt
>
> By rolling back it created a new generation 0 profile which is now lying 
> around with this kind of empty file: 
>
> stefan@guix ~$ cat .guix-profile/etc/profile 
> # Source this file to define all the relevant environment variables in Bash
> # for this profile.  You may want to define the 'GUIX_PROFILE' environment
> # variable to point to the "visible" name of the profile, like this:
> #
> #  GUIX_PROFILE=/path/to/profile ; \
> #  source /path/to/profile/etc/profile
> #
> # When GUIX_PROFILE is undefined, the various environment variables refer
> # to this specific profile generation.
>
> So the test for the existence of this file does not fail, but it doesn't 
> change PATH either. This is the profile content, it has no bin/ folder to add 
> to PATH:

I see.  We could extend the test in /etc/profile to look for a /bin
directory of the profile, but arguably rolling back to generation 0 is
not a very common case.  So I'm in favor of just keeping the status quo.

WDYT?


signature.asc
Description: PGP signature

bug#41025: blueman does not start

[Raghav Gururajan]

Hi Pierre!

> It seems that the blueman package is missing a wrapper unless I'm
> missing something:

When I packaged it, all I got was error regarding dbus. But now it seems there
are more errors. I am wondering if it has to do with updates in gtk and/or glib
and/or gobject-introspection.

Also, I found out that python references are not getting patched during
the build. I have made a patch to fix it, which I attached with this email.

Regards,
RG.
>From 4a2739cfa69d3537dcd3d4cee85d33bd790d0980 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan 
Date: Sat, 2 May 2020 09:51:09 -0400
Subject: [PATCH] gnu: blueman: Fix python references.

* gnu/packages/networking.scm (blueman): Fix python references.
[arguments]:<#:phases>:['patch-python-references]: New phase.
---
 gnu/packages/networking.scm | 39 -
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index 94b521584f..b775a9e689 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -143,7 +143,44 @@
 "--enable-polkit"
 "--disable-appindicator" ; Deprecated
 "--with-systemdsystemunitdir=no" ; Not required
-"--with-systemduserunitdir=no")))  ; Not required
+"--with-systemduserunitdir=no")  ; Not required
+   #:phases
+   (modify-phases %standard-phases
+ ;; Python references are not being patched in patch-phase of build;
+ ;; despite using python-wrapper as input. So patching them manually.
+ (add-after 'unpack 'patch-python-references
+   (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "apps/blueman-adapters.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-applet.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-assistant.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-manager.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-mechanism.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-report.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-rfcomm-watcher.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-sendto.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-services.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ (substitute* "apps/blueman-tray.in"
+   (("@PYTHON@") (string-append (assoc-ref inputs "python")
+"/bin/python3.7")))
+ #t)
 (native-inputs
  `(("cython" ,python-cython)
("glib:bin" ,glib "bin")
-- 
2.26.2

bug#40977: --load-path does not honor ~

[zimoun]

On Sat, 2 May 2020 at 15:14, Ludovic Courtès  wrote:

> It’s admittedly annoying, but it’s not something Guix itself should
> paper over.  Doing that would open a can of worms, as illustrated by the
> example Tobias gave.

Instead of 'notabug' , I propose to tag this bug as 'wontfix' and
retitle it as: "Tilde-expansion in --long-options=".

Is it ok?


Best regards,
simon

ps:
Quoting the 'wontfix' explanation [1]: ``this is a choice between two
arbitrary ways of doing things and the maintainer and submitter prefer
different ways of doing things``.
[1] https://debbugs.gnu.org/Developer.html#tags

bug#40790: OOM error in graphical installer tests.

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> * I have some hangs when doing the final testing in marionette. Still
>>   trying to understand why.
>
> Fixed with c537d2bcb7c652b4776435cd1e2a5119af43dd78.

Cool, sorry for breaking things.  :-/

> Still an issue remaining. "gui-installed-desktop-os-encrypted" closure
> is about 5.5GiB which makes too much files for libisofs:
>
> xorriso : UPDATE :  427934 files added in 19 seconds
> libisofs: FAILURE : HFS+ map nodes aren't implemented
> libisofs: FAILURE : Too much files to mangle, cannot guarantee unique file 
> names
> xorriso : FAILURE : Failed to prepare session write run
> xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
>
> Not sure how to fix it. Someone?

I tried the attached patch, which would select just one desktop
environments, thinking it might appease Xorriso, but actually it still
OOMs at the very last step:

--8<---cut here---start->8---
xorriso : UPDATE :  141879 file filters processed in 848 seconds
xorriso : UPDATE :  142026 file filters processed in 849 seconds
xorriso : UPDATE :  142102 file filters processed in 850 seconds
xorriso : NOTE : Copying to System Area: 512 bytes from file 
'/gnu/store/dvfl5ax7pj6c62f1ccc27qcrcb8nafr7-grub-hybrid-2.04/lib/grub/i386-pc/boot_hybrid.img'
[13266.747348] xorriso invoked oom-killer: 
gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[13266.749415] CPU: 0 PID: 251 Comm: xorriso Not tainted 5.4.36-gnu #1
[13266.750777] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
--8<---cut here---end--->8---

Testing again with this extra patch:

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 6f81ac16ff..9f240b50ee 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -356,7 +356,7 @@ INPUTS is a list of inputs (as for packages)."
#:substitutable? substitutable?
 
;; Xorriso seems to be quite memory-hungry, so increase the VM's RAM size.
-   #:memory-size 512))
+   #:memory-size 1024))
 
 (define* (qemu-image #:key
  (name "qemu-image")

I wonder if why it’s taking so much memory, and whether there’s
something else at play, like temporary files written to the overlaid
tmpfs and thus eating memory.

Thoughts?

Ludo’.

diff --git a/gnu/tests/install.scm b/gnu/tests/install.scm
index 019e21fd39..941958d698 100644
--- a/gnu/tests/install.scm
+++ b/gnu/tests/install.scm
@@ -957,7 +957,7 @@ build (current-guix) and then store a couple of full system images.")
 
 (define* (gui-test-program marionette
#:key
-   (desktop? #f)
+   (desktops '())
(encrypted? #f))
   #~(let ()
   (define (screenshot file)
@@ -971,7 +971,9 @@ build (current-guix) and then store a couple of full system images.")
   (setvbuf (current-output-port) 'none)
   (setvbuf (current-error-port) 'none)
 
-  (marionette-eval* '(use-modules (gnu installer tests))
+  (marionette-eval* '(use-modules (gnu installer tests)
+  (srfi srfi-1)
+  (srfi srfi-26))
 #$marionette)
 
   ;; Arrange so that 'converse' prints debugging output to the console.
@@ -1016,7 +1018,9 @@ build (current-guix) and then store a couple of full system images.")
 
   (marionette-eval* '(choose-services installer-socket
   #:choose-desktop-environment?
-  (const #$desktop?)
+  (lambda (desktop)
+(any (cut string-contains desktop <>)
+ '#$desktops))
   #:choose-network-service?
   (const #f))
 #$marionette)
@@ -1110,7 +1114,7 @@ build (current-guix) and then store a couple of full system images.")
 
 (define* (guided-installation-test name
#:key
-   (desktop? #f)
+   (desktops '())
(encrypted? #f)
target-os
(install-size 'guess)
@@ -1132,7 +1136,7 @@ build (current-guix) and then store a couple of full system images.")
(lambda (marionette)
  (gui-test-program
   marionette
-  #:desktop? desktop?
+  #:desktops desktops
   #:encrypted? encrypted?
  (command (qemu-command/writable-image image)))
   (run-basic-test target-os command 

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Ludovic Courtès]

Hi!

Jan Nieuwenhuizen  skribis:

> Pushed to core-updates as d2fc76462e72268ee5b04fe53805efc05c35e139,

Closing!

Ludo’.

bug#40977: --load-path does not honor ~

[Ludovic Courtès]

Danny Milosavljevic  skribis:

>> After processing options, guix need to "expanduser()" (as it is called
>> in Python) on all arguments which are paths.  
>
> Please don't do it.
>
> UNIX has its warts, and this is a well-known one (use ${HOME} instead).

Seconded.

Tilde expansion is performed by the shell.  In the case of
‘--foo=~/bar’, tilde expansion does not happen because ~ is right in the
middle of a string.

It’s admittedly annoying, but it’s not something Guix itself should
paper over.  Doing that would open a can of worms, as illustrated by the
example Tobias gave.

Ludo’.

bug#40803: One page HTML cookbooks are 404

[Björn Höfling]

On Thu, 23 Apr 2020 22:17:13 +
"operator.name" via Bug reports for GNU Guix  wrote:

> As of now these following pages 404:
> 
> https://guix.gnu.org/cookbook/de/guix-cookbook.de.html
> https://guix.gnu.org/cookbook/en/guix-cookbook.html
> https://guix.gnu.org/cookbook/es/guix-cookbook.es.html
> https://guix.gnu.org/cookbook/fr/guix-cookbook.fr.html
> https://guix.gnu.org/cookbook/ru/guix-cookbook.ru.html
> https://guix.gnu.org/cookbook/zh-cn/guix-cookbook.zh_CN.html

I commited a patch at the guix main repository with commit-id
7c65fc378cf68b598965fd977f5844050435ac97.

It will take a night until berlin will rebuild the documentation and
then it should be fixed on the web-site.

The translations in es, fr, ru, zh are not available for the cookbook
and the links to them will be removed.

I will control the success in 1 or 2 days and then close this bug.

Björn


pgpdCAhmXWqqk.pgp
Description: OpenPGP digital signature

bug#41019: util-linux runstatedir is not actually a state directory

[Danny Milosavljevic]

Note: once that bug is fixed, still have to add:

diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 44ee4f10aa..6a1840dbf6 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -245,6 +245,9 @@ FILE-SYSTEMS."
   '())
 ,@(if (find (file-system-type-predicate "jfs") file-systems)
   (list jfs_fsck/static)
+  '())
+,@(if (find (file-system-type-predicate "f2fs") file-systems)
+  (list f2fs-fsck/static)
   '(
 
 (define-syntax vhash  ;TODO: factorize


pgpQ0r8nAKcU0.pgp
Description: OpenPGP digital signature

bug#41019: util-linux runstatedir is not actually a state directory

[Danny Milosavljevic]

Hi,

util-linux tries to use a "uuidd" daemon to generate uuids.  It tries to
communicate with it via socket in $runstatedir/var/run/uuidd/ .

Unfortunately, we do not set runstatedir which means that we'll uselessly
refer to a socket inside util-linux's derivation output directory that never
will be there.

Better would be to refer to /var/run directly, or to remove that functionality
from our version of util-linux.

Git checkout:
  repository: /home/dannym/src/guix-raghav/guix
  branch: master
  commit: 807986a55fc2849d6986efb79f9a015cf4132e09

I stumbled upon that while trying to get F2FS's fsck to work (bug 41015).
We try to build a static version of f2fs-tools (f2fs-tools-static in
guix master), but it retains a reference from mkfs to the non-static
util-linux because of the problem above.

Details of that part of util-linux:

./libuuid/src/uuidd.h: * Definitions used by the uuidd daemon
./libuuid/src/uuidd.h:#define UUIDD_DIR _PATH_RUNSTATEDIR "/uuidd"
./libuuid/src/uuidd.h:#define UUIDD_PIDFILE_PATHUUIDD_DIR "/uuidd.pid"
./libuuid/src/uuidd.h:#define UUIDD_PATH"/usr/sbin/uuidd"
./libuuid/src/gen_uuid.c:#include "uuidd.h"
./libuuid/src/gen_uuid.c: * Try using the uuidd daemon to generate the UUID
./libuuid/src/gen_uuid.c: * Tries to guarantee uniqueness of the generated UUIDs
 by obtaining them from the uuidd daemon,
./libuuid/src/gen_uuid.c: * or, if uuidd is not usable, by using the global cloc
k state counter (see get_clock()).
UUIDD_SOCKET_PATH 
./libuuid/src/uuidd.h:#define UUIDD_SOCKET_PATH UUIDD_DIR "/request"
./libuuid/src/uuidd.h:#define UUIDD_DIR _PATH_RUNSTATEDIR "/uuidd"

/gnu/store/xymkwf57x988q8cny2is1dgzrbr9xdfi-util-linux-2.34/var/run/uuidd



pgpr9ctTo2brU.pgp
Description: OpenPGP digital signature