bug#40565: make authenticate fails: commit 77704cb13e5bebf412297dab764a00849a3cfdc0: key A0C5E3522EF8EF5C64CDB7F0FD73CAC719D32566 is missing

[Eric Bavier]

On 16.04.2020 11:24, Tobias Geerinckx-Rice wrote:

Ela, Eric,

elaexuotee--- via Bug reports for GNU Guix 写道：

It looks like the referenced key doesn't exist in the keyservers:

$ gpg --recv-keys A0C5E3522EF8EF5C64CDB7F0FD73CAC719D325
gpg: keyserver receive failed: No data


Eric, I didn't find any previous discussion about this.  Could you
help us out by publishing this ‘secret’ key somewhere?  :-)

Your key at Savannah[0] is a different one and there's no
A0C5E3522EF8EF5C64CDB7F0FD73CAC719D325 on keys.openpgp.org, SKS,
keys.gnupg.net, or pgp.mit.edu.


A0C5E352... is a signing subkey.  The key on Savannah, 34FF38BC..., is 
the primary key.  The signature checks out with my primary key.


--
`~Eric

bug#40544: Pulseaudio is not looking for user configuration

[pkill9]

> That's a known [0] (but AFAIK undocumented) side effect of the
> PulseAudio service, which was added to %desktop-services in January
> [1]. If you want PulseAudio to read your user configuration files
> you'll have to remove that service from your system services or unset
> PULSE_CONFIG and PULSE_CLIENT_CONFIG in ~/.profile [2].

Thank you very much for pointing that out, I've solved all my problems
with Pulseaudio now. Glad it was just a trivial misconfiguration and
not a bug.

bug#40675: Chromium doesn't start pulseaudio if pulseaudio isn't running

[pkill9]

It instead seems to use Alsa directly, because when I then run
Pulseaudio, it just creates a 'dummy output'. This is annoying with the
default Pulseaudio behaviour of exiting after 20 seconds of idling.

bug#40669: [PATCH] gnu: Add exfatprogs.

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

* gnu/packages/file-systems.scm (exfatprogs): New public variable.
---

Leo,

Here 't is.  Boring, but avoids you some duplicate busywork.

> New "official" package

I'm not…  I'm really not biting, you know.  Nope.  Nein!

Enjoy,

T G-R

 gnu/packages/file-systems.scm | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/gnu/packages/file-systems.scm b/gnu/packages/file-systems.scm
index b5ca37d43e..1e4464e22f 100644
--- a/gnu/packages/file-systems.scm
+++ b/gnu/packages/file-systems.scm
@@ -113,6 +113,37 @@ caching system, and lets you assign different roles to 
each device based on its
 performance and other characteristics.")
   (license license:gpl2+
 
+(define-public exfatprogs
+  (package
+(name "exfatprogs")
+(version "1.0.1")
+(source
+ (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/exfatprogs/exfatprogs;)
+ (commit version)))
+   (file-name (git-file-name name version))
+   (sha256
+(base32 "0ndc0vsf5m7n79fjxhkg1qw3gy9zdpx2jrdgl0dqjr6cm06jd0b5"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+   (list "--disable-static")))
+(native-inputs
+ `(("autoconf" ,autoconf)
+   ("automake" ,automake)
+   ("libtool" ,libtool)
+   ("pkg-config" ,pkg-config)))
+(home-page "https://github.com/exfatprogs/exfatprogs;)
+(synopsis "Tools to create, check, and repair exFAT file systems")
+(description
+ "These are command-line user space tools for the @acronym{exFAT,
+Extensible File Allocation Table} file systems.  Included are
+@command{mkfs.exfat} to create (format) new exFAT file systems, and
+@command{fsck.exfat} to check their consistency and repair them.")
+(license license:gpl2+)))
+
 (define-public httpfs2
   (package
 (name "httpfs2")
-- 
2.25.2

bug#15284: wish: make the (name) field optional

[Ricardo Wurmus]

I agree with Ludo and Andreas that we better shouldn’t make the
name field optional.

That said, I just pushed a series of patches that happens to address
this wishlist item in a very roundabout way.  It is now possible to
build packages from JSON files like this:

--8<---cut here---start->8---
[
  {
"name": "myhello",
"version": "2.10",
"source": "mirror://gnu/hello/hello-2.10.tar.gz",
"build-system": "gnu",
"arguments": {
  "tests?": false
}
"home-page": "https://www.gnu.org/software/hello/;,
"synopsis": "Hello, GNU world: An example GNU package",
"description": "GNU Hello prints a greeting.",
"license": "GPL-3.0+",
"native-inputs": ["gettext"]
  },
  {
"name": "greeter",
"version": "1.0",
"source": "https://example.com/greeter-1.0.tar.gz;,
"build-system": "gnu",
"arguments": {
  "test-target": "foo",
  "parallel-build?": false,
},
"home-page": "https://example.com/;,
"synopsis": "Greeter using GNU Hello",
"description": "This is a wrapper around GNU Hello.",
"license": "GPL-3.0+",
"inputs": ["myhello", "hello"]
  }
]
--8<---cut here---end--->8---

As you can see, there is no variable assignment, because this is JSON.
The “name” field is the only identifier, and its value can be used as an
input in other packages (see the reference to “myhello” in the “greeter”
package definition).

It’s really only tangentially related to what this issue is about, but
it’s as close as we can get to duplication-free syntax — even though
it’s JSON and not Scheme.  Look, there are also no labels for inputs!
Because there are no custom phases either…

--
Ricardo

bug#40672: shepherd fails to terminate processes after PID file timeout expiration

[Ludovic Courtès]

As discussed during , in
Shepherd 0.7.0, if a process created with ‘fork+exec-command’ & co. with
#:pid-file fails to start before #:pid-file-timeout has expired,
shepherd marks it as failed but the process potentially just keeps
running.

Ludo’.

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Guillaume Le Vaillant  skribis:

> Guillaume Le Vaillant  skribis:
>
>> Ludovic Courtès  skribis:
>>
>>> Hi Guillaume,
>>>
>>> Guillaume Le Vaillant  skribis:
>>>
 I don't know if it's related, but recently I had GDM crashes at boot
 after reconfiguring a system using gdm-service-type (generation n) to
 make it use slim-service-type instead (generation n+1), and then
 reconfiguring to gdm-service-type again (generation n+2).

 The problem was that the 'gdm' user id number (or group id number) was
 not the same in generations n and n+2, which prevented GDM from
 accessing the '/var/lib/gdm' directory.
>>>
>>> When did that happen?
>>>
>>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>>> ensures that /var/lib/gdm has proper ownership.
>>>
>>> Thanks,
>>> Ludo’.
>>
>> I think it was around 2 weeks ago.
>
> Concerning the service extensions of gdm-service-type, is it guaranteed
> that %gdm-activation will be run after %gdm-accounts and not before?
> If it's not the case it could explain the problem...

‘%gdm-activation’ would throw an exception if the “gdm” user didn’t
exist, so apparently it’s run before the activation snippet of
‘account-service-type’ (the ordering guarantee is not explicit.)

Hmm I wonder what I’m missing then.  Would you like to try again?

Now, I think we should generalize this chown thing and apply it to all
the user accounts.  ‘user-homes’ would chown recursively if needed or
use the newfangled shiftfs, like systemd-homed does¹.

Thoughts?

Ludo’.

¹ https://systemd.io/HOME_DIRECTORY/

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Christopher Baines]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Hi Christopher,
>>
>> Christopher Baines  skribis:
>>
>>> I've attached a script that when run should reproduce the issue. I
>>> extracted the code relating to lint warnings from the Guix Data
>>> Service. The script attached runs this code twice against the inferior,
>>> once will often be enough to cause it to crash, but twice should
>>> reproduce it more reliably.
>>
>> Thanks a lot.
>>
>> Here’s a backtrace from the core dumped by the inferior:
>
> ...
>
>> It could be an unbounded growth of libgc’s finalizer table or our weak
>> tables as we experienced in .
>>
>> We should be able to reproduce it with something like:
>>
>>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
>> lint -c 
>> inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>>
>> In top one can see that heap usage keeps growing, which may well be a
>> bug in Guix proper rather than in Guile… but it doesn’t crash.
>>
>> I would propose three actions here:
>>
>>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>>  find and address the leak.  As a start, maybe just start reducing
>>  the list of checkers to see if there’s one of them that’s causing
>>  it.
>>
>>  The ‘derivation’ checker is definitely responsible for a lot of the
>>  heap consumption because of the various caches in (guix packages) &
>>  co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>>  (gnu ci).
>>
>>   2. Work around the problem in Guix Data Service by running, say, one
>>  inferior per checker instead of one inferior for all checkers for
>>  all packages.
>>
>>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>>  bug or something like that.
>>
>> Thoughts?
>
> Thanks, that's useful to know.
>
> I think I've now managed to find a way of reproducing this without the
> inferior getting in the way. I was testing if triggering garbage
> collection in Guile would help avoid the problem, but actually it seems
> to cause it. I guess given the mentions of GC in the above stacktrace,
> and the major version change of libgc, some GC related bug seems quite
> likely here.
>
> I've been testing with a checkout of Guix built with Guix from the
> core-updates branch. I think that provides the same broken Guile that
> the guix repl is using.
>
> When trying to just use a checkout of the core-updates branch, and guile
> built from that branch I get the following odd error:
>
> → ./pre-inst-env 
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile 
> ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
> guile: warning: failed to install locale
> warning: failed to load '(gnu packages abiword)': Function not implemented
> error: git-fetch: unbound variable
> hint: Did you forget `(use-modules (guix git-download))'?
>
> error: git-version: unbound variable
>
>
>
> No idea what's happening there, but when I ./configure and make with
> packages from core-updates, I seem to end up with a setup that works:
>
> This is the guile I'm using: 
> /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile
>
> If you just run the script, you should see:
>
> → ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm
>
> ;;; ("%package-table-setup" #)
> mmap(PROT_NONE) failed
> Aborted
>
>
> For more information, you can pipe the script to the REPL. What you
> should see is that it's slow to compute the lint warnings the first
> time, but the subsequent times are quick, and it crashes in one of the
> (gc) calls.
>
> I'm going to try and continue looking in to this, at least it'll be
> easier to delve in to guile now that I can directly control what guile
> is used.

Following up on this, I've built Guile on core-updates with libgc@7
rather than libgc@8 (which is what's used above), and I can't reproduce
the issue. So, I'm getting more certain that this is a regression which
the libgc upgrade has led to.

Would it be feasible to keep guile, or at least the guile Guix uses with
libgc@7 for now?


signature.asc
Description: PGP signature

bug#40669: New "official" exfat-utils package

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

Leo,

Leo Famulari 写道：

Help wanted packaging the new exfatprogs!


I already have a package.  I'll send it here.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#40669: New "official" exfat-utils package

[Leo Famulari]

There is a new package for working with Linux-native exFAT filesystems:

https://github.com/exfatprogs/exfatprogs
https://lkml.org/lkml/2020/4/8/1014

It was originally called exfat-utils, like our existing FUSE-based
exfat-utils package, but it will be renamed exfatprogs in the next
release.

Help wanted packaging the new exfatprogs!

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Christopher,
>
> Christopher Baines  skribis:
>
>> I've attached a script that when run should reproduce the issue. I
>> extracted the code relating to lint warnings from the Guix Data
>> Service. The script attached runs this code twice against the inferior,
>> once will often be enough to cause it to crash, but twice should
>> reproduce it more reliably.
>
> Thanks a lot.
>
> Here’s a backtrace from the core dumped by the inferior:

...

> It could be an unbounded growth of libgc’s finalizer table or our weak
> tables as we experienced in .
>
> We should be able to reproduce it with something like:
>
>   guix time-machine --commit=d523eb5c9c2659cbbaf4eeef3691234ae527ee6a -- \
> lint -c 
> inputs-should-be-native,license,mirror-url,source-file-name,source-unstable-tarball,derivation,patch-file-names,formatting,synopsis
>
> In top one can see that heap usage keeps growing, which may well be a
> bug in Guix proper rather than in Guile… but it doesn’t crash.
>
> I would propose three actions here:
>
>   1. Run linters un ‘gcprof’ to see what’s eating memory and hopefully
>  find and address the leak.  As a start, maybe just start reducing
>  the list of checkers to see if there’s one of them that’s causing
>  it.
>
>  The ‘derivation’ checker is definitely responsible for a lot of the
>  heap consumption because of the various caches in (guix packages) &
>  co.  Perhaps add calls to ‘invalidate-derivation-caches!’ as in
>  (gnu ci).
>
>   2. Work around the problem in Guix Data Service by running, say, one
>  inferior per checker instead of one inferior for all checkers for
>  all packages.
>
>   3. If #1 didn’t help, let’s see if we can isolate a Guile weak-table
>  bug or something like that.
>
> Thoughts?

Thanks, that's useful to know.

I think I've now managed to find a way of reproducing this without the
inferior getting in the way. I was testing if triggering garbage
collection in Guile would help avoid the problem, but actually it seems
to cause it. I guess given the mentions of GC in the above stacktrace,
and the major version change of libgc, some GC related bug seems quite
likely here.

I've been testing with a checkout of Guix built with Guix from the
core-updates branch. I think that provides the same broken Guile that
the guix repl is using.

When trying to just use a checkout of the core-updates branch, and guile
built from that branch I get the following odd error:

→ ./pre-inst-env 
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile 
./reproduce-core-updates-mmap-PROT_NONE-failed.scm
guile: warning: failed to install locale
warning: failed to load '(gnu packages abiword)': Function not implemented
error: git-fetch: unbound variable
hint: Did you forget `(use-modules (guix git-download))'?

error: git-version: unbound variable



No idea what's happening there, but when I ./configure and make with
packages from core-updates, I seem to end up with a setup that works:

This is the guile I'm using: 
/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile

If you just run the script, you should see:

→ ./pre-inst-env guile ./reproduce-core-updates-mmap-PROT_NONE-failed.scm

;;; ("%package-table-setup" #)
mmap(PROT_NONE) failed
Aborted


For more information, you can pipe the script to the REPL. What you
should see is that it's slow to compute the lint warnings the first
time, but the subsequent times are quick, and it crashes in one of the
(gc) calls.

I'm going to try and continue looking in to this, at least it'll be
easier to delve in to guile now that I can directly control what guile
is used.

Thanks,

Chris

(use-modules (srfi srfi-1)
 (ice-9 match)
 (gnu packages)
 (guix store)
 (guix grafts)
 (guix packages)
 (guix lint)
 (guix utils))

(define %package-table (make-hash-table))
(begin
  (fold-packages (lambda (package result)
   (let ((id (object-address package)))
 (hashv-set! %package-table id package)
 (cons (list (package-name package)
 (package-version package)
 id)
   result)))
 '())
  (peek "%package-table-setup" %package-table))

(define lint-warnings-for-checker
  (lambda (checker-name store)
(let* ((checker (find (lambda (checker)
(eq? (lint-checker-name checker)
 checker-name))
  %local-checkers))
   (check (lint-checker-check checker)))

  (define (process-lint-warning lint-warning)
(list
 (match (lint-warning-location lint-warning)
   (($  file line column)
(list (if (string-prefix? "/gnu/store/" file)
  (string-join (drop (string-split file #\/) 8) "/")
  

bug#40650: guix test suite failures building Debian package

[Vagrant Cascadian]

Thanks for the quick response!

On 2020-04-16, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> Any of the test suites that require networking will need to be disabled
>> for Debian packages.
>
> That should be fine.

Well, they need to be disabled even if networking is available...

We might be able to make some of them "autopackagetests" ... e.g. tests
that are run as part of Debian's CI infrastructure on the installed
packages (as opposed to tests run from within the source tree).


>> test-name: wrap-program, one input, multiple calls
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/build-utils.scm:94
>> source:
>> + (test-equal
>> +   "wrap-program, one input, multiple calls"
>> +   "hello world\n"
>> +   (call-with-temporary-directory
>> + (lambda (directory)
>> +   (let ((bash (search-bootstrap-binary
>> + "bash"
>> + (%current-system)))
>> + (foo (string-append directory "/foo")))
>> + (call-with-output-file
>> +   foo
>> +   (lambda (p)
>> + (format
>> +   p
>> +   "#!~a~%echo \"${GUIX_FOO} ${GUIX_BAR}\"~%"
>> +   bash)))
>> + (chmod foo 511)
>> + (with-environment-variable
>> +   "PATH"
>> +   (dirname bash)
>> +   (wrap-program foo `("GUIX_FOO" prefix ("hello")))
>> +   (wrap-program foo `("GUIX_BAR" prefix ("world")))
>> +   (unsetenv "LOCPATH")
>> +   (let* ((pipe (open-input-pipe foo))
>> +  (str (get-string-all pipe)))
>> + (with-directory-excursion
>> +   directory
>> +   (for-each delete-file '("foo" ".foo-real")))
>> + (and (zero? (close-pipe pipe)) str)))
>> expected-value: "hello world\n"
>> actual-value: #f
>> actual-error:
>> + (system-error
>> +   "copy-file"
>> +   "~A: ~S"
>> +   ("Permission denied"
>> +"/build/guix-jgTHmh/guix-1.1.0/gnu/packages/bootstrap/i686-linux/bash")
>> +   (13))
>> result: FAIL
>
> Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
> create the file above, having downloaded it earlier.
>
> For the ‘guix’ package in Guix, what we do is that this and related
> files are inputs to the package; that way, they are not downloaded at
> all upon ‘make check’ since they’re already there.
>
> All you need is to ensure that
> gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
> executable, and are statically-linked.  You could provide Debian
> binaries if that’s more appropriate.

Regarding providing Debian binaries, I could Build-Depend (the debian
equivalent of "inputs") on bash-static and symlink to that, and maybe
use busybox-static and symlinks for mkdir and tar, but I don't think
there's a static implementation of xz in Debian.

Do they strictly need to be statically linked? These are just for test
suites, not actually used in the eventual packaged guix?

I notice it's also checking for i686-linux/bash above even though the
build was done on amd64/x86_64 ... and it would be non-trivial to enable
cross-architecture checks for all architectures across all of Debian's
architectures.


>> test-name: channel-instances->manifest
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/channels.scm:177
>
> [...]
>
>> +Initialized empty Git repository in 
>> /tmp/guix-directory.kYfBE0/.git/
>>
>> *** Please tell me who you are.
>>
>> Run
>>
>>   git config --global user.email "y...@example.com"
>>   git config --global user.name "Your Name"
>>
>> to set your account's default identity.
>> Omit --global to set the identity only in this repository.
>>
>> fatal: unable to auto-detect email address (got 'vagrant@yucca.(none)')
>
> We may need to provide a dummy .gitconfig file or something here so we
> can run these tests.  See also .
> (The same applies to several test failures.)
>
> Thoughts?

I could try a couple things ... basically re-implement the patch from
#37679 in Debian's packaging (e.g. HOME=/some/path and populate
$HOME/.gitconfig), or apply the patch and try it. :)


>> test-name: scandir*, properties
>> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
>> source:
>> + (test-assert
>> +   "scandir*, properties"
>> +   (let ((directory
>> +   (dirname
>> + (search-path %load-path "guix/base32.scm"
>> + (every (lambda (entry name)
>> +  (match entry
>> + ((name2 . properties)
>> +  (and (string=? name2 name)
>> +   (let* ((full (string-append directory "/" name))
>> +  (stat (lstat full))
>> +  (inode (assoc-ref properties 'inode))
>> +  (type (assoc-ref properties 'type)))
>> + (and (= inode (stat:ino stat))
>> +  (or (eq? type 'unknown)
>> + 

bug#40583: guix-system-install-1.0.1.i686 fails to build amdgpu

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> could you try installing the i686 version from
> https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc2.5/ ?

Or the just-released 1.1.0?  It very likely fixes the “screen noise”
issue you encountered:

  https://guix.gnu.org/download/

Thanks in advance,
Ludo’.

bug#40574: [wip-hurd-vm]: cross-build of `guix' fails

[Ludovic Courtès]

Hello!

Jan Nieuwenhuizen  skribis:

> In procedure lstat: No such file or directory: 
> "/tmp/guix-build-guix-1.0.1-18.11fc384.drv-0/source/gnu/../gnu/installer/~^m\x18
>  "

This one is funny:

--8<---cut here---start->8---
$ (unset GUILE_LOAD_COMPILED_PATH; COLUMNS=200 XDG_CACHE_HOME=/nowhere guild 
compile --target=i586-pc-gnu -L . gnu/ci.scm -o foo.go)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /home/ludo/.guix-profile/bin/guild
;;; WARNING: compilation of /home/ludo/.guix-profile/bin/guild failed:
;;; failed to create path for auto-compiled file 
"/home/ludo/.guix-profile/bin/guild"
WARNING: Use of `load' in declarative module (guix ui).  Add #:declarative? #f 
to your define-module invocation.
WARNING: (guix build emacs-build-system): imported module (guix build utils) 
overrides core binding `delete'
WARNING: Use of `load' in declarative module (gnu system install).  Add 
#:declarative? #f to your define-module invocation.
Backtrace:
In ice-9/boot-9.scm:
  3297:17 19 (resolve-interface (gnu system install) #:select _ #:hide _ 
#:prefix _ #:renamer _ #:version _)
In ice-9/threads.scm:
390:8 18 (_ _)
In ice-9/boot-9.scm:
  3223:13 17 (_)
In ice-9/threads.scm:
390:8 16 (_ _)
In ice-9/boot-9.scm:
  3507:20 15 (_)
   2806:4 14 (save-module-excursion _)
  3527:26 13 (_)
In unknown file:
  12 (primitive-load-path "gnu/system/install" #)
In ice-9/eval.scm:
   626:19 11 (_ #)
   173:47 10 (_ #(#(# 
#< name: "motd" content: "\n\x1b[1;37mWelcome to the installation 
of GNU Guix!\x1b[0m\n\n\x1b[2mUsing this shell…>) …))
   196:43  9 (_ #(#(# 
#< name: "motd" content: "\n\x1b[1;37mWelcome to the installation 
of GNU Guix!\x1b[0m\n\n\x1b[2mUsing this shell…>) …))
   293:34  8 (_ #(#(#(# 
#< name: "motd" content: "\n\x1b[1;37mWelcome to the installation 
of GNU Guix!\x1b[0m\n\n\x1b[2mUsing this …>) …) #))
619:8  7 (_ #(#(#(#)) # …))
   626:19  6 (_ #(#(#(#)) # …))
159:9  5 (_ #(#(#(#) 
"/home/ludo/src/guix/gnu/.." "gnu/installer") 26))
In srfi/srfi-1.scm:
   495:18  4 (fold-right # () _ . _)
In ice-9/eval.scm:
   293:34  3 (_ #(#(#(#(#(#(#(# ("ރl^ 
" (type . unknown) (inode . 17571939)) 
"/home/ludo/src/guix/gnu/../gnu/installer" # …)) …) …) …) …) 
…))
155:9  2 (_ #(#(#(#(#) 
"/home/ludo/src/guix/gnu/../gnu/installer/ރl^ " ((type . unknown) (inode . 
17571939))) unknown) #))
In unknown file:
   1 (lstat "/home/ludo/src/guix/gnu/../gnu/installer/ރl^ ")
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure lstat: Dosiero aŭ dosierujo ne ekzistas: 
"/home/ludo/src/guix/gnu/../gnu/installer/ރl^ "
--8<---cut here---end--->8---

(A good opportunity to learn about THAANA LETTER RAA!
)

Here ‘scandir*’ from (guix build syscalls) is being interpreted and
presumably it gets all the struct offsets wrong (32-bit instead of
64-bit I guess), hence the funny file name.  (‘scandir*’ is called from
‘scheme-modules*’ in (gnu installer), itself from the
‘installer-program’ call in (gnu system install).)

This bit is fixed in 82d8959e5d137b2061a68878d78a8f74a238ac44.

To be continued…

Thank you,
Ludo’.

bug#40565: make authenticate fails: commit 77704cb13e5bebf412297dab764a00849a3cfdc0: key A0C5E3522EF8EF5C64CDB7F0FD73CAC719D32566 is missing

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

Ela, Eric,

elaexuotee--- via Bug reports for GNU Guix 写道：
It looks like the referenced key doesn't exist in the 
keyservers:


$ gpg --recv-keys A0C5E3522EF8EF5C64CDB7F0FD73CAC719D325
gpg: keyserver receive failed: No data

Am I flubbing something up? Or is this a legitimate issue?


It's not you.  ‘make authenticate’ is currently broken for any 
practical purpose.


Eric, I didn't find any previous discussion about this.  Could you 
help us out by publishing this ‘secret’ key somewhere?  :-)


Your key at Savannah[0] is a different one and there's no 
A0C5E3522EF8EF5C64CDB7F0FD73CAC719D325 on keys.openpgp.org, SKS, 
keys.gnupg.net, or pgp.mit.edu.


Kind regards,

T G-R

[0]: curl 
https://savannah.gnu.org/people/viewgpg.php?user_id=93889 | gpg

pub   rsa2048/0x34532F9FAFCA8B8E 2016-05-26 [SC]
 Key fingerprint = 34FF 38BC D151 25A6 E340  A0B5 3453 2F9F 
 AFCA 8B8E
uid Eric Bavier 

sub   rsa2048/0x5A9C1FD168338676 2016-05-26 [E] [expired: 
2017-05-26]
sub   rsa2048/0x1EBBD204781F962C 2016-05-26 [S] [expired: 
2017-05-26]
sub   rsa4096/0xFD73CAC719D32566 2017-06-13 [S] [expires: 
2021-06-12]


signature.asc
Description: PGP signature

bug#40626: Poor performance on low-end ARMv7 devices

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Most of it seems to go in loading .go files:

On x86_64, I’ve run:

  ./pre-inst-env perf record guile -c '(use-modules (gnu packages libreoffice))'

which shows mostly GC activity, along with symbol interning activity:

--8<---cut here---start->8---
  14.71%  guilelibgc.so.1.3.6 [.] GC_mark_from
   7.49%  guilelibgc.so.1.3.6 [.] GC_header_cache_miss
   5.56%  guilelibguile-3.0.so.1.1.1  [.] vm_regular_engine
   5.42%  guilelibgc.so.1.3.6 [.] GC_add_to_black_list_normal
   2.66%  guilelibpthread-2.29.so [.] __pthread_mutex_unlock_usercnt
   2.63%  guilelibgc.so.1.3.6 [.] GC_find_header
   2.09%  guileld-2.29.so [.] _dl_update_slotinfo
   1.88%  guilelibguile-3.0.so.1.1.1  [.] scm_c_weak_set_lookup
   1.68%  guilelibguile-3.0.so.1.1.1  [.] narrow_string_hash
   1.64%  guilelibguile-3.0.so.1.1.1  [.] scm_i_is_narrow_string
   1.55%  guilelibguile-3.0.so.1.1.1  [.] scm_ihashq
   1.52%  guilelibguile-3.0.so.1.1.1  [.] scm_sloppy_assq
   1.32%  guilelibgc.so.1.3.6 [.] GC_move_disappearing_link_inner
   1.23%  guilelibgc.so.1.3.6 [.] GC_malloc_kind
   1.23%  guilelibpthread-2.29.so [.] __pthread_mutex_lock
   1.22%  guilelibguile-3.0.so.1.1.1  [.] scm_hash_fn_get_handle
   1.19%  guilelibpthread-2.29.so [.] __pthread_mutex_trylock
   1.12%  guilelibguile-3.0.so.1.1.1  [.] get_callee_vcode
   1.12%  guilelibguile-3.0.so.1.1.1  [.] scm_equal_p
--8<---cut here---end--->8---

Back on my A20 board, I get this (unhelpful) GC profile:

--8<---cut here---start->8---
scheme@(guix-user)> ,use(statprof)
scheme@(guix-user)> (gcprof (lambda () (resolve-module '(gnu packages base
% cumulative   self
time   seconds seconds  procedure
100.00  5.13  5.13  ice-9/boot-9.scm:2201:0:%load-announce
  0.00   4081.53  0.00  ice-9/boot-9.scm:220:5:map1
  0.00621.21  0.00  ice-9/threads.scm:388:4
  0.00310.61  0.00  ice-9/boot-9.scm:2803:0:save-module-excursion
  0.00310.61  0.00  anon #x1b15600
  0.00310.61  0.00  ice-9/boot-9.scm:3211:7
  0.00310.61  0.00  ice-9/boot-9.scm:3500:5
  0.00310.61  0.00  ice-9/boot-9.scm:3508:21
  0.00305.47  0.00  ice-9/boot-9.scm:3256:0:resolve-interface
  0.00295.21  0.00  ice-9/boot-9.scm:3381:5
  0.00295.21  0.00  ice-9/boot-9.scm:3351:0:define-module*
  0.00  5.13  0.00  anon #xb2d8d098
  0.00  5.13  0.00  anon #xb32d0098
  0.00  5.13  0.00  anon #xb2fca098
  0.00  5.13  0.00  anon #xb32e2098
  0.00  5.13  0.00  anon #xb3343098
  0.00  5.13  0.00  ice-9/boot-9.scm:2557:0:call-with-deferred-observers
[…]
---
Sample count: 2
Total time: 5.134 seconds (0.44 seconds in GC)
--8<---cut here---end--->8---

and this profile:

--8<---cut here---start->8---
scheme@(guix-user)> ,pr (resolve-module '(gnu packages base))
% cumulative   self
time   seconds seconds  procedure
 17.86  1.38  1.38  ice-9/boot-9.scm:2201:0:%load-announce
  5.36  0.41  0.41  ice-9/boot-9.scm:3545:0:autoload-done!
  4.76  0.37  0.37  
ice-9/boot-9.scm:3540:0:autoload-done-or-in-progress?
  4.76  0.37  0.37  anon #x1a671cc
  4.17  0.32  0.32  ice-9/format.scm:113:2:format:format-work
  3.57  0.28  0.28  ice-9/boot-9.scm:3552:0:autoload-in-progress!
  2.98  0.55  0.23  ice-9/boot-9.scm:1396:0:symbol-append
  2.98  0.23  0.23  anon #x1a65c28
  1.79  0.32  0.14  ice-9/boot-9.scm:2729:0:module-make-local-var!
  1.79  0.14  0.14  anon #x1a671a4
  1.79  0.14  0.14  anon #x1a6c284
  1.79  0.14  0.14  anon #x1a67644
  1.79  0.14  0.14  ice-9/boot-9.scm:3209:4
  1.19   6106.96  0.09  ice-9/boot-9.scm:220:5:map1
  1.19518.54  0.09  ice-9/boot-9.scm:3211:7
  1.19511.19  0.09  ice-9/boot-9.scm:3381:5
  1.19  5.69  0.09  anon #xb13f9098
  1.19  0.18  0.09  anon #xad994098
  1.19  0.09  0.09  anon #x1a6848c
  1.19  0.09  0.09  srfi/srfi-60.scm:57:0:bitwise-if
  1.19  0.09  0.09  ice-9/boot-9.scm:2468:2
  1.19  0.09  0.09  ice-9/boot-9.scm:2468:2
  1.19  0.09  0.09  anon #x1a6e284
  1.19  0.09  0.09  anon #x1a67cd4
  1.19  0.09  0.09  anon #x1a6e87c
[…]
---
Sample count: 168
Total time: 7.714 seconds (1.279 seconds in GC)
--8<---cut here---end--->8---

What’s the deal with ‘%load-announce’?  How many times is it called?

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type 

bug#24937: "deleting unused links" GC phase is too slow

[Ricardo Wurmus]

Here are more benchmarks on one of the build nodes.  It doesn’t nearly
have as many used inodes as ci.guix.gnu.org, but I could fill it up if
necessary.

  root@hydra-guix-127 ~# df -i /gnu/
  Filesystem   Inodes   IUsedIFree IUse% Mounted on
  /dev/sda3  28950528 2796829 26153699   10% /

  root@hydra-guix-127 ~# ls -1 /gnu/store/.links | wc -l
  2017395

I tested all three modes with statx and with lstat.  The
links-traversal-statx.c is attached below.

* mode 1 + statx

--8<---cut here---start->8---
root@hydra-guix-127 ~ [env]# gcc -Wall -std=c99 links-traversal-statx.c 
-DMODE=1 -D_GNU_SOURCE=1 -o links-traversal
links-traversal-statx.c:53:8: warning: �stat_entries� defined but not used 
[-Wunused-function]
   53 |   void stat_entries (void)
  |^~~~
root@hydra-guix-127 ~ [env]# echo 3 > /proc/sys/vm/drop_caches
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 9 seconds (including stat)

real0m9.176s
user0m0.801s
sys 0m4.236s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 4 seconds (including stat)

real0m3.556s
user0m0.708s
sys 0m2.848s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 4 seconds (including stat)

real0m3.553s
user0m0.599s
sys 0m2.954s
root@hydra-guix-127 ~ [env]# 
--8<---cut here---end--->8---


* mode 2 + statx

--8<---cut here---start->8---
root@hydra-guix-127 ~ [env]# gcc -Wall -std=c99 links-traversal-statx.c 
-DMODE=2 -D_GNU_SOURCE=1 -o links-traversal
root@hydra-guix-127 ~ [env]# echo 3 > /proc/sys/vm/drop_caches
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 10 seconds (including stat)

real0m9.598s
user0m1.210s
sys 0m4.257s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 4 seconds (including stat)

real0m4.094s
user0m0.988s
sys 0m3.107s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 4 seconds (including stat)

real0m4.095s
user0m0.933s
sys 0m3.162s
root@hydra-guix-127 ~ [env]# 
--8<---cut here---end--->8---


* mode 3 + statx

--8<---cut here---start->8---
root@hydra-guix-127 ~ [env]# gcc -Wall -std=c99 links-traversal-statx.c 
-DMODE=3 -D_GNU_SOURCE=1 -o links-traversal^C
root@hydra-guix-127 ~ [env]# echo 3 > /proc/sys/vm/drop_caches
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 7 seconds
stat took 3 seconds

real0m9.992s
user0m1.411s
sys 0m4.221s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 1 seconds
stat took 2 seconds

real0m4.265s
user0m1.120s
sys 0m3.145s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 2 seconds
stat took 2 seconds

real0m4.267s
user0m1.072s
sys 0m3.195s
root@hydra-guix-127 ~ [env]# 
--8<---cut here---end--->8---

Now with just lstat:

* mode 1 + lstat

--8<---cut here---start->8---
root@hydra-guix-127 ~ [env]# gcc -Wall -std=c99 links-traversal.c -DMODE=1 
-D_GNU_SOURCE=1 -o links-traversal
links-traversal.c:49:8: warning: �stat_entries� defined but not used 
[-Wunused-function]
   49 |   void stat_entries (void)
  |^~~~
root@hydra-guix-127 ~ [env]# echo 3 > /proc/sys/vm/drop_caches
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 9 seconds (including stat)

real0m9.303s
user0m0.748s
sys 0m4.397s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 4 seconds (including stat)

real0m3.526s
user0m0.540s
sys 0m2.987s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
2017397 dir_entries, 3 seconds (including stat)

real0m3.519s
user0m0.600s
sys 0m2.919s
root@hydra-guix-127 ~ [env]# 
--8<---cut here---end--->8---

* mode 2 + lstat

--8<---cut here---start->8---
root@hydra-guix-127 ~ [env]# gcc -Wall -std=c99 links-traversal.c -DMODE=2 
-D_GNU_SOURCE=1 -o links-traversal
root@hydra-guix-127 ~ [env]# echo 3 > /proc/sys/vm/drop_caches
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 9 seconds (including stat)

real0m9.614s
user0m1.205s
sys 0m4.250s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 4 seconds (including stat)

real0m4.060s
user0m1.052s
sys 0m3.008s
root@hydra-guix-127 ~ [env]# time ./links-traversal 
17377 dir_entries, 4 seconds (including stat)

real0m4.057s
user0m0.984s
sys 0m3.073s
root@hydra-guix-127 ~ [env]# 
--8<---cut here---end--->8---

* mode 3 + lstat

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

bug#40544: Pulseaudio is not looking for user configuration

[Diego Nicola Barbato]

Hey,

pkill9  writes:

> Pulseaudio doesn't read my user configuration files according to strace.
>
> Attached is the output of `strace -o /tmp/log.log pulseaudio` - It only
> looks for /etc/pulse/daemon.conf.

That's a known [0] (but AFAIK undocumented) side effect of the
PulseAudio service, which was added to %desktop-services in January [1].
If you want PulseAudio to read your user configuration files you'll have
to remove that service from your system services or unset PULSE_CONFIG
and PULSE_CLIENT_CONFIG in ~/.profile [2].

Regards,

Diego

[0]: https://lists.gnu.org/archive/html/guix-patches/2020-01/msg00388.html
[1]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=71e33e32fcedbd0aaafda4fd548fb8443064253c
[2]: https://lists.gnu.org/archive/html/guix-patches/2020-01/msg00408.html

bug#40652: GDM does not starts after April 10 system reconfigure

[sirgazil via Bug reports for GNU Guix]

Yes, Rene, that worked.

I deleted "/var/lib/gdm" and also ".local/share" and ".cache", which were 4.7 
GiB and 2.9 GiB respectively.

Reading bug #36924 now I remember I've been through this before.

bug#24937: "deleting unused links" GC phase is too slow

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> Ricardo, Roel: would you be able to run that links-traversal.c from
>> 
>> on a machine with a big store, as described at
>> ?
>
> I just ran this on my workstation in the office where I regularly build
> packages.  Here’s the output of “df -i /gnu”
>
>   Filesystem   Inodes   IUsed   IFree IUse% Mounted on
>   /dev/mapper/fedora-root 3301376 1098852 2202524   34% /
>
> Probably not large enough to derive conclusions about hydra’s behaviour.
>
> [I can’t run it on the shared store at the MDC because NFS performance is
> too poor.  I recently ran “guix gc --optimize” to dedupe the shared
> store (post-build deduplication is disabled since a few weeks) and it’s
> at 3,197,489 used inodes.]
>
> Here are the results of running the link-traversal code on my
> workstation:
>
> --8<---cut here---start->8---
> rwurmus in ~: gcc -std=gnu99 -Wall links-traversal.c  -DMODE=3
> rwurmus in ~: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> rwurmus in ~: time ./a.out
> 412825 dir_entries, 107 seconds
> stat took 0 seconds
>
> real  1m47.264s
> user  0m0.214s
> sys   0m1.314s
>
> rwurmus in ~: gcc -std=gnu99 -Wall links-traversal.c  -DMODE=2
> rwurmus in ~: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> rwurmus in ~: time ./a.out
> 12821 dir_entries, 107 seconds (including stat)
>
> real  1m46.475s
> user  0m0.201s
> sys   0m1.309s
> --8<---cut here---end--->8---

I ran this for the first time on ci.guix.gnu.org, which has a very big
store (currently at around 29TB).

df -i /gnu:

  FilesystemInodes IUsed IFree IUse% Mounted on
  /dev/sdb1  610021376 132350406 477670970   22% /gnu

I had to increase the number of MAX_ENTRIES to 13500.

I forgot to drop caches initially.  This is the first run:

--8<---cut here---start->8---
root@berlin ~ [env]# gcc links-traversal.c -DMODE=3 -o links-traversal
root@berlin ~ [env]# time ./links-traversal
57079502 dir_entries, 3906 seconds
stat took 136 seconds

real67m48.145s
user0m59.575s
sys 2m30.065s
--8<---cut here---end--->8---

I aborted the run after I dropped caches after 67 minutes.

I’m going to continue testing on one of the build nodes, and I’ll try
using statx.

--
Ricardo

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

Guillaume Le Vaillant  skribis:

> Ludovic Courtès  skribis:
>
>> Hi Guillaume,
>>
>> Guillaume Le Vaillant  skribis:
>>
>>> I don't know if it's related, but recently I had GDM crashes at boot
>>> after reconfiguring a system using gdm-service-type (generation n) to
>>> make it use slim-service-type instead (generation n+1), and then
>>> reconfiguring to gdm-service-type again (generation n+2).
>>>
>>> The problem was that the 'gdm' user id number (or group id number) was
>>> not the same in generations n and n+2, which prevented GDM from
>>> accessing the '/var/lib/gdm' directory.
>>
>> When did that happen?
>>
>> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
>> ensures that /var/lib/gdm has proper ownership.
>>
>> Thanks,
>> Ludo’.
>
> I think it was around 2 weeks ago.

Concerning the service extensions of gdm-service-type, is it guaranteed
that %gdm-activation will be run after %gdm-accounts and not before?
If it's not the case it could explain the problem...


signature.asc
Description: PGP signature

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  skribis:
>
>> I don't know if it's related, but recently I had GDM crashes at boot
>> after reconfiguring a system using gdm-service-type (generation n) to
>> make it use slim-service-type instead (generation n+1), and then
>> reconfiguring to gdm-service-type again (generation n+2).
>>
>> The problem was that the 'gdm' user id number (or group id number) was
>> not the same in generations n and n+2, which prevented GDM from
>> accessing the '/var/lib/gdm' directory.
>
> When did that happen?
>
> Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
> ensures that /var/lib/gdm has proper ownership.
>
> Thanks,
> Ludo’.

I think it was around 2 weeks ago.


signature.asc
Description: PGP signature

bug#40652: #36924 way solves the problem for me

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant  skribis:

> I don't know if it's related, but recently I had GDM crashes at boot
> after reconfiguring a system using gdm-service-type (generation n) to
> make it use slim-service-type instead (generation n+1), and then
> reconfiguring to gdm-service-type again (generation n+2).
>
> The problem was that the 'gdm' user id number (or group id number) was
> not the same in generations n and n+2, which prevented GDM from
> accessing the '/var/lib/gdm' directory.

When did that happen?

Commit a43e9157ef479e94c19951cc9d228cf153bf78ee (Sep. 2019) supposedly
ensures that /var/lib/gdm has proper ownership.

Thanks,
Ludo’.

bug#40650: guix test suite failures building Debian package

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> Any of the test suites that require networking will need to be disabled
> for Debian packages.

That should be fine.

> One thing that occurs to me is Debian systems have USER_NS_UNPRIVLEDGED
> disabled by default (enableable at run-time with
> /proc/sys/kernel/unprivileged_userns_clone).

That should be fine too: tests that rely on unprivileged user namespaces
are skipped when that’s missing.

> Attached is the test-suite.log, as requested.

Excellent!

> test-name: wrap-program, one input, multiple calls
> location: /build/guix-jgTHmh/guix-1.1.0/tests/build-utils.scm:94
> source:
> + (test-equal
> +   "wrap-program, one input, multiple calls"
> +   "hello world\n"
> +   (call-with-temporary-directory
> + (lambda (directory)
> +   (let ((bash (search-bootstrap-binary
> + "bash"
> + (%current-system)))
> + (foo (string-append directory "/foo")))
> + (call-with-output-file
> +   foo
> +   (lambda (p)
> + (format
> +   p
> +   "#!~a~%echo \"${GUIX_FOO} ${GUIX_BAR}\"~%"
> +   bash)))
> + (chmod foo 511)
> + (with-environment-variable
> +   "PATH"
> +   (dirname bash)
> +   (wrap-program foo `("GUIX_FOO" prefix ("hello")))
> +   (wrap-program foo `("GUIX_BAR" prefix ("world")))
> +   (unsetenv "LOCPATH")
> +   (let* ((pipe (open-input-pipe foo))
> +  (str (get-string-all pipe)))
> + (with-directory-excursion
> +   directory
> +   (for-each delete-file '("foo" ".foo-real")))
> + (and (zero? (close-pipe pipe)) str)))
> expected-value: "hello world\n"
> actual-value: #f
> actual-error:
> + (system-error
> +   "copy-file"
> +   "~A: ~S"
> +   ("Permission denied"
> +"/build/guix-jgTHmh/guix-1.1.0/gnu/packages/bootstrap/i686-linux/bash")
> +   (13))
> result: FAIL

Here’s it’s ‘search-bootstrap-binary’ from (guix tests) that tries to
create the file above, having downloaded it earlier.

For the ‘guix’ package in Guix, what we do is that this and related
files are inputs to the package; that way, they are not downloaded at
all upon ‘make check’ since they’re already there.

All you need is to ensure that
gnu/packages/bootstrap/*-linux/{bash,mkdir,tar,xz} exist, are
executable, and are statically-linked.  You could provide Debian
binaries if that’s more appropriate.

> test-name: channel-instances->manifest
> location: /build/guix-jgTHmh/guix-1.1.0/tests/channels.scm:177

[...]

> +Initialized empty Git repository in 
> /tmp/guix-directory.kYfBE0/.git/
>
> *** Please tell me who you are.
>
> Run
>
>   git config --global user.email "y...@example.com"
>   git config --global user.name "Your Name"
>
> to set your account's default identity.
> Omit --global to set the identity only in this repository.
>
> fatal: unable to auto-detect email address (got 'vagrant@yucca.(none)')

We may need to provide a dummy .gitconfig file or something here so we
can run these tests.  See also .
(The same applies to several test failures.)

Thoughts?

> test-name: scandir*, properties
> location: /build/guix-jgTHmh/guix-1.1.0/tests/syscalls.scm:257
> source:
> + (test-assert
> +   "scandir*, properties"
> +   (let ((directory
> +   (dirname
> + (search-path %load-path "guix/base32.scm"
> + (every (lambda (entry name)
> +  (match entry
> + ((name2 . properties)
> +  (and (string=? name2 name)
> +   (let* ((full (string-append directory "/" name))
> +  (stat (lstat full))
> +  (inode (assoc-ref properties 'inode))
> +  (type (assoc-ref properties 'type)))
> + (and (= inode (stat:ino stat))
> +  (or (eq? type 'unknown)
> +  (eq? type (stat:type stat)
> +(scandir* directory)
> +(scandir directory (const #t) string actual-value: #f
> result: FAIL

Could you wrap the ‘scandir*’ and ‘scandir’ calls in ‘pk’, run:

  make check TESTS=tests/syscalls.scm

and send ‘test-suite.log’?

> ++ guix build guile-gcrypt --with-branch=guile-gcrypt=master -d
> accepted connection from pid 17231, user vagrant
> updating checkout of 'https://notabug.org/cwebber/guile-gcrypt.git'...
> guix build: error: cannot fetch branch 'master' from 
> https://notabug.org/cwebber/guile-gcrypt.git: the SSL certificate is invalid: 
> 0x08 - The certificate is not correctly signed by the trusted CA
> + latest_drv=
> FAIL tests/guix-build-branch.sh (exit status: 1)

This test relies on network access + HTTPS certificates.  It does check
for the former but not the latter.  Any suggestions on 

bug#40652: #36924 way solves the problem for me

[Guillaume Le Vaillant]

R Veera Kumar  skribis:

> The solution in bug #36924 solved the problem in my system.
>
> Remove /var/lib/gdm and make a empty one instead.
>
> Thanks Rene!
>
> Regards,
> Veera

I don't know if it's related, but recently I had GDM crashes at boot
after reconfiguring a system using gdm-service-type (generation n) to
make it use slim-service-type instead (generation n+1), and then
reconfiguring to gdm-service-type again (generation n+2).

The problem was that the 'gdm' user id number (or group id number) was
not the same in generations n and n+2, which prevented GDM from
accessing the '/var/lib/gdm' directory.

Changing the permissions with "chown -R gdm.gdm /var/lib/gdm" or
deleting '/var/lib/gdm' to force the creation of a new one with correct
permissions allowed GDM to work correctly again.


signature.asc
Description: PGP signature