bug#43773: [PATCH] offload: Improve load normalization and configurability.

[Maxim Cournoyer]

Fixes .

The computed normalized load was previously obtained by dividing the load
average as found in /proc/loadavg by the number of parallel builds defined for
a build machine.

This normalized didn't allow to compare machines with different number of
cores, as the load average reported by can be as high as the number of cores;
thus comparing that value to a fixed threshold of 2.0 would mean machines with
multiple cores were more likely to be flagged as overloaded compared to single
core machines.

This can be fixed by normalizing using the available number of cores instead
of the number of parallel jobs.

* guix/scripts/offload.scm ()[overload-threshold]: New field.
(node-load): Modify to return a normalized load value between 0 and 1, taking
into account the number of cores available.
(normalized-load): Remove procedure.
(report-load): New procedure.
(choose-build-machine): Adjust to use the modified 'node-load' and the new
'report-load' and 'build-machine-overload-threshold' procedures.
(check-machine-status): Adjust.
* doc/guix.texi (Daemon Offload Setup): Document the offload scheduler and the
new 'overload-threshold' field.
---
 doc/guix.texi| 30 +-
 guix/scripts/offload.scm | 54 
 2 files changed, 62 insertions(+), 22 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index a6260a12aa..1d5adbeb63 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1081,7 +1081,28 @@ architecture natively supports it, via emulation 
(@pxref{Transparent
 Emulation with QEMU}), or both.  Missing prerequisites for the build are
 copied over SSH to the target machine, which then proceeds with the
 build; upon success the output(s) of the build are copied back to the
-initial machine.
+initial machine.  The offload facility comes with a basic scheduler that
+attempts to select the best machine.  The best machine is chosen among
+the available machines based on criteria such as:
+
+@enumerate
+@item
+The availability of a build slot.  A build machine can have as many
+build slots (connections) as the value of the @code{parallel-builds}
+field of its @code{build-machine} object.
+
+@item
+Its relative speed, as defined via the @code{speed} field of its
+@code{build-machine} object.
+
+@item
+Its load.  The normalized machine load must be lower than a threshold
+value, configurable via the @code{overload-threshold} field of its
+@code{build-machine} object.
+
+@item
+Disk space availability.  More than a 100 MiB must be available.
+@end enumerate
 
 The @file{/etc/guix/machines.scm} file typically looks like this:
 
@@ -1185,6 +1206,13 @@ when transferring files to and from build machines.
 File name of the Unix-domain socket @command{guix-daemon} is listening
 to on that machine.
 
+@item @code{overload-threshold} (default: @code{0.6})
+The load threshold above which a potential offload machine is
+disregarded by the offload scheduler.  The value roughly translates to
+the total processor usage of the build machine, ranging from 0.0 (0%) to
+1.0 (100%).  It can also be disabled by setting
+@code{overload-threshold} to @code{#f}.
+
 @item @code{parallel-builds} (default: @code{1})
 The number of builds that may run in parallel on the machine.
 
diff --git a/guix/scripts/offload.scm b/guix/scripts/offload.scm
index 3dc8ccefcb..a5fe98b675 100644
--- a/guix/scripts/offload.scm
+++ b/guix/scripts/offload.scm
@@ -88,6 +88,10 @@
  (default 3))
   (daemon-socket   build-machine-daemon-socket; string
(default "/var/guix/daemon-socket/socket"))
+  ;; A #f value tells the offload scheduler to disregard the load of the build
+  ;; machine when selecting the best offload machine.
+  (overload-threshold build-machine-overload-threshold ; inexact real between
+  (default 0.6))   ; 0.0 and 1.0 | #f
   (parallel-builds build-machine-parallel-builds  ; number
(default 1))
   (speed   build-machine-speed; inexact real
@@ -391,30 +395,34 @@ of free disk space on '~a'~%")
   (* 100 (expt 2 20)));100 MiB
 
 (define (node-load node)
-  "Return the load on NODE.  Return +??? if NODE is misbehaving."
+  "Return the load on NODE, a normalized value between 0.0 and 1.0.  The value
+is derived from /proc/loadavg and normalized according to the number of
+logical cores available, to give a rough estimation of CPU usage.  Return
+1.0 (fully loaded) if NODE is misbehaving."
   (let ((line (inferior-eval '(begin
 (use-modules (ice-9 rdelim))
 (call-with-input-file "/proc/loadavg"
   read-string))
- node)))
-(if (eof-object? line)
-+inf.0 ;MACHINE does not respond, so assume it is infinitely loaded
+ node))
+(ncores 

bug#43518: Guix substitute crash in procedure raise-exception: wrong type agument in position 1: #f

[Maxim Cournoyer]

Hello!

Ludovic Courtès  writes:

[...]

> The “@ download-progress” line is printed by (guix scripts substitute)
> and later consumed by (guix status) in the client, which is why I
> mentioned ‘progress-reporter/trace’ above.
>
> I think the problem we’re looking at could occur if those traces are not
> printed in an atomic way, and thus (guix status) gets to see
> truncated/mixed up traces.  So I tried this:
>
>   _NIX_OPTIONS=print-extended-build-trace=1 sudo -E \
> ./pre-inst-env strace -s 200 -o ,,s  guix substitute \
>--substitute 
> /gnu/store/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0 /tmp/t.drv
>
> It shows that traces are printed in a single write(2) call:
>
> write(2, "@ download-progress /tmp/t.drv 
> http://ci.guix.gnu.org/nar/lzip/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0
>  4843 4843\n", 127) = 127
>
> So this side of things seems to be good.  But then traces could be
> mangled/truncated by the daemon maybe.  An strace log of the failing
> case would be very helpful.

Not sure this matters or not, but thought I'd add the information here
in case:  the ntpd service was stopped for unkown reasons on my local
machine, leading to 'guix offload status' to output the following
warning:

guix offload: warning: machine '127.0.0.1' is 106 seconds behind

I've since restarted the ntpd service and that warning disappeared.

Maxim

bug#43783: ssh-copy-id: line 254: /dev/null`: Permission denied

[Nathan Dehnel]

ssh-copy-id errors out and then does not install the key

bash-5.0$ ssh-copy-id pi@raspberrypi
/home/nathan/.guix-profile/bin/ssh-copy-id: INFO: attempting to log in with
the new key(s), to filter out any that are already installed
/home/nathan/.guix-profile/bin/ssh-copy-id: INFO: 2 key(s) remain to be
installed -- if you are prompted now it is to install the new keys
/home/nathan/.guix-profile/bin/ssh-copy-id: line 251: warning:
here-document at line 251 delimited by end-of-file (wanted `EOF')
/home/nathan/.guix-profile/bin/ssh-copy-id: line 250: warning:
here-document at line 250 delimited by end-of-file (wanted `EOF')
/home/nathan/.guix-profile/bin/ssh-copy-id: line 254: /dev/null`:
Permission denied
/home/nathan/.guix-profile/bin/ssh-copy-id: line 260: EOF: command not found
pi@raspberrypi's password:

Number of key(s) added: 2

Now try logging into the machine, with:   "ssh 'pi@raspberrypi'"
and check to make sure that only the key(s) you wanted were added.

bug#43778: protonvpn-cli does not work after update

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Znavko,

zna...@disroot.org 写道：
pkg_resources.DistributionNotFound: The 'jinja2' distribution 
was not found and is required by protonvpn-cli


I verified that it is indeed protonvpn-cli (and not only some 
dependency) that uses jinja2 and added it as input in 
36045fa6d6f6ed240bf26d3040846533e9e35e82.


Thanks!

T G-R


signature.asc
Description: PGP signature

bug#43779: tbb: test_global_control failure

[Christopher Howard]

Attempt to build tbb, a dependency of Octave I think, fails with:

"""
./test_task_scheduler_observer_v3.exe  1:4
done
Call stack info (12):
./test_global_control.exe(_Z16print_call_stackv+0x37)[0x407937]
./test_global_control.exe(_Z11ReportErrorPKciS0_S0_+0x1b)[0x407a3b]
./test_global_control.exe(_ZN3tbb10interface98internal9start_forINS_13b
locked_rangeImEENS_8internal17parallel_for_bodyIN7Harness21ExactConcurr
encyLevelEmEEKNS_18simple_partitionerEE7executeEv+0x327)[0x411067]
./libtbb.so.2(+0x2b7c2)[0x77fb17c2]
./libtbb.so.2(+0x2bb25)[0x77fb1b25]
./libtbb.so.2(+0x29810)[0x77faf810]
./test_global_control.exe(_ZN7Harness21ExactConcurrencyLevel5checkEmNS0
_4ModeE+0x35f)[0x40cbcf]
./test_global_control.exe(_Z23TestParallelismRestoredv+0xd8)[0x409c28]
./test_global_control.exe(_Z8TestMainv+0x2a)[0x40afea]
./test_global_control.exe(main+0xe)[0x40751e]
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-
2.31/lib/libc.so.6(__libc_start_main+0xed)[0x77ad9a6d]
./test_global_control.exe(_start+0x2a)[0x40776a]
../../src/test/harness_concurrency_tracker.h:123, assertion
!myCrashOnFail: Timeout was detected.
make[1]: *** [../../build/Makefile.test:274: test_tbb_plain] Aborted
make[1]: Leaving directory '/tmp/guix-build-tbb-2020.3.drv-0/tbb-
2020.3-checkout/build/guix_release'
make: *** [Makefile:42: test] Error 2

Test suite failed, dumping logs.
command "make" "test" "-j" "3" "LDFLAGS=-Wl,-
rpath=/gnu/store/qc926v75q54k94mwgz6gn4s02sjgrr03-tbb-2020.3/lib"
failed with status 2
"""

I attempted to build this with -M 1 option, but build still dies with
the same error.

My system:

christopher@nightshade ~$ guix describe
Generation 35   Oct 01 2020 20:02:29(current)
  guix 23dc21f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 23dc21f05b54ef63daaea9eb301cfddbc4c82ddb

christopher@nightshade ~$ neofetch --stdout
christopher@nightshade 
-- 
OS: Guix System 23dc21f05b54ef63daaea9eb301cfddbc4c82ddb x86_64 
Host: GA-880GM-UD2H 
Kernel: 5.7.15-gnu 
Uptime: 5 days, 14 hours, 45 mins 
Packages: 103 (guix-system), 84 (guix-user) 
Shell: bash 5.0.16 
Resolution: 1920x1200 
DE: GNOME 3.34.2 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: .gnome-terminal 
CPU: AMD Athlon II X3 455 (3) @ 3.300GHz 
GPU: NVIDIA GeForce 8400 GS Rev. 3 
Memory: 1232MiB / 7960MiB 

-- 
Christopher Howard
p: +1 (907) 374-0257
w: https://librehacker.com
social: https://gnusocial.club/librehacker
gpg: ADDEAADE5D607C8D (keys.gnupg.net)

bug#43778: protonvpn-cli does not work after update

[znavko]

After update and system reconfigure (just for updating services, with the same 
config) `protonvpn c` does not work.

# protonvpn c
Traceback (most recent call last):
 File 
"/gnu/store/p2f0sblw9sxmzl7kzlhm9h1p66pxhdl5-protonvpn-cli-2.2.4/bin/.protonvpn-real",
 line 6, in 
 from pkg_resources import load_entry_point
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3251, in 
 def _initialize_master_working_set():
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3234, in _call_aside
 f(*args, **kwargs)
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3263, in _initialize_master_working_set
 working_set = WorkingSet._build_master()
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 583, in _build_master
 ws.require(__requires__)
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 900, in require
 needed = self.resolve(parse_requirements(requirements))
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 786, in resolve
 raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'jinja2' distribution was not found and 
is required by protonvpn-cli

# guix package -r protonvpn-cli
# guix package -i protonvpn-cli

# protonvpn c
Traceback (most recent call last):
 File 
"/gnu/store/p2f0sblw9sxmzl7kzlhm9h1p66pxhdl5-protonvpn-cli-2.2.4/bin/.protonvpn-real",
 line 6, in 
 from pkg_resources import load_entry_point
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3251, in 
 def _initialize_master_working_set():
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3234, in _call_aside
 f(*args, **kwargs)
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 3263, in _initialize_master_working_set
 working_set = WorkingSet._build_master()
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 583, in _build_master
 ws.require(__requires__)
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 900, in require
 needed = self.resolve(parse_requirements(requirements))
 File 
"/gnu/store/09a5iq080g9b641jyl363dr5jkkvnhcn-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py",
 line 786, in resolve
 raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'jinja2' distribution was not found and 
is required by protonvpn-cli
# guix describe
Generation 28 Oct 03 2020 13:11:47 (current)
 guix f7f5caf
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: f7f5caf7ea78d2c257a081c8fcf212e507fe2ab6

bug#43760: cuirass: fail to install with simple configuration

[Mathieu Othacehe]

> Would be great :)

Done with b3f5402d2d506271857d2c987b79b741d4b0ec33.

Mathieu

bug#43760: cuirass: fail to install with simple configuration

[Jonathan Brielmaier]

On 03.10.20 12:46, Mathieu Othacehe wrote:
>
> Hello Jonathan,
>
>>> You will then probably hit this one:
>>>
>>> https://issues.guix.gnu.org/43757
>>
>> I do :(
>
> After fixing this issue, see: 761443bca6178b4ac299a8bd368d1cac4abda5f8,
> I'm able to successfully evaluate and build your specification.
>
> I still need to update the Cuirass package accordingly.

Would be great :)
Thanks

bug#43757: cuirass: Fail to fetch "guix" input.

[Mathieu Othacehe]

Hey Ludo,

> ‘par-map’ is implemented in terms of futures, and futures use their own
> thread pool.  What’s likely to block is ‘touch’: it essentially waits on
> a condition variable, which Fibers cannot interrupt.

I see, thanks for explaining.

> Why not just replace ‘par-map’ with ‘map’?  That sounds easier and I
> suspect it doesn’t change much performance-wise.

The objective was to still be able to run parallel input fetching, but
you're right, a simple "map" is nicer.

> (There’s a 2nd use of ‘par-map’ in that file.)

Oh! Fixed too.

Thanks for the quick answer,

Mathieu

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[zimoun]

Dear,

On Fri, 02 Oct 2020 at 20:08, Giovanni Biscuolo  wrote:

> I'm not very good in the triage of this bug: after a lot of trial and
> error I was almost sure I found a conflicting package (emacs-hl-todo,
> required by emacs-magit-todos) BUT I was NOT able to reproduce the bug
> in a pure environment

[...]

> In that environment's emacs session I get an init.el loading error, but
> I'm able to eval-buffer this:

That's because your init.el and guix.scm do not match.  For example, you
are using ’use-package’ inside ’init.el’ without installing it, I mean
it does not appear neither inside ’guix.scm’ –– I do not understand from
where it comes from.  Therefore, I am not sure about the option ’–pure’
but the option ’–container’ should raise an error.  Do I miss something?


> ;; -*- mode: emacs-lisp -*-
> (unless (require 'guix-emacs nil 'noerror)
>  (package-initialize))
> (unless (require 'guix-emacs nil 'noerror)
>  ;; package archives
>  (when (>= emacs-major-version 24)
>(require 'package)
>(setq package-archives
>'(("GNU_ELPA" . "https://elpa.gnu.org/packages/;)
>  ("org"  . "https://orgmode.org/elpa/;)
>  ("MELPA_Stable" . "https://stable.melpa.org/packages/;)
>  ("MELPA". "https://melpa.org/packages/;))
>package-archive-priorities
>'(("GNU_ELPA" . 15)
>  ("org"  . 10)
>   ("MELPA_Stable" . 5)
>  ("MELPA". 0)

>From my experience, I do not mix packages from Emacs archives and from
Guix because it often leads to weirdness –– unexpected behaviour at
least…  Personally, I have removed the use of all the ‘package.el’
functions and only use packages ’emacs-*’ from Guix and then configure
them using ’with-eval-after-load’.


> (unless (require 'guix-emacs nil 'noerror)
>  (use-package emojify

>From where the package ’use-package’ comes from?


>:ensure t
>:pin "GNU_ELPA"))

If you use a manifest.scm file, why do you need ’use-package’ and ELPA.
If ’emojify’ is not in Guix, please try to submit a patch – using “guix
import elpa” helps.


> (unless (require 'guix-emacs nil 'noerror)
>  (use-package tramp
>:ensure t
>:pin "GNU_ELPA"))

Well, ’use-package’ does lazy evaluations if I remember correctly.  So
why do you explicitly ’require’ it just after?

> (require 'tramp)

AFAIU, it should be better to do:

(use-package tramp
  :ensure t
  :defer t
  :pin “GNU_ELPA

  :init
  ;; eval at init time

  :config
  ;; eval at use time
  ;; your TRAMP config
  (setq tramp-remote-path …)
  …)

or to add ’emacs-tramp’ to your manifest.scm file and then write:

(with-eval-after-load ’tramp
  ;; your TRAMP config
  (setq tramp-remote-path …)
  …)

(Note I do not know about TRAMP, so maybe ’tramp-remote-path’ should be
evaluated at init time and not at use time.  Aside the fact that TRAMP
is part of vanilla Emacs, AFAICT.)


> (unless (require 'guix-emacs nil 'noerror)
>  (use-package org
>:mode (("\\.org$" . org-mode))
>:ensure org-plus-contrib
>:pin org))

[...]

> (require 'org-id)
> (require 'org-toc)
> (require 'org-tempo)

Because of this mess about evaluating order, I am not sure this is
correct.  Instead, you should write something like:

(use-package org
  …
  :config
  (require 'org-tempo))

or instead the ’(require 'org-tempo)’ in your init.el, something like:

(use-package org-tempo
  :ensure t
  :defer t
  :after org)


>From my understanding, you are misusing ’use-package’.  Or you could
rewrite:

(with-eval-after-load 'org
  (require 'org-tempo))

(And I am personally doing that.)


Last, your starting time should be pretty long, right?  Hum?  IMHO, it
could be really faster if you use ’with-eval-after-load’ or
’(use-package foo :defer t …)’ and so enjoy the speedup by “lazy”
evaluation.


> ;; This file is automatically generated via init.org
> ;; PLEASE do not edit this, edit init.org
> (specifications->manifest
>  '("gs-fonts"
>"font-dejavu"
>"font-gnu-freefont"
>"unicode-emoji"
>"emacs"
>  "emacs-emojify"

And you have ’(use-package emojify :ensure t)’, it appears to me a bad
idea.  And I am pretty sure that leads to issues.  Choose if the
packages come from ELPA _or_ Guix, IMHO.


> ))

I could have misread, but no ’emacs-use-package’.


Hope that helps,
simon

bug#43757: cuirass: Fail to fetch "guix" input.

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

>> ERROR: In procedure make-stack:
>> Attempt to suspend fiber within continuation barrier
>
> Turns out "par-map" call does not seem suspendable, even though I'm not
> sure why. Maybe Ludo can help here :) ?

‘par-map’ is implemented in terms of futures, and futures use their own
thread pool.  What’s likely to block is ‘touch’: it essentially waits on
a condition variable, which Fibers cannot interrupt.

I’d say that mixing fibers and ‘par-map’ is a bad idea.  :-)

If we need such a thing, I think we should implement it on top of
Fibers.  Implementing futures on top of fibers + channels should be
easier than what (ice-9 futures) does.

> This is fixed with: 761443bca6178b4ac299a8bd368d1cac4abda5f8.

Why not just replace ‘par-map’ with ‘map’?  That sounds easier and I
suspect it doesn’t change much performance-wise.

(There’s a 2nd use of ‘par-map’ in that file.)

Thanks,
Ludo’.

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[pelzflorian (Florian Pelz)]

On Sat, Oct 03, 2020 at 12:04:37PM +0200, Ludovic Courtès wrote:
> > I verified the attached patch fixes glib on the ‘master’ branch.
> If you tested it on ‘master’, you can push it on ‘core-updates’.

Pushed as 0585a0d0d1fe6e334d36e2d851b42b47d6769546.  Thank you!

Closing, since the issue is documented now and fixing *all* other
check phases is generally not worth it.

Regards,
Florian

bug#43760: cuirass: fail to install with simple configuration

[Mathieu Othacehe]

Hello Jonathan,

>> You will then probably hit this one:
>>
>> https://issues.guix.gnu.org/43757
>
> I do :(

After fixing this issue, see: 761443bca6178b4ac299a8bd368d1cac4abda5f8,
I'm able to successfully evaluate and build your specification.

I still need to update the Cuirass package accordingly.

Thanks,

Mathieu

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Thu, Oct 01, 2020 at 11:07:54PM +0200, Ludovic Courtès wrote:
>> Oh, we should fix ‘glib’ in ‘core-updates’.
>
> I verified the attached patch fixes glib on the ‘master’ branch.  I’m
> not sure about adding a copyright.  Anyway.  Shall I push it to
> ‘core-updates’ or wait until I can test it on ‘core-updates’ without
> rebuilding the world?

If you tested it on ‘master’, you can push it on ‘core-updates’.

> I changed it and pushed the patch to the documentation as
> 3c01fcc1bb9c086f487d9694cb91a57d7abd0880.  Thank you!

Great!

> (I maybe should have written in the commit message “Fixes
> .”  Oh well.  I will leave the bug open
> though because glib is not fixed yet.)

That’s OK.  :-)

> From 505cfd0fa3411a21c8794ab84473dc1dd2b8754c Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Sat, 3 Oct 2020 00:29:56 +0200
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Subject: [PATCH] gnu: glib: Adhere to '--without-tests' option.
>
> * gnu/packages/glib.scm (glib)[arguments]<#:phases>[configure]:
> Only run tests if 'tests?' is true.

OK for ‘core-updates’, thank you!

Ludo’.

bug#43579: g++ does not provide std::fegetround

[Ludovic Courtès]

Hi,

(Cc’ing Maxim who’s looked into this before.)

Andreas Enge  skribis:

> well, just put these lines into a file called "round.cpp" (as attached),
> and then
>gcc round.cpp

Ah yes, I wasn’t sure if this was ‘gcc-toolchain’ or not.  Only 7.x (the
current ‘gcc-final’) works:

--8<---cut here---start->8---
$ cat t.cpp
#include 
int main () {
   return std::fegetround ();
}

$ guix environment -C --ad-hoc gcc-toolchain@7 -- g++ -Wall -c t.cpp
$ guix environment -C --ad-hoc gcc-toolchain -- g++ -Wall -c t.cpp
t.cpp: In function 'int main()':
t.cpp:3:16: error: 'fegetround' is not a member of 'std'; did you mean 
'fegetround'?
3 |return std::fegetround ();
  |^~
In file included from 
/gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/c++/fenv.h:36,
 from 
/gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/c++/cfenv:41,
 from t.cpp:1:
/gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/fenv.h:104:12: 
note: 'fegetround' declared here
  104 | extern int fegetround (void) __THROW __attribute_pure__;
  |^~
$ guix describe
Generacio 162   Oct 01 2020 00:23:38(nuna)
  guix 7607ace
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7607ace5091aea0157ba5c8a508129cc5fc4f931
--8<---cut here---end--->8---

It’s the same story as .

> The difference to the Opensuse headers is that in bits/c++config.h,
> they define _GLIBCXX_USE_C99_FENV_TR1, which, as I understand it,
> removes the fe* functions from the global namespace to put them back into
> the std:: namespace.

Indeed, the build log of ‘gcc-10’ for instance has this:

--8<---cut here---start->8---
checking fenv.h usability... yes
checking fenv.h presence... yes
checking for fenv.h... yes
checking for complex.h... (cached) yes
checking for complex.h... (cached) yes
checking for ISO C99 support to TR1 in ... yes
checking for ISO C99 support to TR1 in ... yes
checking for fenv.h... (cached) yes
checking for ISO C99 support to TR1 in ... no
--8<---cut here---end--->8---

Here’s the ‘prev-x86_64-unknown-linux-gnu/libstdc++-v3/config.log’
excerpt:

--8<---cut here---start->8---
configure:16448: checking for fenv.h
configure:16448: result: yes
configure:16462: checking for ISO C99 support to TR1 in 
configure:16490:  /tmp/guix-build-gcc-10.2.0.drv-0/build/./gcc/xgcc 
-shared-libgcc -B/tmp/guix-build-gcc-10.2.0.drv-0/build/./gcc -nostdinc++ 
-L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src
 
-L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
 
-L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 
-B/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/bin/
 
-B/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/lib/
 -isystem 
/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/include
 -isystem 
/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/sys-include
   -fno-checking -c -g -O2 -D_GNU_SOURCE -std=c++98  conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:102:7: error: 'fexcept_t' was not declared in this scope; did you 
mean 'except'?
  102 |   fexcept_t* pflag;
  |   ^
  |   except
conftest.cpp:102:18: error: 'pflag' was not declared in this scope
  102 |   fexcept_t* pflag;
  |  ^
conftest.cpp:103:7: error: 'fenv_t' was not declared in this scope
  103 |   fenv_t* penv;
  |   ^~
conftest.cpp:103:15: error: 'penv' was not declared in this scope
  103 |   fenv_t* penv;
  |   ^~~~
conftest.cpp:105:13: error: 'feclearexcept' was not declared in this scope
  105 |   ret = feclearexcept(except);
  | ^
conftest.cpp:106:13: error: 'fegetexceptflag' was not declared in this scope
  106 |   ret = fegetexceptflag(pflag, except);
  | ^~~
conftest.cpp:107:13: error: 'feraiseexcept' was not declared in this scope
  107 |   ret = feraiseexcept(except);
  | ^
conftest.cpp:108:13: error: 'fesetexceptflag' was not declared in this scope
  108 |   ret = fesetexceptflag(pflag, except);
  | ^~~
conftest.cpp:109:13: error: 'fetestexcept' was not declared in this scope
  109 |   ret = fetestexcept(except);
  | ^~~~
conftest.cpp:110:13: error: 'fegetround' was not declared in this scope
  110 |   ret = fegetround();
  | ^~
conftest.cpp:111:13: error: 'fesetround' was not declared in this scope
  111 

bug#43518: Guix substitute crash in procedure raise-exception: wrong type agument in position 1: #f

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hi,
>>
>> Maxim Cournoyer  skribis:
>>
>>> downloading from 
>>> https://ci.guix.gnu.org/nar/6m9zimmw8p6gbc1yfbg454c1r587b7h4-gcc-10.2.0.tar.xz
>>>  ...
>> […]
>>>  gcc-10.2.0.tar.xz  74.3MiB 1.1MiB/s 
>>> 00:25 [###   ]  39.1%Backtrace:
>> […]
>>> In unknown file:
>>>5 (display "@ substituter-succeeded 
>>> /gnu/store/r06j3ms57z4mzfpdzfclsi3i9hr4184g-module-imp…" …)
>>> In guix/status.scm:
>>>699:16  4 (write! _ _ _)
>>> 613:6  3 (_ (download-progress 
>>> "/gnu/store/6m9zimmw8p6gbc1yfbg454c1r587b7h4-gcc-10.2.0.tar.xz" # …) …)
>>> In guix/progress.scm:
>>>213:14  2 (display-download-progress "6m9zimmw8p6gbc1yfbg454c1r58@" _ 
>>> #:start-time _ #:transferred _ …)
>>> In ice-9/boot-9.scm:
>>>   1669:16  1 (raise-exception _ #:continuable? _)
>>>   1669:16  0 (raise-exception _ #:continuable? _)
>>>
>>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>>> In procedure =: Wrong type argument in position 1: #f
>>
>> If you have a case that’s reproducible, please take advantage of it and
>> add ‘pk’ calls in (guix progress) to see what happens.  Here it seems
>> that ‘transferred’ (in ‘display-download-progress’) is #f.
>>
>> The #f would come from this clause in (guix status):
>>
>>  ('download-progress item uri
>>  (= string->number size)
>>  (= string->number transferred))  ;<- here
>>
>> That in turn comes from ‘progress-reporter/trace’, called from (guix
>> scripts substitute).
>
> It's a bit difficult for me to follow the calls here :-).  I thought
> it'd have to be in 'progress-reporter/file' because that's the only one
> that ends up calling display-download-progress.  The line 213 of (guix
> progress) is:
>
>   (unless (zero? transferred)
>
> and if transferred is #f that would indeed fail with the error message
> shown in the backtrace, so it seems you are correct in your analysis.

That’s correct.

The “@ download-progress” line is printed by (guix scripts substitute)
and later consumed by (guix status) in the client, which is why I
mentioned ‘progress-reporter/trace’ above.

I think the problem we’re looking at could occur if those traces are not
printed in an atomic way, and thus (guix status) gets to see
truncated/mixed up traces.  So I tried this:

  _NIX_OPTIONS=print-extended-build-trace=1 sudo -E \
./pre-inst-env strace -s 200 -o ,,s  guix substitute \
   --substitute 
/gnu/store/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0 /tmp/t.drv

It shows that traces are printed in a single write(2) call:

--8<---cut here---start->8---
write(2, "@ download-progress /tmp/t.drv 
http://ci.guix.gnu.org/nar/lzip/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0
 4843 4843\n", 127) = 127
--8<---cut here---end--->8---

So this side of things seems to be good.  But then traces could be
mangled/truncated by the daemon maybe.  An strace log of the failing
case would be very helpful.

Thanks,
Ludo’.

bug#43736: I think f43ffee... broke guix pull

[Ludovic Courtès]

Hi,

Brendan Tildesley  skribis:

> In gnu/packages/package-management.scm:
>549:20  1 (_)
> In guix/gexp.scm:
> 405:0  0 (%local-file _ _ _ #:literal? _ #:location _ #:recursive? _ 
> #:select? _)
>
> guix/gexp.scm:405:0: In procedure %local-file:
> Invalid keyword: "guix-current"

Indeed.  Fixed in 9471aea76ace5c0998d889fc5fbde7a6bcafc654, thanks!

Ludo’.

bug#43757: cuirass: Fail to fetch "guix" input.

[Mathieu Othacehe]

Hello,

> ERROR: In procedure make-stack:
> Attempt to suspend fiber within continuation barrier

Turns out "par-map" call does not seem suspendable, even though I'm not
sure why. Maybe Ludo can help here :) ?

This is fixed with: 761443bca6178b4ac299a8bd368d1cac4abda5f8.

Thanks,

Mathieu

bug#43738: Patch file names too long

[Ludovic Courtès]

Brett Gilio  skribis:

> Ludovic Courtès  writes:
>
>> There are several patch file names that are too long for ‘tar’, as
>> reported during ‘make dist’:
>>
>> tar: 
>> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/ocaml-bisect-fix-camlp4-in-another-directory.patch
>>  dosiernomo tro longas (maks 99); ne ŝutita
>> tar: 
>> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-signature-of-multiplyCheckOverflow.patch
>>  dosiernomo tro longas (maks 99); ne ŝutita
>> tar: 
>> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch
>>  dosiernomo tro longas (maks 99); ne ŝutita
>> tar: 
>> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/audiofile-division-by-zero-BlockCodec-runPull.patch
>>  dosiernomo tro longas (maks 99); ne ŝutita
>> tar: 
>> guix-1.0.1.22624-c258f1-dirty/gnu/packages/patches/python-robotframework-honor-source-date-epoch.patch
>>  dosiernomo tro longas (maks 99); ne ŝutita
>>
>> ‘guix lint’ reports it as well, but apparently this is easily
>> overlooked.
>>
>> Ludo’.
>
> Does it matter that this is coming from a dirty working tree? Maybe not.

Nope, it doesn’t matter.

Ludo’.

bug#42667: opencv fails to build

[Guillaume Le Vaillant]

This was fixed by 8bf704262d672ae0735f0685bfd1c9ddcb1d8484, closing.


signature.asc
Description: PGP signature

bug#43243: emacs-elfeed-org, mapc: Symbol’s function definition is void

[Giovanni Biscuolo]

Hello,

Sorry Simon for the noise, this is just a quick feedback about my
debugging; next messages will be only to debbugs, you know how to track
it :-D 

Meanwhile I've learned how to test things in a dedicated environment,
thanks to some interesting tips [1] (I ignored before) adapted to Guix;
this confirms (ça va sanse dire) how powerful Guix is!

Giovanni Biscuolo  writes:

[...]

>> Yes, AFAIU it's really a loading order triggered error... and I'm not
>> able to debug this :-(
>
> I've finally found the conflicting configuration!

No, I've actually found a workaround - commenting out "(require
'org-tempo)" in my init.el - that works with my emacs configuration (and
package set) BUT there is absolutely no conflict between org-tempo and
elfeed-org.

I confirm that if I eval "(require 'org-tempo)" I get the previously
reported error and backtrace, I confirm that if I do not remove
(comment) "(require 'org-tempo)" in my "production" init.el elfeed does
not work as reported in the first message of this bug report.

Last but not least, I confirm I had no issues with the same manifest
(I've replaced ghc-pandoc with pandoc but that's tangent) and the same
init.el using Guix Emacs 26.3

So I ceated a directory dedicated to my tests in
~/.emacs-testing.d/test-elfeed, where I put "manifest.scm" and a
"test-elfeed.el" (both attached below, inline).

Well: if I do this

--8<---cut here---start->8---

[~/.emacs-testing.d/test-elfeed]-
giovanni@roquette: guix environment --pure --ad-hoc -m manifest.scm -- emacs -q 
-l test-elfeed.el

--8<---cut here---end--->8---

I get an emacs session with a running elfeed, and "(require 'org-tempo)"
is there.

This is manifest.scm:



manifest.scm
Description: Binary data

This is test-elfeed.el:



test-elfeed.el
Description: application/emacs-lisp


So AFAIU there is no direct conflict between elfeed-org and org-tempo,
that conflict is apparent only in my full init.el configuration (and
package set) and probably is related to a combination of environment and
init.el configuration.

I'm going to investigate more and see what I can do to sort out things.

Happy hacking! Gio'


[1] 
https://gonewest818.github.io/2020/03/a-standalone-init.el-for-emacs-package-debugging/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature