bug#24279: Bug in xterm and/or fontconfig

2017-11-30 Thread Maxim Cournoyer 
Hello,

l...@gnu.org (Ludovic Courtès) writes:

[...]

> We can also fix this once and for all with this patch:
>
> diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
> index 0da3397da..8f285b29a 100644
> --- a/gnu/services/xorg.scm
> +++ b/gnu/services/xorg.scm
> @@ -113,6 +113,8 @@
>  (file-append font-alias "/share/fonts/X11/100dpi")
>  (file-append font-alias "/share/fonts/X11/misc")
>  (file-append font-alias "/share/fonts/X11/cyrillic")
> +(file-append font-misc-misc   ;default fonts for xterm
> + "/share/fonts/X11/misc")
>  (file-append font-adobe75dpi "/share/fonts/X11/75dpi")))
>  
>  (define* (xorg-configuration-file #:key
>
>
> That adds 4.1 MiB, but it saves user headaches, so I think it’s worth it.
>
> I’ll go ahead and push that if there are no objections.

And another bug down! :) Thanks for fixing it; LGTM!

Maxim

bug#29512: build of git-2.15.0.drv failed

2017-11-30 Thread George myglc2 Clemmer 
Hmm... I have discovered that that works when I don't use the
multi-job/multi-core options, e.g., as previously reported, this fails
...

g1@g1 ~/src/guix$ guix package -M 4 -c 4 -m ../g1.scm

But this ...

g1@g1 ~/src/guix$ guix package  -m ../g1.scm

works.

So maybe it's a git bug as opposed to a guix bug.

bug#27943: tar complains about too-long names (guix release)

2017-11-30 Thread Leo Famulari 
> On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
> > I thought about it, but since it’s an unsual case, what about adding a
> > special property to packages instead?  You’d write:
> > 
> >   (package
> > ;; …
> > (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"
> > 
> > ‘guix lint’ would honor this property, and that would address both cases
> > like this and situations where a CVE is known to no longer apply, as is
> > the case with unversioned CVEs¹.
> > 
> > Thoughts?

I'd rather the property's name more clearly reflect that it doesn't
actually fix the vulnerability, but just prevents the linter from
complaining about it.

Someone who sees this property used in a package could reasonably assume
that it's required to list all fixed CVEs in a 'fixed-vulnerabilities'
list, and that it is the "single source of truth" for which bugs apply
to a package. But, it would not actually have anything to do with that,
just being a way to silence the linter.

However, I can't think of a good idea for another name...

On Thu, Nov 30, 2017 at 11:49:01PM +0200, Efraim Flashner wrote:
> I like that idea. It also allows us to mitigate a CVE without needing to
> specifically add a patch. I've attached my first attempt at implementing
> it.

I think of `guix lint -c cve` as one of many tools for discovering
important problems in our packages, but I don't think that we must
absolutely silence the linter. It's always going to be imprecise, with
both false negative and positive results.


signature.asc
Description: PGP signature

bug#29426: guix: "make check" test "utmpx-entries" fails

2017-11-30 Thread Adonay Felipe Nogueira 
Thank you very much. It works nicely now. ;)

2017-11-25T18:14:36+0100 Ludovic Courtès wrote:
> Hi,
>
>
> This is the culprit: its ‘pid’ is 0, but its type is not BOOT_TIME as
> the test expects.  Instead, it’s DEAD_PROCESS (8).
>
> Fixed in commit 4aac8d059a2bec9f075ceea2a089ca029a71912c.
>
> Thanks!
>
> Ludo’.

bug#27943: tar complains about too-long names (guix release)

2017-11-30 Thread Efraim Flashner 
On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433
> > and CVE-2011-5244.¹
> >
> > I tried creating a blank patch (touch t1lib-CVE...) and adding that to
> > satisfy the linter (and bookeeping) but unsuprisingly patch didn't like
> > trying to apply a blank file as a patch.
> 
> Yeah that’s no good.
> 
> > Debian removed it after squeeze², which was Debian 6, so about 6 years
> > ago. Gentoo apparently still has it³. We don't have anything that
> > depends on it so I'm in favor of removing it; even the upstream homepage
> > is gone.
> 
> I don’t have an opinion.  Could you poll guix-devel?
> 
> > This doesn't deal with the possibility that patches that address
> > multiple CVEs that can't be split easily and have a very long name will
> > continue to occur, so the best option I can think of right now is to
> > change the linter to logic like this:
> >
> > CVE- -> The following are all CVEs
> > - -> Full CVE reference
> >  -> Follows the year of the previous CVE
> >
> > which would change t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554 ->
> > t1lib-CVE-2011-1552+1553+1554,
> > and our under-referenced t1lib-CVE-2010-2642 ->
> > t1lib-CVE-2010-2642+2011-0433+5244
> 
> I thought about it, but since it’s an unsual case, what about adding a
> special property to packages instead?  You’d write:
> 
>   (package
> ;; …
> (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"
> 
> ‘guix lint’ would honor this property, and that would address both cases
> like this and situations where a CVE is known to no longer apply, as is
> the case with unversioned CVEs¹.
> 
> Thoughts?
> 
> Ludo’.
> 
> ¹ http://www.openwall.com/lists/oss-security/2017/03/15/3

I like that idea. It also allows us to mitigate a CVE without needing to
specifically add a patch. I've attached my first attempt at implementing
it.

-- 
Efraim Flashner      אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From ad48d84c8659985d706cfe2f8e07314d6017611a Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Thu, 30 Nov 2017 23:41:29 +0200
Subject: [PATCH 1/2] lint: 'check-vulnerabilities' also checks package
 properties.

* guix/scripts/lint.scm (check-vulnerabilities): Also check for CVEs
listed as mitigated in the package properties.
---
 guix/scripts/lint.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index 1b43b0a63..8112595c8 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Hartmut Goebel 
 ;;; Copyright © 2017 Alex Kost 
 ;;; Copyright © 2017 Tobias Geerinckx-Rice 
+;;; Copyright © 2017 Efraim Flashner 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -881,10 +882,11 @@ the NIST server non-fatal."
  (or (and=> (package-source package)
 origin-patches)
  '(
+  (known-safe (assq-ref (package-properties package) 
'fixed-vulnerabilities))
   (unpatched (remove (lambda (vuln)
(find (cute string-contains
<> (vulnerability-id vuln))
- patches))
+ (append patches known-safe)))
  vulnerabilities)))
  (unless (null? unpatched)
(emit-warning package
-- 
2.15.0

From 3ae1af75fe7304a05ca8ac0edd8582d581108d05 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Thu, 30 Nov 2017 23:46:55 +0200
Subject: [PATCH 2/2] gnu: t1lib: Change how patched CVEs are listed.

* gnu/packages/fontutils.scm (t1lib)[source]: Change patch name.
[properties]: New field, register patched CVEs.
* gnu/packages/patches/CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch:
Rename to CVE-2011-1552+.patch.
* gnu/local.mk (dist_patch_DATA): Change patch name.
---
 gnu/local.mk  | 2 +-
 gnu/packages/fontutils.scm| 8 ++--
 ...E-2011-1553+CVE-2011-1554.patch => t1lib-CVE-2011-1552+.patch} | 0
 3 files changed, 7 insertions(+), 3 deletions(-)
 rename 
gnu/packages/patches/{t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch => 
t1lib-CVE-2011-1552+.patch} (100%)

diff --git a/gnu/local.mk b/gnu/local.mk
index 05a86ac17..398839682 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1079,7 +1079,7 @@ dist_patch_DATA = 
\

bug#29512: build of git-2.15.0.drv failed

2017-11-30 Thread George myglc2 Clemmer 
Running guix from clean make check on ...

6e385b76e (HEAD -> master, origin/master, origin/HEAD) gnu: mongodb: Use 
scons-build-system.

... guix package failed ...

guix package: error: build failed: build of 
`/gnu/store/r3rijd3pmkfdmg3h4spyb24az3xiylc4-git-2.15.0.drv' failed

Details:

g1@g1 ~/src/guix$ guix package -M 4 -c 4 -m ../g1.scm
[...]
*** t9153-git-svn-rewrite-uuid.sh ***
not ok 4 - create new branches and tags
#
#   ( cd git_project &&
#   git svn branch -m "New branch 1" -d b_one New1 ) &&
#   ( cd svn_project &&
#   svn_cmd up && test -e b_one/New1/a.file ) &&
#
#   ( cd git_project &&
#   git svn branch -m "New branch 2" -d b_two New2 ) &&
#   ( cd svn_project &&
#   svn_cmd up && test -e b_two/New2/a.file ) &&
#
#   ( cd git_project &&
#   git svn branch -t -m "New tag 1" -d tags_A Tag1 ) &&
#   ( cd svn_project &&
#   svn_cmd up && test -e tags_A/Tag1/a.file ) &&
#
#   ( cd git_project &&
#   git svn tag -m "New tag 2" -d tags_B Tag2 ) &&
#   ( cd svn_project &&
#   svn_cmd up && test -e tags_B/Tag2/a.file )
#
# failed 1 among 4 test(s)
1..4
make[2]: *** [Makefile:49: t9141-git-svn-multiple-branches.sh] Error 1
make[2]: *** Waiting for unfinished jobs
ok 1 - load svn repo
ok 2 - verify uuid
# passed all 2 test(s)
1..2
ok 1 - initialize repo
ok 2 - clone
ok 3 - git svn gc runs
ok 4 - git svn mkdirs recreates empty directories after git svn gc
# passed all 4 test(s)
1..4
ok 1 - load svn dump
ok 2 - all svn merges became git merge commits
ok 3 - cherry picks did not become git merge commits
ok 4 - svn non-merge merge commits did not become git merge commits
ok 5 - commit made to merged branch is reachable from the merge
ok 6 - merging two branches in one commit is detected correctly
not ok 7 - everything got merged in the end # TODO known breakage
# still have 1 known breakage(s)
# passed all remaining 6 test(s)
1..7
make[2]: Leaving directory '/tmp/guix-build-git-2.15.0.drv-0/git-2.15.0/t'
make[1]: *** [Makefile:36: test] Error 2
make[1]: Leaving directory '/tmp/guix-build-git-2.15.0.drv-0/git-2.15.0/t'
make: *** [Makefile:2439: test] Error 2
phase `check' failed after 517.7 seconds
builder for `/gnu/store/r3rijd3pmkfdmg3h4spyb24az3xiylc4-git-2.15.0.drv' failed 
with exit code 1
guix package: error: build failed: build of 
`/gnu/store/r3rijd3pmkfdmg3h4spyb24az3xiylc4-git-2.15.0.drv' failed
g1@g1 ~/src/guix$ exit
exit

Full compressed log (300+K) available if needed.

HTH - George

bug#27943: tar complains about too-long names (guix release)

2017-11-30 Thread Ludovic Courtès 
Hi Efraim,

Efraim Flashner  skribis:

> It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433
> and CVE-2011-5244.¹
>
> I tried creating a blank patch (touch t1lib-CVE...) and adding that to
> satisfy the linter (and bookeeping) but unsuprisingly patch didn't like
> trying to apply a blank file as a patch.

Yeah that’s no good.

> Debian removed it after squeeze², which was Debian 6, so about 6 years
> ago. Gentoo apparently still has it³. We don't have anything that
> depends on it so I'm in favor of removing it; even the upstream homepage
> is gone.

I don’t have an opinion.  Could you poll guix-devel?

> This doesn't deal with the possibility that patches that address
> multiple CVEs that can't be split easily and have a very long name will
> continue to occur, so the best option I can think of right now is to
> change the linter to logic like this:
>
> CVE- -> The following are all CVEs
> - -> Full CVE reference
>  -> Follows the year of the previous CVE
>
> which would change t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554 ->
> t1lib-CVE-2011-1552+1553+1554,
> and our under-referenced t1lib-CVE-2010-2642 ->
> t1lib-CVE-2010-2642+2011-0433+5244

I thought about it, but since it’s an unsual case, what about adding a
special property to packages instead?  You’d write:

  (package
;; …
(properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"

‘guix lint’ would honor this property, and that would address both cases
like this and situations where a CVE is known to no longer apply, as is
the case with unversioned CVEs¹.

Thoughts?

Ludo’.

¹ http://www.openwall.com/lists/oss-security/2017/03/15/3

bug#27943: tar complains about too-long names (guix release)

2017-11-30 Thread Efraim Flashner 
On Tue, Nov 28, 2017 at 03:26:03PM +0100, Ludovic Courtès wrote:
> Hi Danny,
> 
> Danny Milosavljevic  skribis:
> 
> > guix $ make release
> > ... || chmod -R a+r "guix-0.13.0.1849-cf189-dirty"
> > tardir=guix-0.13.0.1849-cf189-dirty && ${TAR-tar} chof - "$tardir" | 
> > GZIP=--best gzip -c >guix-0.13.0.1849-cf189-dirty.tar.gz
> > gzip: warning: GZIP environment variable is deprecated; use an alias or 
> > script
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/ghc-dont-pass-linker-flags-via-response-files.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/libevent-2.0-evbuffer-add-use-last-with-datap.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/python-genshi-stripping-of-unsafe-script-tags.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/python2-pygobject-2-gi-info-type-error-domain.patch:
> >  file name is too long (max 99); not dumped
> > tar: 
> > guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554.patch:
> >  file name is too long (max 99); not dumped
> > tar: Exiting with failure status due to previous errors
> > make[1]: Leaving directory '/home/dannym/src/guix-master/guix'
> 
> “make dist” works fine for me with tar 1.29:
> 
> --8<---cut here---start->8---
> || chmod -R a+r "guix-0.13.0.3626-da9b8"
> tardir=guix-0.13.0.3626-da9b8 && ${TAR-tar} chof - "$tardir" | eval GZIP= 
> gzip --best -c >guix-0.13.0.3626-da9b8.tar.gz
> make[1]: Leaving directory '/home/ludo/src/guix'
> --8<---cut here---end--->8---
> 
> Actually,
> “guix-0.13.0.1849-cf189-dirty/gnu/packages/patches/ghc-dont-pass-linker-flags-via-response-files.patch”
> is 101-character long, so without the “-dirty” prefix as above, we’re
> doing OK.  :-)
> 
> Anyway, commit eef01cfe8eac8dee8ecf727e4ca459ae065e15ea augments the
> ‘patch-file-names’ linter to catch this issue.
> 
> There’s one problematic case left, which is t1lib, but I volunteered
> Efraim to split the big CVE patch in several ones.  :-)
> 
> Thanks,
> Ludo’.

It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433
and CVE-2011-5244.¹

I tried creating a blank patch (touch t1lib-CVE...) and adding that to
satisfy the linter (and bookeeping) but unsuprisingly patch didn't like
trying to apply a blank file as a patch.

Debian removed it after squeeze², which was Debian 6, so about 6 years
ago. Gentoo apparently still has it³. We don't have anything that
depends on it so I'm in favor of removing it; even the upstream homepage
is gone.

This doesn't deal with the possibility that patches that address
multiple CVEs that can't be split easily and have a very long name will
continue to occur, so the best option I can think of right now is to
change the linter to logic like this:

CVE- -> The following are all CVEs
- -> Full CVE reference
 -> Follows the year of the previous CVE

which would change t1lib-CVE-2011-1552+CVE-2011-1553+CVE-2011-1554 ->
t1lib-CVE-2011-1552+1553+1554,
and our under-referenced t1lib-CVE-2010-2642 ->
t1lib-CVE-2010-2642+2011-0433+5244


¹ https://github.com/gentoo/gentoo/pull/2906/files
² https://sources.debian.net/src/t1lib/
³ https://security.gentoo.org/glsa/201701-57

-- 
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#29255: "Profile contains conflicting entries" could be more helpful

2017-11-30 Thread Ludovic Courtès 
Hi,

Ricardo Wurmus  skribis:

> In this case it is not entirely clear that the existing python-requests
> package in the profile is “old”.  The version looks the same and the
> hash is opaque.
>
> Would it be possible to record something about the Guix version that was
> used to install a package?  Then we could say:
>
>   An older variant of python-requests is installed in this profile
>   (propagated from package “foo-bar”) and conflicts with a newer variant
>   (propagated from package “python-twine”).

When the version numbers are the same, we cannot tell whether a variant
is “older”, we can just tell that it’s different.  Also, I find it
useful to see the propagation stack as is currently the case.

With the patch below, I get:

--8<---cut here---start->8---
$ ./pre-inst-env guix package -p foo -i python@2 python
The following packages will be installed:
   python   2.7.13  
/gnu/store/vysfxizaddh1q8s5qjgbdkzxx0585dzi-python-2.7.13
   python   3.5.3   /gnu/store/m4rdgmvdqcxs2zhv42idnz1s1w391i8j-python-3.5.3

guix package: error: profile contains conflicting entries for python:out
guix package: error:   first entry: python@2.7.13 
/gnu/store/vysfxizaddh1q8s5qjgbdkzxx0585dzi-python-2.7.13
guix package: error:   second entry: python@3.5.3 
/gnu/store/m4rdgmvdqcxs2zhv42idnz1s1w391i8j-python-3.5.3
hint: You cannot have two different versions or variants of `python' in the 
same profile.
--8<---cut here---end--->8---

and:

--8<---cut here---start->8---
$ ./pre-inst-env guix package -i guile-cairo -p foo --no-grafts
The following package will be installed:
   guile-cairo  1.4.1   
/gnu/store/dsdbp9sqla6zz2skljlcr5zfjyzvargf-guile-cairo-1.4.1

guix package: error: profile contains conflicting entries for cairo:out
guix package: error:   first entry: cairo@1.14.10 
/gnu/store/c4vl4hw5jccg0b23sfvs0kdnfdbxdlgm-cairo-1.14.10
guix package: error:... propagated from guile-cairo@1.4.1
guix package: error:   second entry: cairo@1.14.10 
/gnu/store/nwxv9s2q8pi0m6gn6fyidpj8442dwp6f-cairo-1.14.10
guix package: error:... propagated from cairomm@1.12.2
hint: Try upgrading both `guile-cairo' and `cairomm', or remove one of them 
from the profile.
--8<---cut here---end--->8---

How does that sound?

We could further refine the hint to suggest using ‘guix package -m’,
though I’m not sure if it’d be a useful hint (it’s a useful
recommendation, but not necessarily good as a “fix hint.”)

Thoughts?

Thanks,
Ludo’.

diff --git a/guix/ui.scm b/guix/ui.scm
index 13cbe3a0f..660f6ea5c 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -502,6 +502,25 @@ interpreted."
   (x
(leave (G_ "unknown unit: ~a~%") unit)))
 
+(define (display-collision-resolution-hint collision)
+  (define (top-most-entry entry)
+(let loop ((entry entry))
+  (match (force (manifest-entry-parent entry))
+(#f entry)
+(parent (loop parent)
+
+  (let* ((first  (profile-collision-error-entry collision))
+ (second (profile-collision-error-conflict collision))
+ (name1  (manifest-entry-name (top-most-entry first)))
+ (name2  (manifest-entry-name (top-most-entry second
+(if (string=? name1 name2)
+(display-hint (format #f (G_ "You cannot have two different versions
+or variants of @code{~a} in the same profile.")
+  name1))
+(display-hint (format #f (G_ "Try upgrading both @code{~a} and @code{~a},
+or remove one of them from the profile.")
+  name1 name2)
+
 (define (call-with-error-handling thunk)
   "Call THUNK within a user-friendly error handler."
   (define (port-filename* port)
@@ -570,6 +589,7 @@ interpreted."
  (manifest-entry-output* conflict)
  (manifest-entry-item conflict))
(report-parent-entries conflict)
+   (display-collision-resolution-hint c)
(exit 1)))
 ((nar-error? c)
  (let ((file (nar-error-file c))

bug#29492: tests/guix-system.sh failure on unbound variable check

2017-11-30 Thread Ludovic Courtès 
Hi Eric,

Eric Bavier  skribis:

> Latest guix master (2cdf78df2d3d5d88c7e6908754233cf37cce1e61) fails 
> tests/guix-system.sh for me, on line 128.  This seems to be caused by the 
> fact that the error output contains a multi-character column number:
>
> ```
> /tmp/bavier/tmpfile:9:14: In procedure #:
> /tmp/bavier/tmpfile:9:14: GRUB-config: unbound variable
> hint: Did you forget a `use-modules' form?

I suppose that’s with Guile 2.0, right?

So the patch would become:

diff --git a/tests/guix-system.sh b/tests/guix-system.sh
index 4bb866adf..eaa0c4332 100644
--- a/tests/guix-system.sh
+++ b/tests/guix-system.sh
@@ -125,7 +125,8 @@ else
 	# See .
 	grep "$tmpfile:[49]:[0-9]: GRUB-config.*[Uu]nbound variable" "$errorfile"
 else
-	grep "$tmpfile:9:[0-9]: GRUB-config.*[Uu]nbound variable" "$errorfile"
+	# With Guile 2.0.14 the error is reported on line 14 (the last line).
+	grep "$tmpfile:9:[0-9]\+: GRUB-config.*[Uu]nbound variable" "$errorfile"
 fi
 fi
 

Please push if it works for you.

Thanks,
Ludo’.

bug#24279: Bug in xterm and/or fontconfig

2017-11-30 Thread Ludovic Courtès 
Hi Oleg,

Oleg Pykhalov  skribis:

> John Darrington  writes:
>
>> In GuixSD:
>>
>> guix package -i xterm strace
>> strace xterm
>>
>> xterm starts as it should,  however observe many failed calls similar to:
>>  
>> open("/gnu/store/b484nvn9nnr3ddclpz2fma9yxmimg2jj-fontconfig-2.11.94/lib/libXdmcp.so.6",
>>  O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>
>>
>> Now in the xterm, hold down Ctrl and press any mouse button.
>> The xterm aborts with the following messages:
>>  Warning: Unable to load any usable ISO8859 font
>>  Error: Aborting: no font found
>
> I solved this issue by:
>
>   - Install a font-misc-misc as Mike Hunt from Gentoo forum suggests¹:
>
> $ guix package -i font-misc-misc
>
>   - From "(guix) Application Setup"²:
>
> $ xset +fp ~/.guix-profile/share/fonts/X11/misc

Oh, good to know!

We can also fix this once and for all with this patch:

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 0da3397da..8f285b29a 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -113,6 +113,8 @@
 (file-append font-alias "/share/fonts/X11/100dpi")
 (file-append font-alias "/share/fonts/X11/misc")
 (file-append font-alias "/share/fonts/X11/cyrillic")
+(file-append font-misc-misc   ;default fonts for xterm
+ "/share/fonts/X11/misc")
 (file-append font-adobe75dpi "/share/fonts/X11/75dpi")))
 
 (define* (xorg-configuration-file #:key

That adds 4.1 MiB, but it saves user headaches, so I think it’s worth it.

I’ll go ahead and push that if there are no objections.

Thanks,
Ludo’.