bug#39562: python-keras build fails: test_selu: Not equal to tolerance rtol=1e-07, atol=0

2020-10-04 Thread Maxim Cournoyer
Pierre Neidhardt  writes:

> Patch sent: 39...@debbugs.gnu.org.
> Also see https://github.com/keras-team/keras/issues/13856.

I fixed it with a substitute* instead, and also applied another upstream
fix in commit 5f37d7e38e.

Thanks for the report!

Closing,

Maxim





bug#31403: Font installed in non-default profile doesn't appear.

2020-10-04 Thread Maxim Cournoyer
merge 31403 22138
thanks

Hello,

George Clemmer  writes:

> George Clemmer  writes:
>
>> Alex Kost  writes:
>>
>>> Hello George,
>>>
>>> George Clemmer (2018-05-08 20:04 -0400) wrote:
>>>
 In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed
 by manifest (attached) into the "empty" default profile ...

 'guix package -m manifest'

 ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't
 appear with the same manifest installed in the "foo" profile ...

Assuming you run Emacs in that foo profile and don't see the font,
that's probably because XDG_DATA_DIRS is unset in that other profile.
glib is one of the package setting that variable.

I'm merging this bug with 22138, which would fix the root cause.

Thanks,

Maxim





bug#39511: github auth

2020-10-04 Thread Maxim Cournoyer
Ludovic Courtès  writes:

> Hi Matt,
>
> Matt Wette  skribis:
>
>> I have not gotten into testing, but according to email and references
>> provided previously the patch below might work.
>
> I’ve applied the patch on your behalf, thank you!
>
> Ludo’.

Closing, thanks!

Maxim





bug#39508: Guix cookbook: Broken hyperlink

2020-10-04 Thread Maxim Cournoyer
Hello,

Ludovic Courtès  writes:

> Hi,
>
>> If you open https://guix.gnu.org/cookbook/, and choose a language except 
>> English, It will return 404 Not found.
>> Seems someone just carelessly push the cookbook and without checking the 
>> translations.
>
> Yeah, this is a limitation in the current machinery that build the
> documentation pages—see ‘doc/build.scm’ in the source.
>
> Thanks,
> Ludo’.

This was fixed by Björn in commit 7c65fc378cf last April.

Closing,

Maxim





bug#43531: Hang after power suspend

2020-10-04 Thread Jeffrey Walton
On Wed, Sep 30, 2020 at 1:37 PM Ludovic Courtès  wrote:
>
> Jeffrey Walton  skribis:
>
> > I'm using Guix 1.1 x86_64 in a virtual box VM. I've noticed when the
> > guest enters "power suspend" state I cannot wake it. The guest stops
> > responding over SSH and stops accepting UI input. I have to cycle
> > power to bring it back to life.
> >
> > Power settings are:
> >
> >   * Blank Screen - 15 minutes
> >   * Automatic suspend - Off
> >
> > I don't see other relevant power settings in the Gnome app.
>
> I don’t know what the emulator is doing, but I do know that this works
> well on the bare metal.  :-)
>
> Do you have similar issues with other distros/OSes hanging about suspend
> in that emulator?

I had no other problems until today.

Today, I installed Ubuntu 20.04 in a VM for testing. It is exhibiting
similar problems. In the Ubuntu case, it is not hanging. Instead, the
screen goes black and I cannot get it back; but I can still SSH into
the Ubuntu machine.

I guess it's another Gnome bug that will be abandoned in 6 months.

Jeff





bug#43802: Knot: Linker runs very slowly and crashes during build

2020-10-04 Thread Simon South
Building Knot 3.0.0 using "guix build knot" consistently appears to hang
for me when it gets to this point during the linking stage:

CCLD knsec3hash
  ar: `u' modifier ignored since `D' is the default (see `U')
CCLD kdig
CCLD khost

While it sits here the compiler is tying up 100% of a single CPU
core. On my ROCK64 with 4 GB of RAM, it eventually crashes with an
internal error:

  gcc: internal compiler error: Killed (program cc1)
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.
  make[3]: *** [Makefile:5381: libzscanner/la-scanner.lo] Error 1
  make[3]: Leaving directory '/tmp/guix-build-knot-3.0.0.drv-0/knot-3.0.0/src'

dmesg shows the compiler was killed for running out of memory:

  cc1 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, 
oom_score_adj=0
  CPU: 2 PID: 22340 Comm: cc1 Not tainted 5.8.11-gnu #1
  (...)
  
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=cc1,pid=22340,uid=999
  Out of memory: Killed process 22340 (cc1) total-vm:2573780kB, 
anon-rss:2540708kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:5044kB 
oom_score_adj:0
  oom_reaper: reaped process 22340 (cc1), now anon-rss:0kB, file-rss:0kB, 
shmem-rss:0kB

On my x86_64 machine the build eventually completes (that machine has
much more memory), but there is the same, weirdly long delay during
linking while the compiler runs.

I see no such delay however when I build the code "manually", using
"guix environment --pure knot" or even "guix environment --no-grafts
--container knot" as the manual suggests. The build then completes
quickly and successfully on either machine; the problem appears to
happen only when guix-daemon is involved.

Is there a known issue that can cause the linker to consume orders of
magnitude more resources when run by the Guix build process?

Apart from rebuilding gcc with debugging symbols (which seems to make
Guix want to rebuild every other package in the system as well) and
trying to understand what the compiler is doing, how might I go about
diagnosing this?

-- 
Simon South
si...@simonsouth.net





bug#43797: astromenace does not work

2020-10-04 Thread Luis Felipe via Bug reports for GNU Guix
Hi, I'm using guix b61e057. Just installed AstroMenace and it does not start. 
Trying to launch it from a terminal prints the following error:

AstroMenace 1.4.1
VFS version 190427
Compiled against SDL version 2.0.12
Linking against SDL version 2.0.12
vw_OpenVFS(): Can't find VFS file share/astromenace/gamedata.vfs
main(): gamedata.vfs file not found or corrupted.


---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/





bug#43798: [IceDove/Daily]: Global preferences does not open

2020-10-04 Thread carriemathison--- via Bug reports for GNU Guix
Hola,

I was setting up my email accounts in IceDove/Daily, but then the preferences 
menu did not open.

XML Parsing Error: undefined entity
Location: about:preferences
Line Number 780, Column 17:    

bug#30093: Installing python-ipython breaks Gnome on Fedora.

2020-10-04 Thread Maxim Cournoyer
Hello,

Fis Trivial  writes:

>>
>> so I
>> still think it might be best to deal with the problems on a case by case
>> basis.
>>
>
> I tried to find out what would Fedora set *GI_TYPELIB_PATH* if guix didn't.
> It turns out, nothing. If I comment out the line containing *GI_TYPELIB_PATH*
> in ~/.guix-profile/etc/profile, the variable won't be exist.
> Is there any suggestion for what I can do, to let guix have this variable, 
> while
> Fedora wouldn't see it?

I think a bold, but definitive approach at fixing this problem would be
to never use known environment variables in Guix search paths
specifications.

Instead, we should introduce custom Guix-specific flavors of the same
variables, e.g. GUIX_GI_TYPELIB_PATH.  That's more work (need to write
and maintain patches that add those Guix-specific variables along their
regular flavor), but that'd mean we can set all the variables we want
not worrying about breaking a foreign distribution.

What do you think?

Maxim





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

2020-10-04 Thread Maxim Cournoyer
Hello Giovanni,

Giovanni Biscuolo  writes:

> Hello,
>
> I resolved this issue: (obviously) It was my fault, please see below.
>
> zimoun  writes:
>
> [...]
>
>> Hum?  What is your ’~/.emacs.d/init.el’?  The issue seems the
>> loading order.  It could happen with lazy eval   Well, this ’alist’
>> is from ’org.el’, so it appears to me a bit weird.
>
> This sentence slowly guided me to the solution: I still had
> ~/.emacs.d/elpa and after I deleted that, the initial error reported in
> this bug disappeared, with another one I discovered later.
>
> AFAIU the error was triggered by the fact that my Emacs (on foreign
> distro) was still loading some old code from ~/.emacs.d/elpa, installed
> using use-package (mixed with Debian packages in some case) before I
> migrated to Guix Emacs.

As with other things Guix, mix and match of ad-hoc package management
(e.g., Emacs' native package management) and Guix can cause conflicts.
There is not always a clear solution to these problems.

I don't use Emacs' native package management facility, but if it clashes
with our own use of EMACSLOADPATH and site-start.el, it could be work
looking into (as a fresh bug).

I'll close this one for now.

Thanks!

Maxim





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

2020-10-04 Thread Giovanni Biscuolo
Hello,

I resolved this issue: (obviously) It was my fault, please see below.

zimoun  writes:

[...]

> Hum?  What is your ’~/.emacs.d/init.el’?  The issue seems the
> loading order.  It could happen with lazy eval   Well, this ’alist’
> is from ’org.el’, so it appears to me a bit weird.

This sentence slowly guided me to the solution: I still had
~/.emacs.d/elpa and after I deleted that, the initial error reported in
this bug disappeared, with another one I discovered later.

AFAIU the error was triggered by the fact that my Emacs (on foreign
distro) was still loading some old code from ~/.emacs.d/elpa, installed
using use-package (mixed with Debian packages in some case) before I
migrated to Guix Emacs.

All this confusion comes from the fact that before upgrading to 27.1 I
was using the same version (26.3) installed from Debian and then
migrated to Guix: this way, apart some strange warning I fully
understand only today, my Emacs Guix was running fine as before.  So
when I upgraded I misintepreted the situation as coming from some
problem of elfeed-org with 27.1.

Probably we should add a warning in our manual to avoid other users on
foreign distros will get in similar situations: I'd like to help but I'm
not sure I'll be able to find the right words.

Simon: about my strange use of

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

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

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

I think is a tengent here, so if you agree I'd discuss it on guix-users
(IMHO is OT on guix-devel).

Re. this bug, I think the situation is clear now and if you agree I'd
close it.

Thanks a lot! Emacs-Fu panda Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature


bug#43778: closed (Re: bug#43778: protonvpn-cli does not work after update)

2020-10-04 Thread znavko
Sorry, it still does not work! Before update, it sometimes could not find 
network, but stopping and starting wpa-supplicant and networking solved 
problem, restat was effective solution too.

But now protonvpn does not connect at all.


# protonvpn c
[!] There was an error connecting to the ProtonVPN API.
[!] Please make sure your connection is working properly!


# herd stop wpa-supplicant
# herd start wpa-supplcant
# herd stop networking
# herd start networking


# protonvpn c
[!] There was an error connecting to the ProtonVPN API.
[!] Please make sure your connection is working properly!


# restart
# protonvpn c
[!] There was an error connecting to the ProtonVPN API.
[!] Please make sure your connection is working properly!

# cat /etc/config.scm

;-*- mode: Scheme; -*-
;;this is znavko's cute config
;; for lightweight xfce4 desktop
;; without networkmanager but wpa_supplicant + dhcp-client instead

(use-modules (gnu) (gnu system nss)
 (gnu system locale) ;;for locale-definition
 (gnu services desktop)
 (srfi srfi-1) ;;for remove function
 (gnu services networking) ;;for remove ntp
 (gnu services avahi)  ;;for remove avahi
 (gnu services xorg)
 (gnu packages admin) ;;for wpa_supplicant
 )

(use-service-modules desktop)
(use-package-modules certs gnome)

(operating-system (host-name "antelope") (timezone "Europe/Moscow") (locale 
"en_US.utf8")
  (bootloader (bootloader-configuration (bootloader 
grub-efi-bootloader) (target "/boot/efi")))
  (file-systems (cons* 
(file-system (device "/dev/sda1") 
(mount-point "/boot/efi") (type "vfat"))
(file-system (device "/dev/sda2") 
(mount-point "/") (type "ext4")) 
(file-system (device "/dev/sdb1") 
(mount-point "/home/bob/plus") (type "ext4")) 
%base-file-systems))

  (swap-devices '("/dev/sda3"))

  (users (cons* (user-account (name "bob") (group "users")
  (supplementary-groups '("wheel" 
"netdev" "audio" "video"))
  (home-directory "/home/bob"))
(user-account (name "mom") (group "users")
  (supplementary-groups '("wheel" 
"netdev" "audio" "video"))
  (home-directory "/home/mom"))
%base-user-accounts))

  ;; This is where we specify system-wide packages.
  (packages (cons* nss-certs ;for HTTPS access
   gvfs  ;for user mounts
   wpa-supplicant
   %base-packages))

  (services (cons* 
 ;; xfce4 desktop, dhcp-client, slim
 (service xfce-desktop-service-type)
 (service dhcp-client-service-type)
 (service slim-service-type)

 (modify-services  
  ;; removing unnecessary services
  (remove (lambda (service)
(member (service-kind service)
(list ntp-service-type 
avahi-service-type 
  bluetooth-service 
network-manager-service-type
  gdm-service-type)))
  %desktop-services) ;end of remove lambda 
services

  ;; wpa_supplicant + dhcp-client (above) instead 
of networkmanager
  (wpa-supplicant-service-type config =>
   
(wpa-supplicant-configuration
(interface 
"wlp0s20f0u1")
(config-file 
"/etc/wpa_supplicant/wpa_supplicant.conf")))

  ) ;;end of modify-services
 )) ;;end of services

  ;; Allow resolution of '.local' host names with mDNS.
  (name-service-switch %mdns-host-lookup-nss)

  ;;blacklist ugly sound speaker, blacklist ideapad_laptop for 
prevent soft blocking wlan
  (kernel-arguments 
'("modprobe.blacklist=pcspkr,snd_pcsp,bluetooth"))

  ) ;;end of operating-system


What to do?


October 3, 2020 2:54 PM, help-debb...@gnu.org wrote:

> Your bug report
> 
> #43778: protonvpn-cli does not work after update
> 
> which was filed against the guix package, has been closed.
> 
> 

bug#43796: Privacy policy

2020-10-04 Thread Julien Lepiller
Looks nice, but:

The GDPR is not the only legislation that applies to us. For services hosted in 
France for instance, there is a legal obligation to keep logs for at least one 
year (not sure exactly who that applies to). There could be something similar 
in Germany where berlin is located.

I think some of the wording is vague. Does "can be used to identify" mean we 
will use the IP to identify the person (is it the reason we process this data?) 
Or is it something that we could technically do, but refuse to do?

Le 4 octobre 2020 11:34:19 GMT-04:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>IANAL but I think Guix needs a privacy policy for both its website and
>the Guix software in general.
>
>Attached is a patch for the website that also documents data use by
>Guix and Guix System.  Maybe I’ve overdone some parts and probably
>something important is missing.
>
>In particular, the GDPR requires IP addresses to be deleted from logs
>after a reasonable time.  I think but am not sure the current process
>for nginx is to delete only when the log files become too big.  A more
>suitable policy must be implemented and the users must be told about
>it, I think.  See .
>
>In general I think it is better to have an incomplete policy than to
>have none.
>
>Comments?
>
>Regards,
>Florian


bug#43796: Privacy policy

2020-10-04 Thread pelzflorian (Florian Pelz)
IANAL but I think Guix needs a privacy policy for both its website and
the Guix software in general.

Attached is a patch for the website that also documents data use by
Guix and Guix System.  Maybe I’ve overdone some parts and probably
something important is missing.

In particular, the GDPR requires IP addresses to be deleted from logs
after a reasonable time.  I think but am not sure the current process
for nginx is to delete only when the log files become too big.  A more
suitable policy must be implemented and the users must be told about
it, I think.  See .

In general I think it is better to have an incomplete policy than to
have none.

Comments?

Regards,
Florian
>From 080df2de1f1f99fce3d7dffcce57f723fd266e17 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sun, 4 Oct 2020 17:10:13 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] website: Add privacy policy.

* website/apps/base/templates/privacy.scm: New file with
web page on privacy.
* website/apps/base/templates/components.scm (navbar): Add it.
* website/po/POTFILES: Add it.
* website/apps/base/builder.scm (privacy-builder): New procedure.
(builder): Add it.
---
 website/apps/base/builder.scm  |  23 +
 website/apps/base/templates/components.scm |  18 +++-
 website/apps/base/templates/privacy.scm| 115 +
 website/po/POTFILES|   1 +
 4 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 website/apps/base/templates/privacy.scm

diff --git a/website/apps/base/builder.scm b/website/apps/base/builder.scm
index 4882dc5..2acf4dc 100644
--- a/website/apps/base/builder.scm
+++ b/website/apps/base/builder.scm
@@ -1,6 +1,22 @@
 ;;; GNU Guix web site
+;;; Copyright © 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site 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 Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see 
.
 
 (define-module (apps base builder)
   #:use-module (apps base data)
@@ -13,6 +29,7 @@
   #:use-module (apps base templates help)
   #:use-module (apps base templates home)
   #:use-module (apps base templates menu)
+  #:use-module (apps base templates privacy)
   #:use-module (apps base templates security)
   #:use-module (apps base types)
   #:use-module (apps blog utils)
@@ -54,6 +71,7 @@
 (contact-builder)
 (irc-builder)
 (contribute-builder)
+ (privacy-builder)
 (security-builder)
 (graphics-builder
 
@@ -115,6 +133,11 @@
   (make-page "menu/index.html" (menu-t) sxml->html))
 
 
+(define (privacy-builder)
+  "Return a Haunt page representing the Privacy page of the website."
+  (make-page "privacy/index.html" (privacy-t) sxml->html))
+
+
 (define (security-builder)
   "Return a Haunt page representing the Security page of the website."
   (make-page "security/index.html" (security-t) sxml->html))
diff --git a/website/apps/base/templates/components.scm 
b/website/apps/base/templates/components.scm
index 44d410e..1bf11e9 100644
--- a/website/apps/base/templates/components.scm
+++ b/website/apps/base/templates/components.scm
@@ -1,7 +1,22 @@
 ;;; GNU Guix web site
-;;; Copyright © 2019 Florian Pelz 
+;;; Copyright © 2019, 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site 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 Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see 
.
 
 ;;; This module defines HTML parts like header, breadcrumbs, footer,
 ;;; buttons, etc., which are used website-wide.

bug#43446: Qt Apps cant make use of qtwayland due to QT_PLUGIN_PATH '= wrapping

2020-10-04 Thread Ricardo Wurmus


Brendan Tildesley  writes:

> qt-build-system wraps variables such as QT_PLUGIN_PATH  with  '=
> instead of prefix, so when qtwayland is installed in a profile or
> included in the environment, the application fails to see it. Programs
> run with export QT_QPA_PLATFORM=wayland-egl will fail to launch.
>
> We could:
>
> 1. Use 'prefix so that the parent environment's variables are appended
>and users have to manually install qtwayland them selves.
> 2. Include qtwayland as an input to every qt package somehow. Can the
>build system do that? Considering that Wayland seems to be the
>future, I feel that Qt GUI applications should support it by
>default. I mean, wayland is in the closure of qtbase anyway.
> 3. Both? Why is '= used anyway?

I can’t say why the Qt build system does this, but in other cases we
know that 'prefix causes problems because the application may end up
loading incompatible binaries leading to a crash.  That’s especially the
case on foreign distros, e.g. when the Guix-installed graphical
application loads a plugin from the system’s XDG_* directories.

-- 
Ricardo





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

2020-10-04 Thread Maxim Cournoyer
Hello again!

Maxim Cournoyer  writes:

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

[...]

I managed to capture two instances of 'transferred= #f' from my pk
output in the attached logs.  Curiously, they didn't lead to the crash.
Attached is a pruned version of the strace log of a command like
'./pre-inst-env guix package -m my-manifest --max-jobs=20'.  Offloading
was in use.



log.pruned.lz
Description: strace log with two instances of 'transferred= #f'

Thanks,

Maxim


bug#43446: [PATCH] guix: qt-build-system: Fix search-path wrapping.

2020-10-04 Thread Brendan Tildesley


>From 9c1d5b76c70ebf9942f6bb891677d260fe16cb62 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Sun, 4 Oct 2020 21:58:08 +1100
Subject: [PATCH] guix: qt-build-system: Fix search-path wrapping.

* guix/build/qt-build-system.scm: (variables-for-wrapping): Modify
qt-build-system's wrap-all-programs phase to prefix all wrapped
search-path variables instead of overwriting them with =. This allows Qt
applications to find plugins available in the environment.
---
 guix/build/qt-build-system.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/build/qt-build-system.scm b/guix/build/qt-build-system.scm
index 005157b0a4..93f512b5d6 100644
--- a/guix/build/qt-build-system.scm
+++ b/guix/build/qt-build-system.scm
@@ -60,7 +60,7 @@
(lambda (var-to-wrap) (not (null? (last var-to-wrap
(map
 (lambda (var-spec)
-  `(,(first var-spec) = ,(collect-sub-dirs base-directories (last var-spec
+  `(,(first var-spec) prefix ,(collect-sub-dirs base-directories (last var-spec
 (list
  ;; these shall match the search-path-specification for Qt and KDE
  ;; libraries
-- 
2.28.0



bug#43791: cuirass: Search queries are too slow.

2020-10-04 Thread Mathieu Othacehe


Hello,

Search queries can take a long time to complete.

This query took 658.67 seconds to complete:

--8<---cut here---start->8---
SELECT * FROM ( SELECT Builds.rowid, Builds.timestamp, Builds.starttime, 
Builds.stoptime, Builds.log, Builds.status, Builds.job_name, Builds.system, 
Builds.nix_name, Specifications.name FROM Builds INNER JOIN Evaluations ON 
Builds.evaluation = Evaluations.id INNER JOIN Specifications ON 
Evaluations.specification = Specifications.name WHERE (Builds.nix_name LIKE 
'%hurd-barebones.qcow2%') AND (0 IS NULL OR (Builds.status = 0)) AND 
('guix-master' IS NULL OR (Specifications.name = 'guix-master')) AND 
('x86_64-linux' IS NULL OR (Builds.system = 'x86_64-linux')) AND (NULL IS NULL 
OR (NULL < Builds.rowid)) AND (NULL IS NULL OR (NULL > Builds.rowid)) ORDER BY 
CASE WHEN NULL IS NULL THEN Builds.rowid ELSE -Builds.rowid END DESC LIMIT 1) 
ORDER BY rowid DESC 658.67
--8<---cut here---end--->8---

and this one:

--8<---cut here---start->8---
SELECT MIN(Builds.rowid) FROM Builds INNER JOIN Evaluations ON 
Builds.evaluation = Evaluations.id INNER JOIN Specifications ON 
Evaluations.specification = Specifications.name WHERE (Builds.nix_name LIKE 
'%ganeti%') AND (NULL IS NULL OR (Builds.status = NULL)) AND (NULL IS NULL OR 
(Specifications.name = NULL)) AND (NULL IS NULL OR (Builds.system = NULL)) 
146.70
--8<---cut here---end--->8---

took 146.70 seconds.

The naive solution of adding an index on nix_name column does not work
as it is still ignored for some reason.

According to https://www.sqlite.org/optoverview.html, starting the LIKE
search pattern with '%' prevent the index use.

However, searching for 'hurd-barebones.qcow2%' also skips the index.

Thanks,

Mathieu





bug#43564: cuirass: Contention while registering new builds.

2020-10-04 Thread Mathieu Othacehe


Hello,

> I'm trying locally to spawn database workers dedicated to registration,
> that execute the evaluation queries in a single batch. Let's see if it
> helps.

I added 4 registration dedicated database workers and removed from
registration all accesses to the store. Now the evaluation returns
objects that contain all required information.

This seem to improve the situation quite a lot. For example, those three
registrations were done simultaneously in ~200 seconds:

--8<---cut here---start->8---
2020-10-04T12:46:19 registration took 205.429772 seconds
2020-10-04T12:46:19 evaluation 17099 registered 156 new derivations
2020-10-04T12:46:19 building 156 derivations in batches of 200
2020-10-04T12:46:19 building batch of 200 derivations (0/156)
2020-10-04T12:46:19 registration took 212.892482 seconds
2020-10-04T12:46:19 evaluation 17105 registered 164 new derivations
2020-10-04T12:46:19 building 164 derivations in batches of 200
2020-10-04T12:46:19 building batch of 200 derivations (0/164)
2020-10-04T12:46:19 registration took 205.009416 seconds
2020-10-04T12:46:19 evaluation 17102 registered 160 new derivations
2020-10-04T12:46:19 building 160 derivations in batches of 200
2020-10-04T12:46:19 building batch of 200 derivations (0/160)
--8<---cut here---end--->8---

Thanks,

Mathieu





bug#43446: EGL-Wayland

2020-10-04 Thread Raghav Gururajan
Hello Brendan!

I think you are missing 'egl-wayland'.
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8d82df1376f50bb1e32fa82e943b0f5c837658b6

Not sure if, Qt packages or Qt apps or both, requires rebuilding with 
egl-wayland as input.

Regards,
RG.





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

2020-10-04 Thread Andreas Enge
Hello Maxim,

On Sat, Oct 03, 2020 at 11:21:12PM -0400, Maxim Cournoyer wrote:
> 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 can be fixed by normalizing using the available number of cores instead
> of the number of parallel jobs.

this looks like a good change to me; actually I ended up encoding the number
of cores in the "speed" field instead, which is a dirty hack around the
core problem.

Andreas






bug#43788: core-updates groff "doc" output is not reproducible

2020-10-04 Thread Danny Milosavljevic
output ‘/gnu/store/9gc8dhi69qlmqfwg0971x49d6zf126i7-groff-1.22.4-doc’ of 
‘/gnu/store/h3kf5xyd0cvjyn13xkacsa1sskfsclnw-groff-1.22.4.drv’ differs from 
‘/gnu/store/9gc8dhi69qlmqfwg0971x49d6zf126i7-groff-1.22.4-doc-check’ from 
previous round
│ │ │ │ │ ├── slide-demo.pdf
--- /gnu/store/9gc8dhi69qlmqfwg0971x49d6zf126i7-groff-1.22.4-doc
+++ /gnu/store/9gc8dhi69qlmqfwg0971x49d6zf126i7-groff-1.22.4-doc-check
├── share
│ ├── doc
│ │ ├── groff
│ │ │ ├── examples
│ │ │ │ ├── mom
│ │ │ │ │ ├── slide-demo.pdf
│ │ │ │ │ │ ├── dumppdf -adt {}
│ │ │ │ │ │ │ @@ -7263,40 +7263,44 @@
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  BitsPerComponent
│ │ │ │ │ │ │  8
│ │ │ │ │ │ │  ColorSpace
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  Filter
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  RunLengthDecode
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  Height
│ │ │ │ │ │ │  96
│ │ │ │ │ │ │  Length
│ │ │ │ │ │ │  7826
│ │ │ │ │ │ │  Name
│ │ │ │ │ │ │  Im0
│ │ │ │ │ │ │  SMask
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  Subtype
│ │ │ │ │ │ │  Image
│ │ │ │ │ │ │  Type
│ │ │ │ │ │ │  XObject
│ │ │ │ │ │ │  Width
│ │ │ │ │ │ │  81
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  
[...]
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ -125
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │  
│ │ │ │ │ │ │ -DeviceRGB
│ │ │ │ │ │ │ +125
│ │ │ │ │ │ │  


│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  BitsPerComponent
│ │ │ │ │ │ │  8
│ │ │ │ │ │ │  ColorSpace
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  Filter
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  RunLengthDecode
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  Height
│ │ │ │ │ │ │  96
│ │ │ │ │ │ │  Length
│ │ │ │ │ │ │  7826
│ │ │ │ │ │ │ +Name
│ │ │ │ │ │ │ +Im0
│ │ │ │ │ │ │ +SMask
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +Subtype
│ │ │ │ │ │ │ +Image
│ │ │ │ │ │ │ +Type
│ │ │ │ │ │ │ +XObject
│ │ │ │ │ │ │  Width
│ │ │ │ │ │ │  81
│ │ │ │ │ │ │  
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +DeviceRGB
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +7826
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +PDF
│ │ │ │ │ │ │ +Text
│ │ │ │ │ │ │ +ImageC
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  
│ │ │ │ │ │ │ -
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  BitsPerComponent
│ │ │ │ │ │ │  8
│ │ │ │ │ │ │  ColorSpace
│ │ │ │ │ │ │ -DeviceGray
│ │ │ │ │ │ │ +
│ │ │ │ │ │ │  Filter
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  RunLengthDecode
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  Height
│ │ │ │ │ │ │  96
│ │ │ │ │ │ │  Length
│ │ │ │ │ │ │ -125
│ │ │ │ │ │ │ -Name
│ │ │ │ │ │ │ -Ma0
│ │ │ │ │ │ │ -Subtype
│ │ │ │ │ │ │ -Image
│ │ │ │ │ │ │ -Type
│ │ │ │ │ │ │ -XObject
│ │ │ │ │ │ │ +7826
│ │ │ │ │ │ │  Width
│ │ │ │ │ │ │  81
│ │ │ │ │ │ │  
│ │ │ │ │ │ │  


pgp2RMF6xuD4I.pgp
Description: OpenPGP digital signature