bug#40381: Guix shouldn't request substitutes for profile derivations

[pkill9]

Hi,

> Can you show more precisely what you mean by pasting a command and its
> output?

So it seems it tries to look for substitutes when the profile hooks are built,
not when profile.drv is built.

Here is the output without build hooks:
```
itsme@antelope ~> guix environment --ad-hoc hello
The following derivation will be built:
   /gnu/store/gkz9hzjpc9pj1np7vi5pwb4xhmssk55d-profile.drv
building profile with 1 package...
Welcome to fish, the friendly interactive shell
itsme@antelope ~ [Guix env: /gnu/store/nsi48y..]>
```

And here is output with build hooks:
```
itsme@antelope ~> guix environment --ad-hoc man-db hello
substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0%
substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/w623j5spid7kyxjdp6xbgxs2r5scpjkn-profile.drv
The following profile hooks will be built:
   /gnu/store/14d1mgn1mwz66mj28rwjmnkddskf4zm0-info-dir.drv
   /gnu/store/7rrkqrdpxahk8g0927d56lpgz3n1kl6z-manual-database.drv
   /gnu/store/8h76m85hiyilv0mj053i9n7k2nxb0wf1-ca-certificate-bundle.drv
   /gnu/store/ia5d18hpmza375dizljqi2x12zlirwqi-fonts-dir.drv
building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 2 packages...
Welcome to fish, the friendly interactive shell
itsme@antelope ~ [Guix env: /gnu/store/9qv380..]>
```

bug#40889: CI system displays unix timestamp as duration

[Jonathan Frederickson]

This page for example says the build took "1586990816 seconds”: 
http://ci.guix.gnu.org/build/2602653/details 


…but it appears that’s actually the timestamp of the end of the build.

bug#35574: bcm5974 touchpad is not recognized as touchpad

[pelzflorian (Florian Pelz)]

On Tue, Apr 21, 2020 at 12:26:07AM +0200, Bengt Richter wrote:
> Could the module be needed "just in case" in an initrd
> but should be unloaded before pivoting in a normal case?

I don’t think normal USB mice need the module because they use the
usbhid kernel module.  Maybe there are exotic mice, but I don’t think
they are important (see the message where I attached the patch now).

Regards,
Florian

bug#40887: No substitutes for libreoffice / vigra

[Leo Famulari]

ci.guix.gnu.org is having trouble building vigra (a dependency of
libreoffice) because the build times out after 1 hour of silence [0]:

--
[ 94%] Linking CXX executable test_threadpool
cd /tmp/guix-build-vigra-1.11.1.drv-0/build/test/threadpool && 
/gnu/store/iz9500ssxcqlyr74hg1jq10ycrh42yq1-cmake-minimal-3.15.1/bin/cmake -E 
cmake_link_script CMakeFiles/test_threadpool.dir/link.txt --verbose=1
/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin/c++  -std=c++11 
-pthread 
-I/gnu/store/mh501jvl3hl2fja4n1iial5zjy36qrys-ilmbase-2.4.1/include/OpenEXR 
-ffloat-store -O2 -g -DNDEBUG  -rdynamic 
CMakeFiles/test_threadpool.dir/test.cxx.o 
CMakeFiles/test_threadpool.dir/testsuccess.cxx.o  -o test_threadpool 
Running test_threadpool
cd /tmp/guix-build-vigra-1.11.1.drv-0/build/test/threadpool && 
./run_test_threadpool.sh
building of `/gnu/store/mfnzxkhj4hiayk9lbb7vp5qxa9qjm1li-vigra-1.11.1.drv' 
timed out after 3600 seconds of silence
@ build-failed /gnu/store/mfnzxkhj4hiayk9lbb7vp5qxa9qjm1li-vigra-1.11.1.drv - 
timeout
--

It takes a lot of resources to build this package and people are
reporting difficulties on the mailing lists and IRC [1]. Is there anything
we can do to make it more likely to build on the CI servers?

[0] https://ci.guix.gnu.org/build/2613103/details
[1] https://bugs.gnu.org/40789
http://logs.guix.gnu.org/guix/2020-04-27.log#002722

bug#40885: [XFCE]: thunar does not support sftp

[Jonathan Brielmaier]

If you wanna open a file in thunar remotely via sftp, it does not work.
It's seems that our thunar package does not have sftp support.

SFTP and other remote protocols are supported via the gvfs (already
packaged in guix). Adding gvfs as input could increase the dependency
size of thunar by a few hundred MiB.

bug#40884: [XFCE]: thunar: Browse Network does not work

[Jonathan Brielmaier]

As of Guix 1.1.0 you can not open the tab "Browse Network" in XFCE's
thunar. There is just a popup window with this error message: "Failed to
open".

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Jack Hill]

Some additional observations:

With my patched webkitgtk, if I set:

PULSE_CLIENTCONFIG=/gnu/store/zc4dsmvdabi00nvisrjhi9w00ff4igs7-client.conf

it does work, which is an improvement compared to without the patch.

I notice that Nix [0] has a similar patch:

"""
diff -ru 
old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
 webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
--- 
old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp
   2019-09-09 04:47:07.0 -0400
+++ 
webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp   
2019-09-20 21:14:10.537921173 -0400
@@ -585,7 +585,7 @@
 { SCMP_SYS(keyctl), nullptr },
 { SCMP_SYS(request_key), nullptr },

-// Scary VM/NUMA ops 
+// Scary VM/NUMA ops

 { SCMP_SYS(move_pages), nullptr },
 { SCMP_SYS(mbind), nullptr },
 { SCMP_SYS(get_mempolicy), nullptr },
@@ -724,6 +724,10 @@
 "--ro-bind-try", "/usr/local/lib64", "/usr/local/lib64",

 "--ro-bind-try", PKGLIBEXECDIR, PKGLIBEXECDIR,
+
+// Nix Directories
+"--ro-bind", "@storeDir@", "@storeDir@",
+"--ro-bind", "/run/current-system", "/run/current-system",
 };
 // We would have to parse ld config files for more info.
 bindPathVar(sandboxArgs, "LD_LIBRARY_PATH");
"""

[0] 
https://github.com/NixOS/nixpkgs/blob/465566948393cf533e3617704d1c4ccc34cf3753/pkgs/development/libraries/webkitgtk/fix-bubblewrap-paths.patch

so I wonder if I didn't do the mounts in the right place and or if it is 
becasue I missed /run/current-system.


I'm going to try to adapt the Nix patch to see if that helps.

Best,
Jack

bug#40882: website: screenshots should show configuration.scm

[Jonathan Brielmaier]

A German youtuber did a review of Guix System[0]. He couldn't find the
configuration.scm file of his system, because he looked at
https://guix.gnu.org/screenshots/virtual-machine/. On the screenshot
it's named os-config.scm, so he searched via find. But couldn't find it.

I think we should recreate this screenshot and show the file as
configuration.scm or even as /run/current-system/configuration.scm :)

What do you think?

[0] https://www.youtube.com/watch?v=IKsXecNJ_nE

bug#40881: References to time zones should not be kept

[Leo Famulari]

Go packages are also keeping references to tzdata, probably because of
the tzdata-path variable in our Go compiler package definitions.

bug#40881: References to time zones should not be kept

[Leo Famulari]

Time zones of Earth are changed several times per year, both for future
and past dates. In order to ensure that our clocks display the correct
time, Guix needs to keep our time zone package (tzdata) up to date.

However, the current situation makes this impractical, because changing
tzdata causes ~1400 package rebuilds per-architecture (`guix refresh -l
tzdata`).

We should make sure that packages which use time zones look up the time
zones dynamically, at run-time, rather than recording a store reference
to the tzdata package, which will be obsolete in months, at the latest.

I used `guix graph --type=reverse-package tzdata` to start, and found
that the main culprit here is bluez, which depends on tzdata via
libical.

Using the attached patch, we can make libical look up time zones at
runtime with the $TZDIR environment variable. Bluez still builds with
this; I'm not sure what it does with libical and if it still works
correctly.

However, this makes evolution-data-server test suite fail. I'm not sure
how to fix evolution-data-server correctly. The fine points of looking
up time zones in evolution-data-server were already discussed:

>From 29bd8e4b8fcd332f110dc6d7bb99755300b76299 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Thu, 16 Apr 2020 15:50:40 -0400
Subject: [PATCH] gnu: libical: Dynamically bind the time zones with TZDIR.

* gnu/packages/patches/libical-honor-TZDIR.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/calendar.scm (libical)[source]: Use it.
[arguments]: Remove the 'patch-paths' phase.
[inputs]: Remove tzdata.
---
 gnu/local.mk  |  1 +
 gnu/packages/calendar.scm | 24 +++--
 .../patches/libical-honor-TZDIR.patch | 36 +++
 3 files changed, 42 insertions(+), 19 deletions(-)
 create mode 100644 gnu/packages/patches/libical-honor-TZDIR.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 9f212434a9..0b7569b245 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1075,6 +1075,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/jsoncpp-fix-inverted-case.patch \
   %D%/packages/patches/julia-SOURCE_DATE_EPOCH-mtime.patch \
   %D%/packages/patches/kdbusaddons-kinit-file-name.patch   \
+  %D%/packages/patches/libical-honor-TZDIR.patch   \
   %D%/packages/patches/libnftnl-dont-check-NFTNL_FLOWTABLE_SIZE.patch  \
   %D%/packages/patches/libvirt-create-machine-cgroup.patch \
   %D%/packages/patches/libziparchive-add-includes.patch\
diff --git a/gnu/packages/calendar.scm b/gnu/packages/calendar.scm
index 81b2b436c1..701cd7d6aa 100644
--- a/gnu/packages/calendar.scm
+++ b/gnu/packages/calendar.scm
@@ -119,6 +119,8 @@ the  library for handling time zones and leap 
seconds.")
(base32
 "1z33wzaazbd7drl6qbh1750whd78xl2cg0gjnxyya9m83vgndgha"))
   (patches
+(append
+  (search-patches "libical-honor-TZDIR.patch")
;; Add a patch slated for 3.0.8 which preserves backwards-
;; compatibility in the icalattach_new_from_data() function,
;; which accidentally changed in 3.0.7 and could break some 
uses.
@@ -132,34 +134,18 @@ the  library for handling time zones and leap 
seconds.")
(file-name 
"libical-3.0.7-preserve-icalattach-api.patch")
(sha256
 (base32
- 
"0v8qcxn8a6sh78grzxd61j9478928dx38l5mf8mkdrbxv47vmvvp")))
+ 
"0v8qcxn8a6sh78grzxd61j9478928dx38l5mf8mkdrbxv47vmvvp"
 (build-system cmake-build-system)
 (arguments
  '(#:tests? #f ; test suite appears broken
-   #:configure-flags '("-DSHARED_ONLY=true")
-   #:phases
-   (modify-phases %standard-phases
- (add-before 'configure 'patch-paths
-   (lambda* (#:key inputs #:allow-other-keys)
- ;; TODO: libical 3.1.0 supports using TZDIR instead of a 
hard-coded
- ;; zoneinfo database.  When that is released we can drop
- ;; the tzdata dependency.
- (let ((tzdata (assoc-ref inputs "tzdata")))
-   (substitute* "src/libical/icaltz-util.c"
- (("\\\"/usr/share/zoneinfo\\\",")
-  (string-append "\"" tzdata "/share/zoneinfo\""))
- (("\\\"/usr/lib/zoneinfo\\\",") "")
- (("\\\"/etc/zoneinfo\\\",") "")
- (("\\\"/usr/share/lib/zoneinfo\\\"") "")))
- #t)
+   #:configure-flags '("-DSHARED_ONLY=true")))
 (native-inputs
  `(("gtk-doc" ,gtk-doc)
("perl" ,perl)
("pkg-config" ,pkg-config)))
 (inputs
  `(("glib" ,glib)
-   ("libxml2" ,libxml2)
-   ("tzdata" ,tzdata)))
+   ("libxml2" ,libxml2)))
 (propagated-inputs
  ;; In Requires.private of libical.pc.
  

bug#40880: [XFCE]: No webbrowser installed by default

[Jonathan Brielmaier]

If you install XFCE and you want to start the webbrowser via the bottom
line or the Applications menu, you get a dialog "Choose Preferred
Application" instead of a launching web browser.

That's because no web browser is installed with XFCE.

bug#40381: Guix shouldn't request substitutes for profile derivations

[Ludovic Courtès]

Hi,

pkill9  skribis:

>> Can you show more precisely what you mean by pasting a command and its
>> output?
>> 
>> With the recent changes in the implementation of grafts, what happens
>> is usually this:
>> 
>>   $ guix build foo
>>   updating the list of substitutes…
>>   The following things will be built/downloaded:
>>   …
>> 
>>   updating the list of substitutes…
>>   The following things will be built/downloaded:
>>   …
>> 
>> The second stage here typically includes profile.drv as well as
>> grafts. All this is expected behavior.
>
> I think that since profile.drv is always produced locally on the
> machine, then it's unnecessary to update the list of substitutes
> when it's on that second stage.

I don’t observe this, or rather I cannot blame profile.drv for this.

Can you show more precisely what you mean by pasting a command and its
output?

Thanks,
Ludo’.

bug#39302: XFCE user cannot log out, shutdown, or reboot via GUI

[Jonathan Brielmaier]

Hi Jesse,

can you still reproduce this? For me at guix 1.1.0-4affa91 (current
core-updates) log out, shutdown and reboot does work.

bug#40832: alsa-lib cannot find its plugins

[Leo Famulari]

I propose we make alsa-lib respect an environment variable
ALSA_PLUGIN_DIRS, and make that a Guix package search path that matches
'lib/alsa-lib'. I think this will do what we need. Any feedback?

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

[Stefan]

Hi!

I have a guix system and my user account has no package installed yet. After 
installing the first package – git-minimal in my case – this message is printed 
and I get this error when trying to use the new command:

building profile with 1 package...
Hinweis: Vielleicht möchten Sie die nötigen Umgebungsvariablen festlegen, indem 
Sie dies ausführen:

 GUIX_PROFILE="/home/stefan/.guix-profile"
 . "$GUIX_PROFILE/etc/profile"

Sie können sie auch mit `guix package --search-paths -p 
"/home/stefan/.guix-profile"' nachlesen.

stefan@guix ~$ git show
-bash: git: Kommando nicht gefunden.


The problem is that without a single package installed there is no user 
profile-link present:


stefan@guix ~$ echo $PATH
/run/setuid-programs:/home/stefan/.config/guix/current/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin


This is of course easily solved by either following the hint or a logout and 
login:


stefan@guix ~$ exit
Abgemeldet
Connection to raspberry closed.
Computer:~ stefan$ ssh stefan@raspberry
Last login: Sun Apr 26 13:59:31 2020 
stefan@guix ~$ echo $PATH
/run/setuid-programs:/home/stefan/.config/guix/current/bin:/home/stefan/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin


However, this gives a bad first impression to users. Moreover users may think 
that a logout/login cycle or manually following the hint could be necessary 
after each package installation. They may get annoyed by this.


Bye

Stefan

bug#40381: Guix shouldn't request substitutes for profile derivations

[pkill9]

Hi Ludovic

> Can you show more precisely what you mean by pasting a command and its
> output?
> 
> With the recent changes in the implementation of grafts, what happens
> is usually this:
> 
>   $ guix build foo
>   updating the list of substitutes…
>   The following things will be built/downloaded:
>   …
> 
>   updating the list of substitutes…
>   The following things will be built/downloaded:
>   …
> 
> The second stage here typically includes profile.drv as well as
> grafts. All this is expected behavior.

I think that since profile.drv is always produced locally on the
machine, then it's unnecessary to update the list of substitutes
when it's on that second stage.

bug#40870: Quassel IRC client trying to open links with xdg-open from a nonexisting store path

[pkill9]

From the output:

```
2020-04-26 16:45:17 [Warn ] Launch failed
(/gnu/store/jsqihy7z3bsbiixchk19dsnaj6bh9h2b-xdg-utils-1.1.3/bin/xdg-open
https://freenode.net)
```

I assume it is recording the absolute path to xdg-open somewhere when
it's first run or something, but I can't find any references to it in
the configuration directory.

bug#40858: Cargo in Guix

[Julien Lepiller]

Le 25 avril 2020 18:17:16 GMT-04:00, Jan Ole Zabel  a 
écrit :
>Hi,
>
>I just installed the rust package on guix-system and realized I have no
>idea of how to use `cargo` to build something. First, cargo is not in
>my
>search path after installing `rust`, because there is no link in
>`.guix-profile`. There is no dedicated package either. 

The rust package has multiple outputs. Its default output doesn't contain 
cargo, but it has a cargo output which you found in the store. You can install 
it with:

guix install rust:cargo

>Second, the
>cargo binary installed in `/gnu/store/` throws the following:
>
>   $ /gnu/store/*-rust-1.39.0-cargo/bin/cargo install ripgrep
>   error: failed to download from
>`https://crates.io/api/ripgrep/12.0.1/download`
>   
>   Caused by:
> [60] SSL peer certificate or SSH remote key not found (server
>certificate verification failed. CAfile: none CRLFile: none)
>
>A `curl https://crates.io` works normally, so it's not an issue with
>the
>system certificates.

My guess is that curl comes from your foreign system? Guix packages don't read 
the global location. Have you performed these additional steps after installing 
guix?

http://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html#X_002e509-Certificates

>
>Am I doing something wrong? Is this even the right place to report or
>ask?

guix-help would have been a better place for this one I think.

I hope this helped a bit :)

Hi,

bug#40867: guix build --rounds=N is miss advising

[Jonathan Brielmaier]

The help section for `guix build --rounds=N` in 7.1.1 Common Build
Options is miss advising.

```
Note that, currently, the differing build results are not kept
around, so you will have to manually investigate in case of an
error—e.g., by stashing one of the build results with ‘guix archive
--export’ (*note Invoking guix archive::), then rebuilding, and finally
comparing the two results.
```

Should rather endorse `guix build --rounds=N --keep-failed` as this
option preservers all differing builds, not only one. This option was
proposed by Marius Bakke in IRC.