bug#36069: Menu-based installer unusable through noVNC

[Ludovic Courtès]

Hello Björn,

Björn Höfling  skribis:

> On Mon, 22 Jul 2019 12:25:12 +0200
> Ludovic Courtès  wrote:
>
>> Hello!
>> 
>> Björn Höfling  skribis:
>
>> > What I haven't done yet:
>> >
>> > 1. Use only "cirrus"
>> > 2. Use only "cirrusfb"
>> > 3. Try it out on my VPS.  
>> 
>> Please let us know when you have feedback on these so we can add just
>> the module that makes sense.
>
>
> I tried all three combinations and all work with qemu:
>
> 1. (initrd-modules (append (list "cirrus" "cirrusfb")
> 2. (initrd-modules (append (list "cirrusfb")
> 3. (initrd-modules (append (list "cirrus")
>
> I tried the version with "cirrus" on my VPS and it worked there too.

Cool, thanks for testing.

One easy thing we can do is to arrange so that ‘guix system vm{,-image}’
always include this module in the initrd.  I believe that would address
your use case, right?

Patch below.

Thanks,
Ludo’.

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index ac6e4ded92..73d9b2c0c1 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -850,6 +850,11 @@ environment with the store shared with the host.  MAPPINGS is a list of
  #:volatile-root? #t
  rest)))
 
+;; VPS sometimes expect the "cirrus" graphics driver to be available when
+;; the VM is accessed with noVNC; see .
+(initrd-modules (cons "cirrus"
+  (operating-system-initrd-modules os)))
+
 ;; Disable swap.
 (swap-devices '())
 

bug#36763: `guix search` does unexpected logical and

[Ludovic Courtès]

Hello!

zimoun  skribis:

> On Thu, 25 Jul 2019 at 19:35, Ludovic Courtès  wrote:
>
>>   (fold p (make-list …) metrics)
>>
>> looks a lot like:
>>
>>   (map (lambda (x) (fold p x metrics)) regexps)
>>
>> Well, something like that.  :-)
>
> Second try attached with your advice. :-)

Neat!

> +  (let ((scores (map
> + (lambda (regexp)
> +   (fold
> +(lambda (metric relevance)
> +  (match metric
> +((field . weight)
> + (match (field obj)
> +   (#f  relevance)
> +   ((? string? str)
> +(+ relevance (* (score str regexp) weight)))
> +   ((lst ...)
> +(+ relevance (* weight
> +(apply + (map
> +  (lambda (str)
> +(score str regexp))
> +  lst)
> +0 metrics))
> + regexps)))

For readability, I’d suggest giving a name to one of the two lambdas
above, so you can write, say:

  (map regexp-scores regexps)

where:

  (define (regexp-scores regexp)
(fold (lambda (metric relevance)
…)
  …))

Also, could you add a couple of tests (such as the “libb2” example for
“crypto” + “library” you mentioned earlier)?  You can add them to the
existing “package-relevance” test in tests/ui.scm.

Bonus points if you send the patch with ‘git format-patch’ and with a
commit log:

  https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

Thank you!

Ludo’.

bug#36924: Mesa/GDM/XFCE

[Andreas Enge]

Hello,

On Thu, Sep 12, 2019 at 01:40:09PM +0200, Ludovic Courtès wrote:
> Thanks for the report, Andreas!

and thanks for the time spent putting me on the good track!

> Andreas Enge  skribis:
> > xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293: 
> > intel_miptree_match_image: Zusicherung »image->TexObject->Target == 
> > mt->target« nicht erfüllt.
> That’s the likely root cause to me (in which case it may be unrelated to
> this , after all.)
> I found these bug reports:
>   https://bugs.freedesktop.org/show_bug.cgi?id=107117
>   https://bugzilla.redhat.com/show_bug.cgi?id=1678334
> 
> In both cases, Xfce and Mesa’s i965 drivers are involved, as is the case
> on your machine.  The 2nd bug report includes an xfwm4 patch, even.

The first one also contains a patch, but it has been integrated into later
mesa releases, in particular the one we are using.

> I wonder if Xfce before the recent updates (so before
> 8549e0ca6fd68a57253471436de49b88b2d47e64) works better.
> Andreas, if you feel like it, could you try:
>   guix pull --commit=97ce5964fb5d52cf2151fea685e28fa23a98b264
>   sudo guix system reconfigure …

Indeed, the problem disappears with this commit; I can log in and out
and in again with xfce working. So I am cc-ing the author of the commits
updating xfce, maybe they have an answer!

And I will try to look at the patch in the second report you reference
above.

Thanks!

Andreas

bug#37422: Setting keyboard layout with SLiM login manager doesn't work

[Jan Wielkiewicz]

Hi everyone!

I've tried using the default Polish keyboard layout with
SLiM and it doesn't seem to work - the system reconfigures properly
with no single error or warning, then after rebooting and logging in,
the layout is unavailable - only the US layout. The Polish layout is
aviable in tty's, but not in X sessions. I've run guix pull
several days ago.

This is my configuration:

(keyboard-layout (keyboard-layout "pl" "legacy"))

[...]

(service slim-service-type
 (slim-configuration
 (display ":0")
 (vt "vt7")))
(set-xorg-configuration (xorg-configuration
(keyboard-layout keyboard-layout))
slim-service-type)

PS tried sending this message to
https://issues.guix.gnu.org/issue/26234 
but it got lost. Is it an accident, or is sending messages to closed
issues impossible?

---
Jan Wielkiewicz

bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop

[Jan]

Hi.

Changing the login service from GDM to SLiM and then back to GDM makes
GDM to loop like this:
"New session c1 of user gdm."
"Removed session c1."
"New session c2 of user gdm."
"Removed session c2."
...

And it continues like this to relatively high numbers like c167. Didn't
check how far it could go, but that's not important anyway.
Reverting to the previous definition of the system by using 
"guix system switch-generation" or using grub menu entries doesn't help,
changing /etc/config.scm back to the default gdm configuration and
running 
"guix system reconfigure" doesn't help either.

There's also one strange thing that have happened before rebooting -
when logging off, SLiM was running in a loop too - I couldn't turn off
the computer using it, I had to switch to another tty and run "shutdown"
manualy.

But reverting to a configuration with SLiM works - I can use the system
with it, but can't with GDM anymore.

---
Jan Wielkiewicz

bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs

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

Martin,

Martin Becze 写道：

ping :P


Absolutely.

The diff you sent here[0] is incomplete (it relies on your 
previous patch and doesn't have a header); please always send 
git-formatted patches that apply directly to current master.  They 
are easier to merge and will be merged sooner.


Yeah I don't know. I just used prefix in the latest patch. Let 
me know

if the other method is preferred.


¯\_(ツ)_/¯

I've pushed this to master as 
ad6e168b3f29576d92b00725dedbb38cd5f05e46 with the following 
changes:


- Moved widowed ‘#:phases’ to the previous line (in well-formatted 
 Scheme, ‘(’ can never end a line and ‘)’ should never start 
 one), same for 'phase 'names
- then decided to move ’#:phases’ below ‘#:configure-flags’.  This 
 is subjective, but since *flags ‘affect’ phases (never the other 
 way 'round) it felt right  :-)

- dropped the unused ‘inputs’ phase argument
- added the missing ":" separator to the prefix wrapping — if it 
 does work without one (I didn't test), that's undocumented & 
 shouldn't be relied upon

- removed unnecessary trailing / in ‘schemas/’
- and wrote a commit message as mostly documented in ‘info 
 (standards)Change Logs’.


Thanks!

T G-R

[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36896#53


signature.asc
Description: PGP signature

bug#37424: guix pull fails with “no code for module (git object)”

[Ricardo Wurmus]

Hi Guix,

on my i686 machine I get this error:

--8<---cut here---start->8---
rekado@elephly ~$ ~/.config/guix/current/guix pull --no-build-hook
bin/   etc/   lib/   share/ 
rekado@elephly ~$ ~/.config/guix/current/bin/guix pull --no-build-hook
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   518fd3b
Computing Guix derivation for 'i686-linux'...  Backtrace:
In ice-9/boot-9.scm:
   222:17 19 (map1 (((guix git)) ((guix build-system r) #:select ?) ?))
  2800:17 18 (resolve-interface (guix git) #:select _ #:hide _ # _ # ?)
In ice-9/threads.scm:
390:8 17 (_ _)
In ice-9/boot-9.scm:
  2726:13 16 (_)
In ice-9/threads.scm:
390:8 15 (_ _)
In ice-9/boot-9.scm:
  2994:20 14 (_)
   2312:4 13 (save-module-excursion #)
  3014:26 12 (_)
In unknown file:
  11 (primitive-load-path "guix/git" #)
In ice-9/eval.scm:
   721:20 10 (primitive-eval (define-module (guix git) #:use-module ?))
In ice-9/psyntax.scm:
  1235:36  9 (expand-top-sequence ((define-module (guix git) # # ?)) ?)
  1182:24  8 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   285:10  7 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)
In ice-9/eval.scm:
   293:34  6 (_ #)
In ice-9/boot-9.scm:
   2874:4  5 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2887:24  4 (_)
   222:29  3 (map1 (((git)) ((git object)) ((guix i18n)) ((guix ?)) ?))
   222:17  2 (map1 (((git object)) ((guix i18n)) ((guix base32)) # ?))
   2803:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
In unknown file:
   0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)

ERROR: In procedure scm-error:
no code for module (git object)
-guix pull: error: You found a bug: the program 
'/gnu/store/f3xc9qp45hma3ia2z36z50vd5lxx4mk8-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"518fd3b6592203df73fec347d30016d4260ee127"; system: "i686-linux";
host version: "aa986c9cd6cf5874f5a6b326484a9073977cc4bd"; pull-version: 1).
Please report it by email to .
--8<---cut here---end--->8---

-- 
Ricardo

bug#37369: Getting network-manager-openconnect to work

[pelzflorian (Florian Pelz)]

On Tue, Sep 10, 2019 at 01:21:20PM +0200, pelzflorian (Florian Pelz) wrote:
> I suspect something like the attached patch would help (and expand the
> closure of network-manager to always include openconnect).
> 

Sorry, my old patch did not even build.  A friend lent me her
AnyConnect credentials so I can test.  I will test now and send a
working patch.

Regards,
Florian

bug#37424: guix pull fails with “no code for module (git object)”

[Efraim Flashner]

Fixed with 74e7465c9b3758c1509a3e0dbe575e2014e20f0a

[14:37:08]  so the problem is that this commit pulled in (git) 
indirectly
[14:37:59]  without tracking it down, i'd guess that (guix import cran) 
uses guile-git and (guix build-system r) doesn't
[14:39:35]  efraim: yes, exactly
[14:40:15]  so the solution is to do it the other way around: have the 
importer depend on the build system
[14:40:30]  or have an extra module used by both the importer and the 
build system

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#35519: librsvg broken on i686-linux

[Ludovic Courtès]

Hello Danny and all,

Ricardo Wurmus  skribis:

>> Hydra failed to build librsvg on i686-linux, because it depends on Rust
>> which is still broken on i686-linux in Guix.
>
> Danny opened a bug report with the mrustc upstream:
>
> https://github.com/thepowersgang/mrustc/issues/108
>
> The last message there tells us to try again with current HEAD on
> master.  If this fails I think it’s acceptable to use a binary for the
> very first Rust on i686; we would skip the use of mrustc on i686 then.
> Not great.

I don’t know if it relates but on current ‘core-updates’ Rust 1.19 fails
to build on i686:

--8<---cut here---start->8---
BUILDING curl_sys from curl-sys v0.3.11 with features []
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc 
> src/vendor/curl-sys/lib.rs --crate-name curl_sys --crate-type rlib 
> --crate-tag 0_3_11 -g --cfg debug_assertions -O -o 
> output/cargo-build/libcurl_sys-0_3_11.hir -L output/cargo-build -L 
> /gnu/store/44sdci2mizpvd70zyvbfs9ai0maw255z-curl-7.65.3/lib -l curl --extern 
> libz_sys=output/cargo-build/liblibz_sys-1_0_13.hir --extern 
> libc=output/cargo-build/liblibc-0_2_22.hir --extern 
> openssl_sys=output/cargo-build/libopenssl_sys-0_9_12.hir -L output -L 
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrust
BUILDING curl from curl v0.4.6 with features []
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc 
> src/vendor/curl/src/lib.rs --crate-name curl --crate-type rlib --crate-tag 
> 0_4_6 -g --cfg debug_assertions -O -o output/cargo-build/libcurl-0_4_6.hir -L 
> output/cargo-build --extern libc=output/cargo-build/liblibc-0_2_22.hir 
> --extern curl_sys=output/cargo-build/libcurl_sys-0_3_11.hir --extern 
> openssl_sys=output/cargo-build/libopenssl_sys-0_9_12.hir --extern 
> openssl_probe=output/cargo-build/libopenssl_probe-0_1_1.hir -L output -L 
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrust
BUILDING crates_io from crates-io v0.9.0 with features []
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc 
> src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib 
> --crate-tag 0_9_0 -g --cfg debug_assertions -O -o 
> output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern 
> curl=output/cargo-build/libcurl-0_4_6.hir --extern 
> error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern 
> serde=output/cargo-build/libserde-1_0_6.hir --extern 
> serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern 
> serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern 
> url=output/cargo-build/liburl-1_4_0.hir -L output -L 
> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrust
munmap_chunk(): invalid pointer
src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: 
Unexpected EOF while reading from child process
BUILD FAILED
command 
"/gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/tools/bin/minicargo" 
"src/tools/cargo" "--vendor-dir" "src/vendor" "--output-dir" 
"output/cargo-build" "-L" "output/" "-L" 
"/gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrust" "-j" "1" 
failed with status 1
builder for `/gnu/store/01mh2n7mif0k49ivj6y3fdq1ssj3d2lq-rust-1.19.0.drv' 
failed with exit code 1
--8<---cut here---end--->8---

(From
.)

Does that ring a bell?  Any ideas of a fix or workaround we could apply?

It’d be great if we could merge ‘core-updates’ soon.  This is
unfortunately not a regression compared to ‘master’, so I don’t think
this is a blocker.

Thoughts?

Ludo’.

bug#37425: Go 1.12.7 fails to build on i686-linux

[Ludovic Courtès]

Hello,

Go 1.12.7 has test failures on i686-linux, on ‘core-updates’:

--8<---cut here---start->8---
ok  path/filepath   0.041s
ok  plugin  0.038s
ok  reflect 0.328s
ok  regexp  0.241s
ok  regexp/syntax   1.026s
--- FAIL: TestGcSys (0.08s)
gc_test.go:33: expected "OK\n", but got "using too much memory: 17899520 
bytes\n"
FAIL
FAILruntime 37.967s
ok  runtime/debug   0.103s

[…]

ok  cmd/vendor/golang.org/x/sys/unix0.391s
ok  cmd/vet 8.529s
2019/09/16 12:33:32 Failed: exit status 1
command "sh" "all.bash" failed with status 1
builder for `/gnu/store/i2rs47n4000q9dh76alxvjgiry9pq6vj-go-1.12.7.drv' failed 
with exit code 1
--8<---cut here---end--->8---

(From
.)

I found these issues that suggest the test has been flaky:

  https://github.com/golang/go/issues/4155
  https://github.com/golang/go/issues/28574

Unless someone has a better idea, I’d suggest skipping this test on
i686.

Thoughts?

Ludo’.

bug#37426: guix-1.0.1-5.cc98b00 fails tests on i686-linux

[Mikhail Kryshen]

http://ci.guix.gnu.org/log/jkgrd9sv605jj3l819wp1jba99axfl0g-guix-1.0.1-5.cc98b00

This breaks system configuration on i686 with current Guix.

-- 
Mikhail


signature.asc
Description: PGP signature

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

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

Work around .

* gnu/packages/node.scm (node)[arguments]: Disable failing tests.
---

Jelle, Guix,

So here's the obvious non-solution, ignoring test failures being the lesser 
evil compared to 4 potential CVEs anywhere in a Web browser's closure.

It seems to ‘work’ in a short VM Chromium test.  As in, nothing broke.  Don't 
know how to test Node.  Thoughts?

Kind regards,

T G-R

 gnu/packages/node.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gnu/packages/node.scm b/gnu/packages/node.scm
index fc43fcb04c..f467be7665 100644
--- a/gnu/packages/node.scm
+++ b/gnu/packages/node.scm
@@ -91,6 +91,11 @@
  (add-before 'configure 'patch-files
(lambda* (#:key inputs #:allow-other-keys)
 
+ ;; FIXME: These tests fail with openssl@1.1.1d.
+ (for-each delete-file
+   '("test/parallel/test-crypto-binary-default.js"
+ "test/parallel/test-crypto-dh.js"))
+
  ;; Fix hardcoded /bin/sh references.
  (substitute* '("lib/child_process.js"
 "lib/internal/v8_prof_polyfill.js"
-- 
2.23.0

bug#36924: Mesa/GDM/XFCE

[L p R n d n]

Hello,

Andreas Enge  writes:

> Hello,
>
> On Thu, Sep 12, 2019 at 01:40:09PM +0200, Ludovic Courtès wrote:
>> Thanks for the report, Andreas!
>
> and thanks for the time spent putting me on the good track!
>
>> Andreas Enge  skribis:
>> > xfwm4: ../mesa-19.1.4/src/mesa/drivers/dri/i965/intel_mipmap_tree.c:1293:
>> intel_miptree_match_image: Zusicherung »image->TexObject->Target ==
>> mt->target« nicht erfüllt.
>> That’s the likely root cause to me (in which case it may be unrelated to
>> this , after all.)
>> I found these bug reports:
>>   https://bugs.freedesktop.org/show_bug.cgi?id=107117
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1678334
>> 
>> In both cases, Xfce and Mesa’s i965 drivers are involved, as is the case
>> on your machine.  The 2nd bug report includes an xfwm4 patch, even.
>
> The first one also contains a patch, but it has been integrated into later
> mesa releases, in particular the one we are using.
>
>> I wonder if Xfce before the recent updates (so before
>> 8549e0ca6fd68a57253471436de49b88b2d47e64) works better.
>> Andreas, if you feel like it, could you try:
>>   guix pull --commit=97ce5964fb5d52cf2151fea685e28fa23a98b264
>>   sudo guix system reconfigure …
>
> Indeed, the problem disappears with this commit; I can log in and out
> and in again with xfce working. So I am cc-ing the author of the commits
> updating xfce, maybe they have an answer!

It seems some bugs have been introduced in xfwm4 between 4.12 and 4.14.
(All issues previously linked are for >=4.13 wich was the dev version of
4.14).
I found https://forum.xfce.org/viewtopic.php?id=13233 which seems
interesting. Please let us know if it changes anything.

I don't know what would be the correct way to deal with the problem in
guix though.

> And I will try to look at the patch in the second report you reference
> above.
>
> Thanks!
>
> Andreas

Have a nice day,

L  p r n  d n

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Ludovic Courtès]

Hi Jan,

Jan  skribis:

> guix/build/download.scm:313:6: In procedure tls-wrap:
> X.509 certificate of 'api.github.com' could not be verified:
>   signer-not-found
>   invalid

It looks like X.509 certificates used to authenticate web sites over
HTTPS could not be found.

Did you set environment variables and all as described at
?

HTH,
Ludo’.

bug#37384: Daemon does not honor “useSubstitutes” on armhf

[Ludovic Courtès]

Hello Timothy,

Timothy Sample  skribis:

> The following patch fixes the problem:
>
> From 3c3eafac82e0a6e8a37363d6eb46f128e585705a Mon Sep 17 00:00:00 2001
> From: Timothy Sample 
> Date: Thu, 12 Sep 2019 00:50:54 -0400
> Subject: [PATCH] daemon: Include 'config.h' in 'nix-daemon.cc'.
>
> * nix/nix-daemon/nix-daemon.cc: Include 'config.h'.
> ---
>  nix/nix-daemon/nix-daemon.cc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/nix/nix-daemon/nix-daemon.cc b/nix/nix-daemon/nix-daemon.cc
> index ffac6cde34..1163a249d1 100644
> --- a/nix/nix-daemon/nix-daemon.cc
> +++ b/nix/nix-daemon/nix-daemon.cc
> @@ -1,3 +1,4 @@
> +#include "config.h"
>  #include "shared.hh"
>  #include "local-store.hh"
>  #include "util.hh"

LGTM.

Thanks for the debugging effort that led to this fix!

Ludo’.

bug#37369: Getting network-manager-openconnect to work

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Wed, Sep 11, 2019 at 10:46:56PM +0200, Ludovic Courtès wrote:
>> Something I don’t get: why does NM itself know about openconnect?
>> 
>> There’s a network-manager-openconnect plugin, so I would expect
>> everything openconnect to happen there.  Do you know why it’s not that
>> way?
>> 
>> Thanks,
>> Ludo’.
>
> I don’t know.  The patch addresses (if it works) a function called
> nm_vpn_openconnect_authenticate_helper within the code for
> NetworkManager clients like nmtui, probably also nm-connection-editor,
> that calls openconnect --authenticate.

So I guess we first need someone to tell us whether the patch “works”,
as you wrote, right?  :-)

Ludo’.

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

[Ludovic Courtès]

Hello,

Tobias Geerinckx-Rice via Bug reports for GNU Guix 
skribis:

> Work around .
>
> * gnu/packages/node.scm (node)[arguments]: Disable failing tests.

[...]

> + ;; FIXME: These tests fail with openssl@1.1.1d.
> + (for-each delete-file
> +   '("test/parallel/test-crypto-binary-default.js"
> + "test/parallel/test-crypto-dh.js"))

It may be the best short-term solution.

Could we take a look at what these failures are about to see how bad
that might be?

Thanks,
Ludo’.

bug#35519: librsvg broken on i686-linux

[Danny Milosavljevic]

Hi Ludo,

On Mon, 16 Sep 2019 14:24:48 +0200
Ludovic Courtès  wrote:

> Does that ring a bell?

Yes, I've brought that up upstream and upstream is more than willing to work
on this and debug this problem if there is a system to debug it on.

However, as far as I understand we decided not to give thepowersgang (authors
of mrustc) a login to a Guix machine--therefore, the situation will not improve.

The problem is NOT reproducible in Debian with the same gcc version.

Maybe I'll get my home internet set up next month and put a Guix machine on it,
but right now I only have mobile internet (with very slow upload and behind 
NAT).
As it is now, I cannot reasonably give someone a Guix machine already setup
to debug this problem.

The problem is 100% reproducible and I estimate would be easy to fix for the
authors--and maybe would fix the similar armhf problems as well.

So if someone could put a Guix machine on the internet and give thepowersgang
access, that would be great.  I can't right now.

If that happens, I can instruct thepowersgang how to enter an environment
where this problem can be reproduced and fixed.

Even at the last FOSDEM, Chris Marusich and I saw this problem and fixed
part of it--by now we got upstream attention.  (After all this inertia maybe
we lost upstream attention again--we'll see)

>  Any ideas of a fix or workaround we could apply?

No, but thepowersgang might find it very quickly.  They guess it might be
some C undefined behavior being used by the mrustc->C translator, or a problem
with the struct layout (although I've checked the latter and it should be
fine).


pgpVNaQlXw28h.pgp
Description: OpenPGP digital signature

bug#37369: Getting network-manager-openconnect to work

[pelzflorian (Florian Pelz)]

On Mon, Sep 16, 2019 at 05:57:51PM +0200, Ludovic Courtès wrote:
> So I guess we first need someone to tell us whether the patch “works”,
> as you wrote, right?  :-)
> 
> Ludo’.

Currently I have built the attached patch, but NetworkManager
segfaults when connecting, and I try to debug why.

Regards,
Florian
>From 1efadd4619f397429d5fae024b46cd8100870c42 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Mon, 16 Sep 2019 15:27:01 +0200
Subject: [PATCH] gnu: network-manager: Enable openconnect helper.

* gnu/packages/gnome.scm (network-manager): Add openconnect input.
Patch source to use it instead of searching /usr/bin.
---
 gnu/packages/gnome.scm | 8 
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 5dc18b3bb5..a8ba00965d 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -5374,6 +5374,13 @@ users.")
(("src/devices/tests/test-lldp") " ")
(("src/tests/test-route-manager-linux") " "))
  #t))
+ (add-after 'unpack 'patch-source
+   (lambda* (#:key inputs #:allow-other-keys)
+ (let ((openconnect (assoc-ref inputs "openconnect")))
+   (substitute* "clients/common/nm-vpn-helpers.c"
+ (("\\\"/usr/sbin/openconnect\\\"")
+  (string-append "\"" openconnect "/sbin/openconnect\"")))
+   #t)))
  (add-after 'unpack 'delete-failing-tests
(lambda _
  ;; FIXME: These four tests fail for unknown reasons.
@@ -5436,6 +5443,7 @@ users.")
("libsoup" ,libsoup)
("modem-manager" ,modem-manager)
("newt" ,newt)   ;for the 'nmtui' console interface
+   ("openconnect" ,openconnect)
("polkit" ,polkit)
("ppp" ,ppp)
("readline" ,readline)
-- 
2.23.0

bug#37428: Keyboard layout setting fails when no keyboard is attached

[dario]

I have Guix system installed on a Laptop/Tablet hybrid that allows
detaching the keyboard. In my system configuration, I set the keyboard
layout to the German QWERTZ using

(operating-system
...
 (keyboard-layout
  (keyboard-layout "de" "nodeadkeys"))
 (bootloader
  (bootloader-configuration
   (bootloader grub-efi-bootloader)
   (target "/boot/efi")
   (keyboard-layout keyboard-layout)))
...
 (services
  (append
   (list ...
 (set-xorg-configuration
  (xorg-configuration
   (keyboard-layout keyboard-layout)
   ...
   %desktop-services))

When the keyboard is attached, the keyboard layout is set correctly in
the TTY and in the graphical session. However, without the keyboard
attached, even when an external USB-keyboard is attached, the keyboard
layout is only set correctly in the TTY, but in the graphical session,
the default QWERTY layout is set.

This issue is obviously very easy to work around by either attaching the
keyboard or using setxkbmap, but the behaviour seems strange enough to
warrant reporting.

Best regards,
Dario

bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page

[Jan]

Dnia 2019-09-16, o godz. 18:01:04
Ludovic Courtès  napisał(a):

> Hi Jan,
> 
> Jan  skribis:
> 
> > guix/build/download.scm:313:6: In procedure tls-wrap:
> > X.509 certificate of 'api.github.com' could not be verified:
> >   signer-not-found
> >   invalid
> 
> It looks like X.509 certificates used to authenticate web sites over
> HTTPS could not be found.
> 
> Did you set environment variables and all as described at
> ?
> 
> HTH,
> Ludo’.

I have nss-certs installed as a global package in my config.scm and
refreshing only doesn't work in the environment created by "guix
environmnet guix --pure" - it works without an environment. Tried
using "--ad-hoc nss-certs", but it didn't work. The manual says I have
to add certs manually if I'm an unprivileged user or running Guix on a
foreign distro, but I'm running Guix natively on my machine. Do I have
to define variables like this anyway?

---
Jan Wielkiewicz

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

[Jelle Licht]

Ludovic Courtès  writes:

> Hello,
>
> Tobias Geerinckx-Rice via Bug reports for GNU Guix 
> skribis:
>
>> Work around .
>>
>> * gnu/packages/node.scm (node)[arguments]: Disable failing tests.
>
> [...]
>
>> + ;; FIXME: These tests fail with openssl@1.1.1d.
>> + (for-each delete-file
>> +   '("test/parallel/test-crypto-binary-default.js"
>> + "test/parallel/test-crypto-dh.js"))
>
> It may be the best short-term solution.
Agreed, if ungoogled-chromium works with this that would probably be the
best option.
>
> Could we take a look at what these failures are about to see how bad
> that might be?

Interestingly enough, https://github.com/nodejs/node/issues/3881 notes
issues with exactly these two tests. Perhaps there is a regressions in
our case?

bug#35519: librsvg broken on i686-linux

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> Yes, I've brought that up upstream and upstream is more than willing to work
> on this and debug this problem if there is a system to debug it on.
>
> However, as far as I understand we decided not to give thepowersgang (authors
> of mrustc) a login to a Guix machine--therefore, the situation will not 
> improve.

What about giving them “guix pack mrustc”, or a guix-install.sh + pull
command sequence, or a VM image?

The instructions would be:

  1. Download and run .  It will
 perform the steps described at
 .

  2. Write this to a file:

   (list (channel
   (name 'guix)
   (url "https://git.savannah.gnu.org/git/guix.git";)
   (commit
 "0b2ea78173f05c417a9002e52e2b36b139074124")))

  3. Run ‘guix pull -C that-file.scm -p ~/core-updates’.

  4. Run ‘~/core-updates/bin/guix build rust -s i686-linux -K’.
 Investigate as per
 .

Perhaps you could propose them to do that, and if that’s too much to
ask, we can meet halfway somehow.

Of course we can also provide guidance on #guix on IRC.

WDYT?

> No, but thepowersgang might find it very quickly.  They guess it might be
> some C undefined behavior being used by the mrustc->C translator, or a problem
> with the struct layout (although I've checked the latter and it should be
> fine).

Would Valgrind or ASan be able to flag the potential issue?

Thanks,
Ludo’.

bug#37426: guix-1.0.1-5.cc98b00 fails tests on i686-linux

[Ludovic Courtès]

Hi Mikhail,

Mikhail Kryshen  skribis:

> http://ci.guix.gnu.org/log/jkgrd9sv605jj3l819wp1jba99axfl0g-guix-1.0.1-5.cc98b00
>
> This breaks system configuration on i686 with current Guix.

Thanks for the heads-up.

The test failures are:

--8<---cut here---start->8---
test-name: substitutable-path-info when substitutes are turned off
location: /tmp/guix-build-guix-1.0.1-5.cc98b00.drv-0/source/tests/store.scm:310
source:
+ (test-equal
+   "substitutable-path-info when substitutes are turned off"
+   '()
+   (with-store
+ s
+ (set-build-options s #:use-substitutes? #f)
+ (let* ((b (add-to-store
+ s
+ "bash"
+ #t
+ "sha256"
+ (search-bootstrap-binary
+   "bash"
+   (%current-system
+(d (derivation
+ s
+ "the-thing"
+ b
+ '("--version")
+ #:inputs
+ `((,b
+(o (derivation->output-path d)))
+   (with-derivation-narinfo
+ d
+ (substitutable-path-info s (list o))
expected-value: ()
actual-value: (#< path: 
"/tmp/guix-tests/store/k8yr3vwh9lry8r5x53p1fcpk1d78v4y3-the-thing" deriver: 
"/tmp/guix-tests/store/1kklp6bxdl34k0qxg4q4wxab7viyl00n-the-thing.drv" refs: () 
dl-size: 0 nar-size: 1234>)
result: FAIL

test-name: substitutable-paths when substitutes are turned off
location: /tmp/guix-build-guix-1.0.1-5.cc98b00.drv-0/source/tests/store.scm:323
source:
+ (test-equal
+   "substitutable-paths when substitutes are turned off"
+   '()
+   (with-store
+ s
+ (set-build-options s #:use-substitutes? #f)
+ (let* ((b (add-to-store
+ s
+ "bash"
+ #t
+ "sha256"
+ (search-bootstrap-binary
+   "bash"
+   (%current-system
+(d (derivation
+ s
+ "the-thing"
+ b
+ '("--version")
+ #:inputs
+ `((,b
+warning: in 'the-thing': deprecated 'derivation' calling 
convention used
warning: in 'the-thing': deprecated 'derivation' calling convention used
substitute: warning: authentication and authorization of substitutes disabled!
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
warning: in 'the-thing': deprecated 'derivation' calling convention used
warning: in 'the-thing': deprecated 'derivation' calling convention used
warning: in 'the-thing': deprecated 'derivation' calling convention used
warning: in 'the-thing': deprecated 'derivation' calling convention used
substitute: warning: authentication and authorization of substitutes disabled!
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
@ build-started 
/tmp/guix-tests/store/fh0yssxmiv089bpylfl4v5z4qqq89p56-the-thing.drv - 
i686-linux 
/tmp/guix-tests/var/log/guix/drvs/fh//0yssxmiv089bpylfl4v5z4qqq89p56-the-thing.drv.bz2
 31208
@ build-succeeded 
/tmp/guix-tests/store/fh0yssxmiv089bpylfl4v5z4qqq89p56-the-thing.drv -
(o (derivation->output-path d)))
+   (with-derivation-narinfo
+ d
+ (substitutable-paths s (list o))
expected-value: ()
actual-value: 
("/tmp/guix-tests/store/k8yr3vwh9lry8r5x53p1fcpk1d78v4y3-the-thing")
result: FAIL
--8<---cut here---end--->8---

This may well be due to .

When Timothy pushes the fix, I’ll update the ‘guix’ package and check
whether it builds on i686-linux.

Ludo’.

bug#37421: [PATCH] gnu: node: Disable tests that fail with openssl@1.1.1d.

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

Ludovic Courtès 写道：
Could we take a look at what these failures are about to see how 
bad

that might be?


Jelle Licht 写道：
Interestingly enough, https://github.com/nodejs/node/issues/3881 
notes
issues with exactly these two tests. Perhaps there is a 
regressions in

our case?


Thanks, and indeed!  That is _quite_ the coincidence…

Unfortunately, I don't see any mention of a time-out in my logs & 
the truncation of the backtrace


 at Object. (…/test/parallel/test-crypto-dh.js:124:8)
 at Module._compile (internal/modules/cjs/loader.js:701:30)
 at Object.Module._extensions..js 
 (internal/modules/cjs/loader.js:712:10)

 at Module.load (internal/modules/cjs/loader.js:600:32)
 at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
 at Function.Module._load (internal/modules/cjs/loader.js:531:3)
 at Function.Module.runMain 
 (internal/modules/cjs/loader.js:754:12)

 at startup (internal/bootstrap/node.js:283:19)
 at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)
 ...

happens at run time: grepping the output of ‘--keep’ doesn't 
reveal a more complete one :-(


I don't know how to hack the tests to spit out more.  Someone who 
knows node/js more than I do needs to step in and save us.  Is 
that you, Jelle? :-)


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#37425: Go 1.12.7 fails to build on i686-linux

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> I found these issues that suggest the test has been flaky:
>
>   https://github.com/golang/go/issues/4155
>   https://github.com/golang/go/issues/28574
>
> Unless someone has a better idea, I’d suggest skipping this test on
> i686.

Commit b938892551816aedd01fd32b7eb1d5e061afce32 patches the test to skip
it on all platforms after I had experienced it on x86_64 as well (the
test was in fact already skipped on some platforms.)

According to , the underlying
issue has been fixed just 11 days ago.

Ludo’.

bug#37433: python-scikit-learn has two failing tests

[Ricardo Wurmus]

The python-scikit-learn package fails to build due to two failing tests:

--8<---cut here---start->8---
=== FAILURES ===
___ test_scale_and_stability ___

def test_scale_and_stability():
# We test scale=True parameter
# This allows to check numerical stability over platforms as well

d = load_linnerud()
X1 = d.data
Y1 = d.target
# causes X[:, -1].std() to be zero
X1[:, -1] = 1.0

# From bug #2821
# Test with X2, T2 s.t. clf.x_score[:, 1] == 0, clf.y_score[:, 1] == 0
# This test robustness of algorithm when dealing with value close to 0
X2 = np.array([[0., 0., 1.],
   [1., 0., 0.],
   [2., 2., 2.],
   [3., 5., 4.]])
Y2 = np.array([[0.1, -0.2],
   [0.9, 1.1],
   [6.2, 5.9],
   [11.9, 12.3]])

for (X, Y) in [(X1, Y1), (X2, Y2)]:
X_std = X.std(axis=0, ddof=1)
X_std[X_std == 0] = 1
Y_std = Y.std(axis=0, ddof=1)
Y_std[Y_std == 0] = 1

X_s = (X - X.mean(axis=0)) / X_std
Y_s = (Y - Y.mean(axis=0)) / Y_std

for clf in [CCA(), pls_.PLSCanonical(), pls_.PLSRegression(),
pls_.PLSSVD()]:
clf.set_params(scale=True)
X_score, Y_score = clf.fit_transform(X, Y)
clf.set_params(scale=False)
X_s_score, Y_s_score = clf.fit_transform(X_s, Y_s)
assert_array_almost_equal(X_s_score, X_score)
assert_array_almost_equal(Y_s_score, Y_score)
# Scaling should be idempotent
clf.set_params(scale=True)
X_score, Y_score = clf.fit_transform(X_s, Y_s)
>   assert_array_almost_equal(X_s_score, X_score)
E   AssertionError: 
E   Arrays are not almost equal to 6 decimals
E   
E   (mismatch 50.0%)
Ex: array([-1.337317, -0.041705, -1.108472,  0.098154,  
0.407632, -0.103084,
E   2.038158,  0.046634])
Ey: array([-1.337317, -0.041776, -1.108472,  0.0982  ,  
0.407632, -0.103027,
E   2.038158,  0.046602])

sklearn/cross_decomposition/tests/test_pls.py:365: AssertionError
 test_unsorted_indices _

def test_unsorted_indices():
# test that the result with sorted and unsorted indices in csr is the 
same
# we use a subset of digits as iris, blobs or make_classification didn't
# show the problem
digits = load_digits()
X, y = digits.data[:50], digits.target[:50]
X_test = sparse.csr_matrix(digits.data[50:100])

X_sparse = sparse.csr_matrix(X)
coef_dense = svm.SVC(kernel='linear', probability=True,
 random_state=0).fit(X, y).coef_
sparse_svc = svm.SVC(kernel='linear', probability=True,
 random_state=0).fit(X_sparse, y)
coef_sorted = sparse_svc.coef_
# make sure dense and sparse SVM give the same result
assert_array_almost_equal(coef_dense, coef_sorted.toarray())

X_sparse_unsorted = X_sparse[np.arange(X.shape[0])]
X_test_unsorted = X_test[np.arange(X_test.shape[0])]

# make sure we scramble the indices
>   assert_false(X_sparse_unsorted.has_sorted_indices)

sklearn/svm/tests/test_sparse.py:118: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = , expr = 1
msg = '1 is not false'

def assertFalse(self, expr, msg=None):
"""Check that the expression is false."""
if expr:
msg = self._formatMessage(msg, "%s is not false" % safe_repr(expr))
>   raise self.failureException(msg)
E   AssertionError: 1 is not false

/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/lib/python3.7/unittest/case.py:686:
 AssertionError
[…]
2 failed, 10415 passed, 30 skipped, 1 deselected, 1 xfailed, 1026 warnings in 
895.50 seconds 
--8<---cut here---end--->8---

-- 
Ricardo

bug#37384: Daemon does not honor “useSubstitutes” on armhf

[Timothy Sample]

Hi,

Ludovic Courtès  writes:

> LGTM.

Great!  I just pushed it.  Thanks for the review.


-- Tim

bug#37423: Changing the login service from GDM to SLiM and then back to GDM causes a really bad loop

[Timothy Sample]

Hi Jan,

Jan  writes:

> Hi.
>
> Changing the login service from GDM to SLiM and then back to GDM makes
> GDM to loop like this:
> "New session c1 of user gdm."
> "Removed session c1."
> "New session c2 of user gdm."
> "Removed session c2."
> ...
>
> And it continues like this to relatively high numbers like c167. Didn't
> check how far it could go, but that's not important anyway.
> Reverting to the previous definition of the system by using 
> "guix system switch-generation" or using grub menu entries doesn't help,
> changing /etc/config.scm back to the default gdm configuration and
> running 
> "guix system reconfigure" doesn't help either.

Could this be the same issue as ?  In short,
Guix doesn’t guarantee that the “gdm” user will have the same UID if it
gets deleted and recreated (which happens when you remove the GDM
service and add it again).  You can fix this by ensuring the owner of
the files under “/var/lib/gdm” is the current “gdm” user.


-- Tim