bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Sarah Morgensen]

Hi all,

Ludovic Courtès  writes:

> Hello,
>
> Maxime Devos  skribis:
>
>> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
>>> Hi,
>>> 
>>> Maxime Devos  skribis:
>>> 
>>> > FAIL: stackoverflow1
>>> > 
>>> > 
>>> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>> > FAIL stackoverflow1 (exit status: 139)
>>> > 
>>> > FAIL: stackoverflow2
>>> > 
>>> > 
>>> > Starting recursion pass 1.
>>> > Stack overflow 1 missed.
>>> > FAIL stackoverflow2 (exit status: 1)
>>> 
>>> For now I worked around it by offloading this to a “real” machine
>>> (overdrive1), where it builds fine.  I wonder if there’s much we can do
>>> regarding QEMU’s behavior here.
>>
>> Maybe detect if QEMU is used, and if so, don't run the test suite?
>> Not really a ‘clean’ solution though, w.r.t. reproducibility,
>> and I wouldn't know how to detect this.
>
> Yeah, I’d rather avoid that.
>
>> If this is a bug in QEMU, then ideally that would be fixed in QEMU,
>> but I wouldn't know where to look.
>
> It could be that someone else on the intertubes stumbled upon that
> issue, that’d be great.  It could be that libsigsegv plays tricks that
> don’t fare well with QEMU’s expectations, as in
> .  We should ask
> on bug-libsigs...@gnu.org.
>
> Thanks,
> Ludo’.

(I just realized I never actually replied to this!)

Configuring with "--disable-stackvma" seems to fix this.  Doing this
makes libsigsegv use a different heuristic for determining if a SIGSEGV
was a stack overflow.  I don't think it should impact functionality.
Perhaps just apply that to aarch64 until there's a proper fix?

This is probably a QEMU bug... I will try to report this to upstream
QEMU when I can, as I can't find my notes on this right now.

--
Sarah

bug#50883: Suckless packages marked as 'x11' instead of 'expat'

[Sarah Morgensen]

Hello Guix,

It seems like some packages in suckless.scm are listed as having an
'x11' license when they are in fact 'expat' (as listed on
directory.fsf.org and confirmed by visual inspection).

I only checked three: dwm, dmenu, and st; but I suspect there are many
more.

(Perhaps at some point we should write a linter to check for potential
license discrepancies?)

--
Sarah

bug#34417: Ruby is not reproducible

[Sarah Morgensen]

Hello,

Julien Lepiller  writes:

> On current master, ruby-2.5.3 is not reproducible.
>
> The day of build (but not the time) is embedded in *.gemspec files, as
> well as in created.rid which also has some ordering issue. Other binary
> files differ in less trivial ways. I could not attach the output of
> diffoscope because it's 13 MB big!

Just an update on the state of this:

ruby@2.6.5 (default ruby) and ruby@2.7.4 are also not reproducible,
though ruby@3.0.2 is.

--
Sarah

bug#34064: openshot 2.4.3 works badly

[Sarah Morgensen]

Hello,

Thanks for the report.  Apologies it's taken so long for a reply!

 writes:

> openshot 2.4.3 under GuxSD works in an off hand way
>
> Note exactly this:
>
> 1 have lag when pull image from files list to a timeline - cursor just 
> becomes circle and program stops for 15 seconds. and after that openshot can
>  crash or can also perform image addition to a timeline
> 2 starts playing when cursor is on the start so ugly: waiting for 10 seconds 
> after pressing play and breaks audio in start time
> 3 sometimes it stops when move or edit images length on a timeline
>
> The worst bug is waiting 5secs and sound breaking when click 'play' on start 
> postition.
>
> I think should examine and improve openshot from guix repository.

Unfortunately, I'm not able to reproduce this with openshot 2.5.1 (on a
VM, even).

Can you still reproduce this?

--
Sarah

bug#23045: mysql_config missing references to sed and gawk

[Sarah Morgensen]

Fixed by .

--
Sarah

bug#33896: [PATCH 2/2] gnu: libblockdev: Fix inputs.

[Sarah Morgensen]

Add missing inputs; make util-linux a regular input since libblockdev
retains references to it.

* gnu/packages/disk.scm (libblockdev):
[inputs]: Add bcache-tools, e2fsprogs, gptfdisk, multipath-tools, ntfs-3g,
util-linux, and xfsprogs.
[native-inputs]: Remove util-linux.
---
 gnu/packages/disk.scm | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/disk.scm b/gnu/packages/disk.scm
index f3a7eb7617..a233db9433 100644
--- a/gnu/packages/disk.scm
+++ b/gnu/packages/disk.scm
@@ -951,26 +951,30 @@ to create devices with respective mappings for the 
ATARAID sets discovered.")
 (native-inputs
  `(("gobject-introspection" ,gobject-introspection)
("pkg-config" ,pkg-config)
-   ("python" ,python-wrapper)
-   ("util-linux" ,util-linux)))
+   ("python" ,python-wrapper)))
 (inputs
- `(("btrfs-progs" ,btrfs-progs)
+ `(("bcache-tools" ,bcache-tools)
+   ("btrfs-progs" ,btrfs-progs)
("cryptsetup" ,cryptsetup)
("dosfstools" ,dosfstools)
("dmraid" ,dmraid)
+   ("e2fsprogs" ,e2fsprogs)
("eudev" ,eudev)
("glib" ,glib)
+   ("gptfdisk" ,gptfdisk)
("kmod" ,kmod)
("libbytesize" ,libbytesize)
("libyaml" ,libyaml)
("lvm2" ,lvm2)
("mdadm" ,mdadm)
+   ("multipath-tools" ,multipath-tools)
("ndctl" ,ndctl)
("nss" ,nss)
+   ("ntfs-3g" ,ntfs-3g)
("parted" ,parted)
+   ("util-linux" ,util-linux)
("volume-key" ,volume-key)
-   ;; ("xfsprogs" ,xfsprogs) ; TODO: Package?
-   ))
+   ("xfsprogs" ,xfsprogs)))
 (home-page "https://github.com/storaged-project/libblockdev;)
 (synopsis "Library for manipulating block devices")
 (description
-- 
2.33.0

bug#33896: [PATCH 1/2] gnu: libblockdev: Embed executable paths.

[Sarah Morgensen]

Fixes <https://bugs.gnu.org/33896>.

* gnu/packages/disk.scm (libblockdev)[arguments]<#:phases>: Add
'patch-plugin-paths' phase.
---
 gnu/packages/disk.scm | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/disk.scm b/gnu/packages/disk.scm
index 7d6f3811dd..f3a7eb7617 100644
--- a/gnu/packages/disk.scm
+++ b/gnu/packages/disk.scm
@@ -21,6 +21,7 @@
 ;;; Copyright © 2021 Michael Rohleder 
 ;;; Copyright © 2021 Mathieu Othacehe 
 ;;; Copyright © 2021 Brice Waegeneire 
+;;; Copyright © 2021 Sarah Morgensen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -940,7 +941,13 @@ to create devices with respective mappings for the ATARAID 
sets discovered.")
(lambda* (#:key outputs #:allow-other-keys)
  (let ((out (assoc-ref outputs "out")))
   (substitute* "src/lib/blockdev.c"
-   (("/etc/libblockdev/conf.d/" path) (string-append out 
path)
+(("/etc/libblockdev/conf.d/" path) (string-append out 
path))
+ (add-after 'unpack 'patch-plugin-paths
+   (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* (find-files "src/plugins" "\\.c$")
+   (("(gchar \\*arg.+\\{\")([^\"]+)" all start program)
+;; XXX: Use 'search-input-file' when available.
+(string-append start (or (which program) program)
 (native-inputs
  `(("gobject-introspection" ,gobject-introspection)
("pkg-config" ,pkg-config)

base-commit: 69f37702dfcda776a190d5c40fad8518469ce3c4
-- 
2.33.0

bug#33659: Perl-build-system does not honor #:module-build-flags or #:configure-flags

[Sarah Morgensen]

Hello from three years in the future!

swedebu...@riseup.net writes:

> Hi
>
> I'm trying hard to package perl-term-readline-gnu but have failed so
> far. :D
>
> See the attached patch for my addition to perl-build-system that did not
> help.
>
> The Makefile in the source says:
>
> # Usage: perl Makefile.PL [--prefix=...] [--includedir=...]
> [--libdir=...]   
> #   [OPTIMIZE=...] 
>
> The build failure (with or without my modifications to the build-system)
> is:
>
> starting phase `configure'
> running `perl' with arguments ("Makefile.PL"
> "PREFIX=/gnu/store/w4wb4wd1kjj6gmxlix0i3jj47v0izijh-perl-term-readline-gnu-1.35"
> "INSTALLDIRS=site" "NO_PERLLOCAL=1")
> Could not find neither libtermcap.a, libncurses.a, or libcurses.
> Backtrace:
>4 (primitive-load "/gnu/store/vgfkdlnwks28vk50mg0xjl8iaf9…")
> In ice-9/eval.scm:
>191:35  3 (_ _)
> In srfi/srfi-1.scm:
> 640:9  2 (for-each # …)
> In
> /gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/gnu-build-system.scm:
>799:31  1 (_ _)
> In
> /gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/utils.scm:
> 616:6  0 (invoke _ . _)
>
> /gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/utils.scm:616:6:
> In procedure invoke:
> Throw to key `srfi-34' with args `(# "perl" arguments: ("Makefile.PL"
> "PREFIX=/gnu/store/w4wb4wd1kjj6gmxlix0i3jj47v0izijh-perl-term-rea\
> dline-gnu-1.35" "INSTALLDIRS=site" "NO_PERLLOCAL=1") exit-status: 1
> term-signal: #f stop-signal: #f] 80a8e60>)'.
> note: keeping build directory
> `/tmp/guix-build-perl-term-readline-gnu-1.35.drv-17'
> builder for
> `/gnu/store/n6dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv'
> failed with exit code 1
> build of
> /gnu/store/n6dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv
> failed
> View build log at
> '/var/log/guix/drvs/n6/dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv.bz2'.
> cannot build derivation
> `/gnu/store/pz0zrnpsvip0yxyd18cjazibsrlpf29h-youtube-viewer-cli-3.4.1.drv':
> 1 dependencies couldn't be built
> guix build: error: build failed: build of
> `/gnu/store/pz0zrnpsvip0yxyd18cjazibsrlpf29h-youtube-viewer-cli-3.4.1.drv'
> failed

I'm closing this old bug because the error was actually because ncurses
was not an input; see the working package definition (added last year):

  guix edit perl-term-readline-gnu

--
Sarah

bug#50787: rtl8812au-aircrack-ng-linux-module driver is empty

[Sarah Morgensen]

Hi,

Maxim Cournoyer  writes:

> Hello,
>
> On current master, it contains:
>
> tree 
> /gnu/store/28xapcdbk1v5zjsxpa16qvbnhr7cqcgd-rtl8812au-aircrack-ng-linux-module-5.6.4.2-5.b8167e6
> /gnu/store/28xapcdbk1v5zjsxpa16qvbnhr7cqcgd-rtl8812au-aircrack-ng-linux-module-5.6.4.2-5.b8167e6
> ├── lib
> │   └── modules
> └── share
> └── doc
> └── rtl8812au-aircrack-ng-linux-module-5.6.4.2-5.b8167e6
> └── LICENSE
>
> 5 directories, 1 file
>
> Needless to say, it doesn't work.
>
> Is this caused by a too new linux-libre kernel used?  If so, it'd be
> nicer to catch such problem at build time, rather than wondering why
> wifi no longer works after a reconfigure :-).
>
> Thanks,
>
> Maxim

According to the logs, it succesfully builds `88XXau.ko', so I think
something odd is happening in the install phase:

--8<---cut here---start->8---
starting phase `install'
make: Entering directory 
'/gnu/store/c04b4kkhcqzigq11sgyyqk17bp5ra6nd-linux-libre-module-builder-5.13.19/lib/modules/build'
arch/x86/Makefile:148: CONFIG_X86_X32 enabled but no binutils support
  DEPMOD  
/gnu/store/jpisxn26bgdrrb6kyc0si0aanlkq8f7r-rtl8812au-aircrack-ng-linux-module-5.6.4.2-5.b8167e6/lib/modules/5.13.19-gnu1
make: Leaving directory 
'/gnu/store/c04b4kkhcqzigq11sgyyqk17bp5ra6nd-linux-libre-module-builder-5.13.19/lib/modules/build'
phase `install' succeeded after 0.1 seconds
--8<---cut here---end--->8---

Hope that helps,
--
Sarah

bug#33325: xpra doesn't work out-of-the-box (implicit dependencies)

[Sarah Morgensen]

Hi,

I came across this old bug.

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> Hello Rutger and all,
>
> Our Xpra package seems to not be usable directly without installing
> additional items:
>
> $ guix environment --ad-hoc xpra --pure -- xpra start :100
> Warning: Xorg binary not found, assuming the wrapper is needed!
> Entering daemon mode; any further errors will be reported to:
>   /run/user/1000/xpra/:100.log
> $ cat /run/user/1000/xpra/:100.log
> 2018-11-09 14:37:42,986 Error: cannot enable SSH socket upgrades:
> 2018-11-09 14:37:42,986  No module named paramiko
> 2018-11-09 14:37:42,987 cannot access python uinput module:
> 2018-11-09 14:37:42,987  No module named uinput
> 2018-11-09 14:37:42,995 Error adding xauth entry for :100
> 2018-11-09 14:37:42,995  using command "xauth -f /home/ludo/.Xauthority add 
> :100 MIT-MAGIC-COOKIE-1 7c2c66d9295545cfb1c27b1109b4b54e":
> [mi] Extension "Composite" is not recognized
> 2018-11-09 14:37:42,995  [Errno 2] No such file or directory
> [mi] Only the following extensions can be run-time enabled:
> [mi]Generic Event Extension
> [mi]MIT-SHM
> [mi]XTEST
> [mi]XINERAMA
> [mi]XFIXES
> [mi]RENDER
> [mi]RANDR
> [mi]COMPOSITE
> [mi]DAMAGE
> [mi]MIT-SCREEN-SAVER
> [mi]DOUBLE-BUFFER
> [mi]RECORD
> [mi]DPMS
> [mi]X-Resource
> [mi]XVideo
> [mi]XVideo-MotionCompensation
> [mi]GLX
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
> No protocol specified
>
>
> On a foreign distro I see we’re also lacking a reference to
> ‘dbus-launch’:
>
> [courtes@devel13 ~]$ guix environment --ad-hoc xpra --pure -- xpra start :100
> Warning: Xorg binary not found, assuming the wrapper is needed!
> Entering daemon mode; any further errors will be reported to:
>   /run/user/10218/xpra/:100.log
> [courtes@devel13 ~]$ cat /run/user/10218/xpra/:100.log
> 2018-11-09 15:10:06,064 Error: cannot enable SSH socket upgrades:
> 2018-11-09 15:10:06,064  No module named paramiko
> 2018-11-09 15:10:06,066 cannot access python uinput module:
> 2018-11-09 15:10:06,066  No module named uinput
> 2018-11-09 15:10:06,079 Error adding xauth entry for :100
> 2018-11-09 15:10:06,080  using command "xauth -f /home/courtes/.Xauthority 
> add :100 MIT-MAGIC-COOKIE-1 9519cb23f6a348eda7f068d9317a664c":
> 2018-11-09 15:10:06,080  [Errno 2] No such file or directory
> [mi] Extension "Composite" is not recognized
> [mi] Only the following extensions can be run-time enabled:
> [mi]Generic Event Extension
> [mi]MIT-SHM
> [mi]XTEST
> [mi]XINERAMA
> [mi]XFIXES
> [mi]RENDER
> [mi]RANDR
> [mi]COMPOSITE
> [mi]DAMAGE
> [mi]MIT-SCREEN-SAVER
> [mi]DOUBLE-BUFFER
> [mi]RECORD
> [mi]DPMS
> [mi]X-Resource
> [mi]XVideo
> [mi]XVideo-MotionCompensation
> [mi]GLX
> 2018-11-09 15:10:06,472 Warning: some of the sockets are in an unknown state:
> 2018-11-09 15:10:06,473  /home/courtes/.xpra/devel13-100
> 2018-11-09 15:10:06,473  please wait as we allow the socket probing to timeout
> 2018-11-09 15:10:12,502 created unix domain socket: 
> /home/courtes/.xpra/devel13-100
> /gnu/store/rbrandv7anzjxqkr40d7fkanzssslk4b-bash-minimal-4.4.19/bin/sh: 
> dbus-launch: command not found
> dbus-launch failed to start using command 'dbus-launch --close-stderr':
>
>  exit code is 127
>
> Thoughts?
>
> Thanks in advance,
> Ludo’.

This command seems to work for me now (with xpra 4.2.1):

--8<---cut here---start->8---
$ guix environment --pure --ad-hoc xpra -- xpra start :100
Warning: using '/run/user/1001' as XDG_RUNTIME_DIR
Entering daemon mode; any further errors will be reported to:
  /run/user/1001/xpra/:100.log
$ guix environment --pure --ad-hoc xpra -- xpra list
Warning: using '/run/user/1001' as XDG_RUNTIME_DIR
Found the following xpra sessions:
/home/sarah/.xpra:
LIVE session at :100
/run/user/1001/xpra:
LIVE session at :100
--8<---cut here---end--->8---

And xpra now retains a reference to dbus, which has dbus_launch.

Can you still reproduce this?

--
Sarah

bug#32691: OpenMolcas

[Sarah Morgensen]

Hi Eric,

Eric Brown  writes:

>> On Sep 13, 2021, at 3:01 AM, Sarah Morgensen  wrote:
>> 
>> 
>> Thanks for all your work on this package.  Did you ever make further
>> progress on this?  Are you still interested in working on getting
>> OpenMolcas in Guix?
>> 
>> —
>> Sarah
>
> Hi Sarah,
>
> I have made a new port from scratch, which I am testing currently.  It can be 
> found here:
>
> (channel
>  (name 'ecbrown-guix)
>  (url "https://ericcbrown.com/ecbrown/ecbrown-guix.git;)
>  (introduction
>   (make-channel-introduction
>"72e02daa4cf59a5e591387e299729f2509128b58"
>(openpgp-fingerprint
> "AA5F 523D FD6D 0478 8505 6A7D C1D5 F8F0 85BF 4CF3"
>
> I would appreciate any help that you might provide!
>
> Best regards,
> Eric

I'm glad to see that you've continued to work on this!

I took a look at your definition and the package it builds, and I'll
start with two things:

Syntactically, you can do something like this in your extra phase:

  (let* ((out (assoc-ref outputs "out"))
 (share (string-append out "/share/openmolcas")))

  (mkdir-p share)
  (for-each
(lambda (file)
  (rename-file file (string-append share "/" file)))
'("LICENSE" "data" ...))

and to symlink (like you allude to in the phase name):

  (symlink target name)

Looking at the actual package, it looks like there are several ".exe"
executables (which are actually ELF and runnable on Linux?) along with
matching ".prgm" files which (it looks like) are required to load and
run the executables.  Are these part of OpenMolcas itself, or are they
examples or something?  It would be best if we can avoid putting
architecture-specific files (that is, executables) in "/share".

Finally, rather than propagating python inputs, we can probably use the
'wrap' phase from python-build-system.  Adding that is a bit more
complex, but you can look at the 'nncp' package for an example of how
this is done (it uses gnu-build-system, but takes phases from
go-build-system).

Okay, that was three things, but what can you do? :)

--
Sarah

bug#32167: Kernel 'build' directory in the store is a broken symbolic link

[Sarah Morgensen]

Hi all,

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

> Hi,
>
> Mark H Weaver  skribis:
>
>> Danny Milosavljevic  writes:
>>
>>> On Mon, 16 Jul 2018 18:55:11 +0100 (BST)
>>>  wrote:
>>>
 It would be good to keep the build directory though, since it's
 expected to exist, and it's easier to just download a module's
 source and compile it and test it.
>>>
>>> I agree.
>>>
>>> /run/booted-system/kernel/lib/modules/4.17.3-gnu is in the store
>>> anyway so it will be seen by the GC.
>>>
>>> The fix would be in linux-libre.
>>
>> If we were to preserve the kernel build directory as a store item, and
>> keep a link from the modules directory to the build directory, that
>> would greatly increase the size of the most minimal system that users
>> could build.
>
> Yeah, we shouldn’t do that IMO.
>
>> If the intent here is to allow support for out-of-tree kernel modules,
>> then fixing these symlinks would not solve the problem, and it's not
>> clear to me that fixing them would be part of a proper solution on
>> GuixSD.  GuixSD is not a system where you can simply compile a kernel
>> module manually and install it, because our module directory is
>> immutable.  If the goal is to support building out-of-tree kernel
>> modules, that's a separate discussion that deserves its own "wishlist"
>> bug report, I think.
>
> I agree.
>
> Ludo’.

I am closing this old bug since the broken 'build' symlink no longer
exists (nor do any other broken symlinks, as far as I can tell).

As for building out-of-tree kernel modules, we now have
linux-module-build-system, which uses `make-linux-module-builder', which
builds the 'build' directory straight from the linux source with `make
modules_prepare'.  There are some improvements to be had there, for
sure, but like mentioned above, that deserves its own wishlist item.

--
Sarah

bug#31779: gitweb PERL5LIB needs to include Perl version subdirectory

[Sarah Morgensen]

Hello Ricardo,

I found this old bug...

Ricardo Wurmus  writes:

> The “git” package provides “gitweb”, which is wrapped in PERL5LIB.
> Gitweb has broken some time ago and now fails with an error about CGI.pm
> not being found.
>
> The reason seems to be that the Perl version sub-directory is not
> searched for CGI.pm.  The directory that gitweb.cgi is wrapped with
> stops at “site_perl”, but it really should be “site_perl/5.26.1”.
>
> --
> Ricardo

While the value of PERL5LIB hasn't changed, I am able to run

  git instaweb --httpd=lighttpd

and access the gitweb interface from there.  Can you still reproduce
this?

--
Sarah

bug#31663: dino: segfaults on message delivery since libsignal-protocol-c update

[Sarah Morgensen]

Hello Mark,

Mark H Weaver  writes:

> The update of 'libsignal-protocol-c' to 2.3.2 in commit
> 05ca7a916a54d32ae4603bcd90918fb19e907704 broke dino.  Since that update,
> dino now immediately segfaults whenever a message is sent or received
> using OMEMO.
>
> Note that upstream dino has its own copy of 'libsignal-protocol-c' in a
> submodule.  Our 'dino' package arranges to instead use our system copy
> of 'libsignal-protocol-c', and I'm glad for that.  Unfortunately, it no
> longer works.
>
> I tried updating 'dino' to the latest upstream commit
> (60982bff67809e62b43476b49e30a9bd37491930), but that didn't help.
>
>   Mark

It looks like this since got an upstream issue [0] and was fixed in dino
in 7012023d599 (around v0.1), so I'm closing this old bug.  (I also
verified that our dino version wants v2.3.3 of libsignal-protocol-c,
which is what we have.)  Please reopen if this is still an issue!

[0] https://github.com/dino/dino/issues/485

--
Sarah

bug#31652: Use of ‘keymap’ vs. ‘layout’ in manual

[Sarah Morgensen]

Hello all,

I found this old bug...

Ricardo Wurmus  writes:

> Alex Kost  writes:
>
>> Tobias Geerinckx-Rice (2018-05-30 05:49 +0200) wrote:
>>
>>> Guix,
>>>
>>> Grepping the manual for ‘keyboard layout’ will get you to section
>>> 6.1.4.1 (setting the layout temporarily during installation using
>>> loadkeys), but not 6.2.7.1 where you might learn about using
>>> console-keymap-service to make the change permanent.
>>>
>>> This bug is a reminder to myself to replace at least one occurrence of
>>> ‘keymap’ with the common term.
>>
>> Do you mean ‘layout’ is the common term?  "man loadkeys" mentions
>> "layout" only once, and "keymap" a lot.
>>
>> I think we can just put a reference to that section.  Maybe like this:
>>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index 09749b15e..02425e791 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -8418,7 +8418,9 @@ loadkeys dvorak
>>  
>>  See the files under @file{/run/current-system/profile/share/keymaps} for
>>  a list of available keyboard layouts.  Run @command{man loadkeys} for
>> -more information.
>> +more information.  After installing GuixSD, you can set your default
>> +keyboard layout with @code{console-keymap-service} (@pxref{Base
>> +Services}).
>>  
>>  @subsubsection Networking
>
> This is fine.  We should also consider adding more @cindex entries to
> cover all terms that people might search for.  The index should guide
> people to the relevant places in the manual.

However, it seems the manual now primarily uses "keyboard layout" with
an entry in the index for "keymap".  This seems to resolve the original
issue, so I'm closing this bug.  Please reopen if this was in error.

Note also that when there is alternate terminology, you can use

  @cindex keymap @seeentry{keyboard layout}

to put a single entry in the index which says

  keymap: see keyboard layout

See (texinfo)Advanced Indexing for more info :)

--
Sarah

bug#35350: Some compile output still leaks through with --verbosity=1

[Sarah Morgensen]

Hello,

I encountered this issue today.  This looks like a pretty complete
solution ready to go.  Did this ever make it into Guile/Guix?

(Ironically I was also reaching for a "make-custom-textual-output-port"
the other day!)

--
Sarah

Mark H Weaver  writes:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
>> Mark H Weaver  skribis:
>>
>>> Ludovic Courtès  writes:
>>
>> [...]
>>
 So there are two things.  To fix the issue you reported (build output
 that goes through), I think we must simply turn off UTF-8 decoding from
 ‘process-stderr’ and leave that entirely to ‘build-event-output-port’.
>>>
>>> Can we assume that UTF-8 is the appropriate encoding for
>>> (current-build-output-port)?  My interpretation of the Guix manual entry
>>> for 'current-build-output-port' suggests that the answer should be "no".
>>
>> What goes to ‘current-build-output-port’ comes from builds processes.
>> It’s usually UTF-8 but it can be anything, including binary garbage,
>> which should be gracefully handled.
>>
>> That’s why ‘process-stderr’ currently uses ‘read-maybe-utf8-string’.
>
> I agree that we should (permissively) interpret the build process output
> as UTF-8, regardless of locale settings.  However, the encoding of
> 'current-build-output-port' is orthogonal, and I see no reason to assume
> that it's UTF-8.
>
> As 'process-stderr' is currently implemented, it makes no assumptions
> about the encoding of 'current-build-output-port'.  That's because it
> uses only textual I/O on it.  The end result is that the UTF-8 build
> output is effectively converted into the port encoding of
> 'current-build-output-port', whatever it might be.  I think that's how
> it should be, no?
>
>>> Also, in your previous message you wrote:
>>>
>>>   The problem is the first layer of UTF-8 decoding that happens in
>>>   ‘process-stderr’, in the ‘%stderr-next’ case.  We would need to
>>>   disable it, but only if the build output port is
>>>   ‘build-event-output-port’ (i.e., it’s capable of interpreting
>>>   “multiplexed build output” correctly.)
>>>
>>> It sounds like you're suggesting that 'process-stderr' should look to
>>> see if (current-build-output-port) is a 'build-event-output-port', and
>>> in that case it should use binary I/O primitives to write raw binary
>>> data to it, otherwise it should use text I/O primitives and write
>>> characters to it.  Do I understand correctly?
>>
>> Yes.  (Actually, rather than guessing if (current-build-output-port) is
>> a ‘build-event-output-port’, there could be a fluid to ask for the use
>> of raw binary primitives.)
>>
>>> IMO, it would be cleaner to treat 'build-event-output-port' uniformly,
>>> and specifically as a textual port of unknown encoding.
>>
>> (You mean ‘current-build-output-port’, right?)
>
> Yes, indeed.
>
>> I think you’re right.  I’m not yet entirely sure what the implications
>> are.  There’s a couple of tests in tests/store.scm for UTF-8
>> interpretation that describe behavior that I think we should preserve.
>
> I certainly agree that we should preserve those tests.  I would go
> further and add two more tests that bind 'current-build-output-port' to
> a port with a non-UTF-8 encoding (e.g. UTF-16) and verify that the λ
> gets converted correctly.  The test build process would output the λ as
> UTF-8, but it should be written to 'current-build-output-port' as
> e.g. UTF-16.
>
> What do you think?
>
>>> I would suggest changing 'build-event-output-port' to create an R6RS
>>> custom *textual* output port, so that it wouldn't have to worry about
>>> encodings at all, and it would only be given whole characters.
>>> Internally, it would be doing exactly what you suggest above, but those
>>> details would be encapsulated within the custom textual port.
>>>
>>> However, I don't think we can use Guile's current implementation of R6RS
>>> custom textual output ports, which are currently built on Guile's legacy
>>> soft ports, which I suspect have a similar bug with multibyte characters
>>> sometimes being split (see 'soft_port_write' in vports.c).
>>>
>>> Having said all of this, my suggestions would ultimately entail having
>>> two separate places along the stderr pipeline where 'utf8->string!'
>>> would be used, and maybe that's too much until we have a more optimized
>>> C implementation of it.
>>
>> Yeah it looks like we don’t yet have custom textual output ports that we
>> could rely on, do we?
>>
>> I support your work to add that in Guile proper!
>
> For now, I can offer a new implementation of custom textual output ports
> built upon custom binary ports and the 'utf8->string!' that I previously
> sent.  See attached.
>
>  Thanks,
>Mark
>
> GNU Guile 2.2.4
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> 

bug#27372: GRUB 2.02 hangs on pre-UEFI Dell Poweredge 2950

[Sarah Morgensen]

Hi Ludo,

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

> Hello,
>
> GRUB as found in the 0.13.0 installation image hangs after printing the
> four letters “GRUB” in console mode on a pre-UEFI Dell Poweredge 2950
> server (something that’s roughly ten years old.)
>
> I built an image where GRUB’s graphical terminal output was disabled:
>
>   (grub-configuration
> (device "/dev/sda")
> (terminal-outputs '(console)))
>
> … but that didn’t help.
>
> Conversely, Debian’s ‘grub-pc’ 2.02~beta3-5 package doesn’t have this
> problem.   Debian’s ‘grub.cfg’ prologue is similar to ours so I suspect
> the problem is in GRUB itself.  Debian has “quite a few” patches for
> GRUB though:
> .
>
> Has anyone experienced this?
>
> Thanks,
> Ludo’.

Given that we're past v1.3.0 now, is this still relevant?

Thanks,
--
Sarah

bug#50493: Update go-build-system to use Go 1.17.

[Sarah Morgensen]

Hello,

Apologies it's taken so long for a proper response!

>> 2. Make some much-needed improvements to go-build-system [2]:
>> 
>> * replace the *slow* phase 'remove-go-references with -trimpath option
>> 
>> * avoid building a directory union of Go inputs (and then copying it!)
>
> Are these required to use 1.17? I agree they are important problems to
> fix but we shouldn't let them block the upgrade.

You're right.  I've gone ahead and sent a patch series to this bug which
rolls the cache, docker, and the update all together.

I've added one more blocker: #50688 [0], which is a dependency of chezmoi.

This should just leave #49921, the aarch64 issue, then this is patch is
ready to go.  With the patch from #50688, I was to build out all
dependents listed by `guix refresh -l go' (about 900).

Thanks for sticking with this! :)

[0] https://issues.guix.gnu.org/50688

--
Sarah

bug#50493: [PATCH 4/4] build-system/go: Use go-1.17 by default.

[Sarah Morgensen]

Build all Go packages with go-1.17 by default.  Explicitly specify an
older Go version in packages which cannot build with go-1.17.

* gnu/packages/golang.scm (go): Update from 'go-1.14' to 'go-1.17'.
* gnu/packages/docker.scm (docker)[native-inputs]: Explicitly use
'go-1.14'.
* gnu/packages/ipfs.scm (go-ipfs)[arguments]: Set #:go to 'go-1.16'.
(go-github-com-ipfs-go-ipfs-cmdkit-files)[arguments]: Likewise.
---
 gnu/packages/docker.scm | 2 +-
 gnu/packages/golang.scm | 2 +-
 gnu/packages/ipfs.scm   | 6 --
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/docker.scm b/gnu/packages/docker.scm
index 8bac1b89ce..fa666cbb04 100644
--- a/gnu/packages/docker.scm
+++ b/gnu/packages/docker.scm
@@ -594,7 +594,7 @@ (define-public docker
("xz" ,xz)))
 (native-inputs
  `(("eudev" ,eudev)  ; TODO: Should be propagated by lvm2 (.pc -> .pc)
-   ("go" ,go)
+   ("go" ,go-1.14)
("gotestsum" ,gotestsum)
("pkg-config" ,pkg-config)))
 (synopsis "Docker container component library, and daemon")
diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 19f1ef37d5..d1ed30455c 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -790,7 +790,7 @@ (define-public go-1.17
   "README.md" "SECURITY.md"
 (inputs (alist-delete "gcc:lib" (package-inputs go-1.16)
 
-(define-public go go-1.14)
+(define-public go go-1.17)
 
 (define-public (make-go-std go)
   "Return a package which builds the standard library for Go compiler GO."
diff --git a/gnu/packages/ipfs.scm b/gnu/packages/ipfs.scm
index 57701991e3..8d5b4f1767 100644
--- a/gnu/packages/ipfs.scm
+++ b/gnu/packages/ipfs.scm
@@ -46,7 +46,8 @@ (define-public go-github-com-ipfs-go-ipfs-cmdkit-files
   "0qk6fshgdmhp8dip2ksm13j6nywi41m9mn0czkvmw6b697z85l2r"
   (build-system go-build-system)
   (arguments
-   '(#:unpack-path "github.com/ipfs/go-ipfs-cmdkit"
+   `(#:go ,go-1.16
+ #:unpack-path "github.com/ipfs/go-ipfs-cmdkit"
  #:import-path "github.com/ipfs/go-ipfs-cmdkit/files"))
   (home-page "https://github.com/ipfs/go-ipfs-cmdkit;)
   (synopsis "Shared types, functions and values for go-ipfs")
@@ -226,7 +227,8 @@ (define-public go-ipfs
(file-name (string-append name "-" version "-source"
 (build-system go-build-system)
 (arguments
- '(#:unpack-path "github.com/ipfs/go-ipfs"
+ `(#:go ,go-1.16
+   #:unpack-path "github.com/ipfs/go-ipfs"
#:import-path "github.com/ipfs/go-ipfs/cmd/ipfs"
#:phases (modify-phases %standard-phases
   (add-before 'reset-gzip-timestamps 'make-files-writable
-- 
2.33.0

bug#50493: [PATCH 2/4] build-system/go: Initialize build cache from input packages.

[Sarah Morgensen]

* guix/build/go-build-system.com (setup-go-environment): Set GOCACHE to
a location within the build directory.  Union "/var/cache/go/build"
input directories to initialize the cache.  Generate "trim.txt" within
the cache, with the current time.
---
 guix/build/go-build-system.scm | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/guix/build/go-build-system.scm b/guix/build/go-build-system.scm
index 645d2fe680..9f249b0777 100644
--- a/guix/build/go-build-system.scm
+++ b/guix/build/go-build-system.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2020 Jack Hill 
 ;;; Copyright © 2020 Jakub Kądziołka 
 ;;; Copyright © 2020, 2021 Efraim Flashner 
+;;; Copyright © 2021 Sarah Morgensen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -138,9 +139,28 @@ (define* (setup-go-environment #:key inputs outputs goos 
goarch #:allow-other-ke
 where executables (\"commands\") are installed to.  This phase is sometimes 
used
 by packages that use (guix build-system gnu) but have a handful of Go
 dependencies, so it should be self-contained."
-  ;; The Go cache is required starting in Go 1.12.  We don't actually use it 
but
-  ;; we need it to be a writable directory.
-  (setenv "GOCACHE" "/tmp/go-cache")
+  (define (search-input-directories dir)
+(filter directory-exists?
+(map (match-lambda
+   ((name . directory)
+(string-append directory "/" dir)))
+ inputs)))
+
+  ;; Seed the Go build cache with the build caches from input packages.
+  (let ((cache (string-append (getcwd) "/go-build")))
+(setenv "GOCACHE" cache)
+(union-build cache
+ (search-input-directories "/var/cache/go/build")
+ ;; Creating all directories isn't that bad, because there are
+ ;; only ever 256 of them.
+ #:create-all-directories? #t
+ #:log-port (%make-void-port "w"))
+
+;; Tell Go that the cache was recently trimmed, so it doesn't try to.
+(call-with-output-file (string-append cache "/trim.txt")
+  (lambda (port)
+(format port "~a" (current-time)
+
   ;; Using the current working directory as GOPATH makes it easier for 
packagers
   ;; who need to manipulate the unpacked source code.
   (setenv "GOPATH" (getcwd))
-- 
2.33.0

bug#50493: [PATCH 3/4] build-system/go: Add pre-built standard library as implicit input.

[Sarah Morgensen]

* gnu/packages/golang.scm (make-go-std): New procedure.
* guix/build-system/go.scm (make-go-std): New procedure.
(lower): Use it.  Add pre-built standard library to inputs.
---
 gnu/packages/golang.scm  | 30 ++
 guix/build-system/go.scm | 16 ++--
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index f02d0aa9df..19f1ef37d5 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -792,6 +792,36 @@ (define-public go-1.17
 
 (define-public go go-1.14)
 
+(define-public (make-go-std go)
+  "Return a package which builds the standard library for Go compiler GO."
+  (package
+(name (string-append (package-name go) "-std"))
+(version (package-version go))
+(source #f)
+(build-system go-build-system)
+(arguments
+ `(#:import-path "std"
+   #:build-flags `("-pkgdir" "pkg") ; "Install" to build directory.
+   #:allow-go-reference? #t
+   #:substitutable? #f ; Faster to build than download.
+   #:tests? #f ; Already tested in the main Go build.
+   #:go ,go
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'unpack)
+ (replace 'install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(out-cache (string-append out "/var/cache/go/build")))
+   (copy-recursively (getenv "GOCACHE") out-cache)
+   (delete-file (string-append out-cache "/trim.txt"))
+   (delete-file (string-append out-cache "/README")
+ (delete 'install-license-files
+(home-page (package-home-page go))
+(synopsis "Cached standard library build for Go")
+(description (package-description go))
+(license (package-license go
+
 (define-public go-0xacab-org-leap-shapeshifter
   (let ((commit "0aa6226582efb8e563540ec1d3c5cfcd19200474")
 (revision "12"))
diff --git a/guix/build-system/go.scm b/guix/build-system/go.scm
index 8aa065c4ff..a579477500 100644
--- a/guix/build-system/go.scm
+++ b/guix/build-system/go.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2017 Leo Famulari 
 ;;; Copyright © 2020 Jakub Kądziołka 
 ;;; Copyright © 2021 Efraim Flashner 
+;;; Copyright © 2021 Sarah Morgensen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -109,6 +110,9 @@ (define (default-go)
   (let ((go (resolve-interface '(gnu packages golang
 (module-ref go 'go)))
 
+(define (make-go-std)
+  (module-ref (resolve-interface '(gnu packages golang)) 'make-go-std))
+
 (define* (lower name
 #:key source inputs native-inputs outputs system target
 (go (default-go))
@@ -118,6 +122,14 @@ (define* (lower name
   (define private-keywords
 '(#:source #:target #:go #:inputs #:native-inputs))
 
+  (define inputs-with-cache
+;; XXX: Avoid a circular dependency.  This should be rewritten with
+;; 'package-mapping' or similar.
+(let ((go-std-name (string-append (package-name go) "-std")))
+  (if (string-prefix? go-std-name name)
+  inputs
+  (cons `(,go-std-name ,((make-go-std) go)) inputs
+
   (bag
 (name name)
 (system system)
@@ -127,7 +139,7 @@ (define* (lower name
 '())
  ,@`(("go" ,go))
  ,@native-inputs
- ,@(if target '() inputs)
+ ,@(if target '() inputs-with-cache)
  ,@(if target
  ;; Use the standard cross inputs of
  ;; 'gnu-build-system'.
@@ -135,7 +147,7 @@ (define* (lower name
  '())
  ;; Keep the standard inputs of 'gnu-build-system'.
  ,@(standard-packages)))
-(host-inputs (if target inputs '()))
+(host-inputs (if target inputs-with-cache '()))
 
 ;; The cross-libc is really a target package, but for bootstrapping
 ;; reasons, we can't put it in 'host-inputs'.  Namely, 'cross-gcc' is a
-- 
2.33.0

bug#50493: [PATCH 1/4] build-system/go: Add #:substitutable? argument.

[Sarah Morgensen]

* guix/build-system/go.scm (go-build): Add 'substitutable?' argument.
(go-cross-build): Likewise.
---
 guix/build-system/go.scm | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/guix/build-system/go.scm b/guix/build-system/go.scm
index 4c1a732107..8aa065c4ff 100644
--- a/guix/build-system/go.scm
+++ b/guix/build-system/go.scm
@@ -169,7 +169,8 @@ (define* (go-build store name inputs
(imported-modules %go-build-system-modules)
(modules '((guix build go-build-system)
   (guix build union)
-  (guix build utils
+  (guix build utils)))
+   (substitutable? #t))
   (define builder
`(begin
   (use-modules ,@modules)
@@ -211,6 +212,7 @@ (define* (go-build store name inputs
 #:system system
 #:modules imported-modules
 #:outputs outputs
+#:substitutable? substitutable?
 #:guile-for-build guile-for-build))
 
 (define* (go-cross-build store name
@@ -234,7 +236,8 @@ (define* (go-cross-build store name
  (imported-modules %go-build-system-modules)
  (modules '((guix build go-build-system)
 (guix build union)
-(guix build utils
+(guix build utils)))
+ (substitutable? #t))
   "Cross-build NAME using GO, where TARGET is a GNU triplet and with INPUTS."
   (define builder
 `(begin
@@ -303,6 +306,7 @@ (define* (go-cross-build store name
   #:inputs (append native-drvs target-drvs)
   #:outputs outputs
   #:modules imported-modules
+  #:substitutable? substitutable?
   #:guile-for-build guile-for-build))
 
 (define go-build-system
-- 
2.33.0

bug#50493: [PATCH staging 0/4] build-system/go: Use go-1.17 by default.

[Sarah Morgensen]

Hello Guix,

This patch series updates the Go build system to use Go 1.17 by default.

As a necessity, because go-1.17 no longer contains its own pre-compiled
standard library, an implicit input is added to the build system which
contains the build cache from building the standard library with the
go-build-system.  (This way, we can always guarantee that the cache is valid
because it's built with the same flags as the build system.)  The build system
is also modified to make use of this cache.

(We use the build cache rather than archives because the Go project is moving
away from archives towards an authoritative build cache.)

Three packages are modified to keep using an older Go:

* docker now explicitly uses go-1.14

* go-ipfs and go-github-com-go-ipfs-cmdkit-files now explitly use go-1.16
(go-ipfs and gx badly need to be upgraded!)

There are about 900 dependent packages according to `guix refresh -l go', but
I don't know how many are leaf packages, so I marked this for staging.  The
actual series is based on master because go-1.17 is only present in master.

I have built them all out successfully on x86_64.

Sarah Morgensen (4):
  build-system/go: Add #:substitutable? argument.
  build-system/go: Initialize build cache from input packages.
  build-system/go: Add pre-built standard library as implicit input.
  build-system/go: Use go-1.17 by default.

 gnu/packages/docker.scm|  2 +-
 gnu/packages/golang.scm| 32 +++-
 gnu/packages/ipfs.scm  |  6 --
 guix/build-system/go.scm   | 24 
 guix/build/go-build-system.scm | 26 +++---
 5 files changed, 79 insertions(+), 11 deletions(-)


base-commit: a640ee7da3311e4fa560c7163d2dd7d24a25585a
-- 
2.33.0

bug#50595: Faliure in guix import go

[Sarah Morgensen]

Hi,

Ludovic Courtès  writes:

> I went ahead and pushed these two patches on your behalf (after adding a
> reference to this bug):
>
>   281ede2e7d * import: go: Match "go-import" meta tags anywhere.
>   b3907e304d * import: go: Improve handling of modules in VCS subdirectories.

Thanks (that was quick)!

> Should we close this bug now, Sarah?

Yes; I've closed it now.

If anyone has some time and free disk space, you might try importing
something which brings in complicated repos like AWS, and see if
anything else falls out.  Perhaps try github.com/cloudfoundry/cli?  I've
tried that one before and it was a mess.

--
Sarah

bug#50665: Docker 19.03 is no longer receiving updates.

[Sarah Morgensen]

Hello Guix,

Docker 19.03 (the version we have) is expected to receive no further
updates [0], and currently depends on Go 1.14 to build, which has also
reached EOL.

Is anyone up to the task of updating the Docker behemoth?

[0] https://github.com/moby/moby/pull/41381#issuecomment-876982431

--
Sarah

bug#50595: Failure in guix import go

[Sarah Morgensen]

Hello,

Stephen Paul Weber  writes:

> Getting a similar failure here:
>
> $ guix import go github.com/cncf/udpa/go/
>
> following redirection to 
> `https://proxy.golang.org/github.com/cncf/udpa/go/@v/list'...
> following redirection to 
> `https://proxy.golang.org/github.com/cncf/udpa/go/@latest'...
> following redirection to 
> `https://proxy.golang.org/github.com/cncf/udpa/go/@v/v0.0.0-20210322005330-6414d713912e.mod'...
> guix import: warning: Failed to import package "github.com/cncf/udpa/go/".
> reason: ("vector-ref" "Wrong type argument in position 1 (expecting vector): 
> ~S" (#f) (#f)).
> guix import: error: failed to download meta-data for module 
> 'github.com/cncf/udpa/go/'

This one seems to be caused by the importer incorrectly using the
repository root instead of the module path in a couple places.  The
attached patch fixes this.

Hope that helps,
--
Sarah

>From b9ef64a641c20d331cf1886d71b85b81be910b30 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Sarah Morgensen 
Date: Thu, 16 Sep 2021 18:24:40 -0700
Subject: [PATCH] import: go: Improve handling of modules in VCS
 subdirectories.

Use the supplied module path (instead of the repository root) as the import
path for everything except source and homepage URLs.  For modules not in the
root of a VCS repository, set #:unpack-path to the repository root by default.

* guix/import/go.scm (go-module->guix-package): Use 'module-path'
instead of 'root-module-path' for #:import-path.  Emit #:unpack-path
when #:import-path is not equal to 'root-module-path'.
---
 guix/import/go.scm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index c6ecdbaffd..fe7387dec2 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -619,7 +619,7 @@ hint: use one of the following available versions ~a\n"
  (meta-data (fetch-module-meta-data root-module-path))
  (vcs-type (module-meta-vcs meta-data))
  (vcs-repo-url (module-meta-data-repo-url meta-data goproxy))
- (synopsis (go-package-synopsis root-module-path))
+ (synopsis (go-package-synopsis module-path))
  (description (go-package-description module-path))
  (licenses (go-package-licenses module-path)))
 (values
@@ -630,7 +630,10 @@ hint: use one of the following available versions ~a\n"
  ,(vcs->origin vcs-type vcs-repo-url version*))
 (build-system go-build-system)
 (arguments
- '(#:import-path ,root-module-path))
+ '(#:import-path ,module-path
+   ,@(if (string=? module-path root-module-path)
+ '()
+ `(#:unpack-path ,root-module-path
 ,@(maybe-propagated-inputs
(map (match-lambda
   ((name version)

base-commit: 72297993a174586ee0a23b95b6b9ee2f3db34cf1
--
2.33.0

bug#50595: Faliure in guix import go

[Sarah Morgensen]

Hello,

Thanks for your report!

Stephen Paul Weber  writes:

> $ guix import go -r bdd.fi/x/runitor
>
> guix import: warning: Failed to import package "bdd.fi/x/runitor".
> reason: ("struct-vtable" "Wrong type argument in position 1 (expecting 
> struct): ~S" (#f) (#f)).

It seems this is occurring because "https://bdd.fi/x/runitor?go-get=1;
does not have the

  

tag in the  element, as the Go spec requires (it's a direct child
of the  element).  However, it seems fairly harmless to relax this
requirement in our importer, so the following patch should fix this.

>From ca17299a3011171d6889202003d1e888b22303ec Mon Sep 17 00:00:00 2001
Message-Id: 
From: Sarah Morgensen 
Date: Thu, 16 Sep 2021 18:27:09 -0700
Subject: [PATCH] import: go: Match "go-import" meta tags anywhere.

Some personal sites forget to put  in a
 element, so look anywhere for them.

* guix/import/go.scm (fetch-module-meta-data): Match "go-import" meta
tags anywhere in the page.
---
 guix/import/go.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index dad007d511..43abe004b3 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -480,7 +480,7 @@ build a package."
  (strip-.git-suffix/maybe repo-url)
   ;; 
   (let* ((meta-data (http-fetch* (format #f "https://~a?go-get=1; module-path)))
- (select (sxpath `(// head (meta (@ (equal? (name "go-import"
+ (select (sxpath `(// (meta (@ (equal? (name "go-import"
   // content
 (match (select (html->sxml meta-data #:strict? #t))
   (() #f)   ;nothing selected

base-commit: 72297993a174586ee0a23b95b6b9ee2f3db34cf1
--
2.33.0

bug#33615: xonsh build failure

[Sarah Morgensen]

Hello,

Danny Milosavljevic  writes:

> xonsh-0.6.2/
> [...]
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/parser.py", line 
> 10,
>  in Parser
> from xonsh.parsers.v36 import Parser as p
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/parsers/v36.py", 
> lin
> e 4, in 
> from xonsh.parsers.v35 import Parser as ThreeFiveParser
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/parsers/v35.py", 
> lin
> e 4, in 
> from xonsh.parsers.base import BaseParser
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/parsers/base.py", 
> li
> ne 18, in 
> from xonsh.lexer import Lexer, LexToken
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/lexer.py", line 
> 16, 
> in 
> from xonsh.tokenize import (OP, IOREDIRECT, STRING, DOLLARNAME, NUMBER,
>   File "/tmp/guix-build-xonsh-0.6.2.drv-0/xonsh-0.6.2/xonsh/tokenize.py", 
> line 5
> 7, in 
> ASYNC = token.ASYNC
> AttributeError: module 'token' has no attribute 'ASYNC'

The updated version (0.9.27) we have builds fine now, so I'm closing this old
bug.

--
Sarah

bug#33609: fortune-mod build (test) failure

[Sarah Morgensen]

Hi,

Pierre Neidhardt  writes:

> I've pushed 6185732390003ca36a730231bb6280b68c37ee8e which skips the
> valgrind test.  This is not ideal but better than having a broken
> package.
>
> Upstream has https://github.com/shlomif/fortune-mod/issues/21 which
> could be related.

This seems to be fixed now.  I've attached a patch below to reenable it.

It could probably do with an update, too.  It now vendors 'rinutils'
(which we already have as an input) so that would need to be removed.

--
Sarah

>From 5aa332afa3f624ecab54ffd411026700b0d0dfb8 Mon Sep 17 00:00:00 2001
Message-Id: <5aa332afa3f624ecab54ffd411026700b0d0dfb8.1631594857.git.iskar...@mgsn.dev>
From: Sarah Morgensen 
Date: Mon, 13 Sep 2021 21:40:43 -0700
Subject: [PATCH] gnu: fortune-mod: Re-enable test.

Re-enable the valgrind test, fixed in a previous version update.

* gnu/packages/games.scm (fortune-mod)[arguments]<#:phases>
{fix-build-env}: Re-enable test.
---
 gnu/packages/games.scm | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index a2f756e3a7..4236560143 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -7633,11 +7633,7 @@ original.")
(copy-file cmake-rules
   (string-append "fortune-mod/cmake/"
  (strip-store-file-name cmake-rules)))
-   (chdir "fortune-mod")
-   ;; TODO: Valgrind tests fail for some reason.
-   ;; Similar issue: https://github.com/shlomif/fortune-mod/issues/21 (?)
-   (delete-file "tests/t/valgrind.t")
-   #t)))
+   (chdir "fortune-mod"
  (add-after 'install 'fix-install-directory
(lambda* (#:key outputs #:allow-other-keys)
  ;; Move binary from "games/" to "bin/" and remove the latter.  This

base-commit: 72297993a174586ee0a23b95b6b9ee2f3db34cf1
-- 
2.33.0

bug#32691: OpenMolcas

[Sarah Morgensen]

Hello Eric,

Eric Brown  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Eric,
>>
>> We’re almost there!  :-)
>>
>> I made small changes (moved comments about the patch at the top of the
>> patch; switch to ‘texlive-union’, which is much smaller than ‘texlive’),
>> leading to the attached patch.
>>
>> It’s all good, except that the file layout really doesn’t match the
>> usual conventions:
>>
>> [...]
>>
>> Ideally basis_library/ and data/ would go under share/openmolcas, while
>> CONTRIBUTORS.md and LICENSE would go to share/doc/openmolcas.  Also, it
>> would be nice to remove the ‘.exe’ extension.
>>
>> Do you think you could easily fiddle with CMake to fix these and/or
>> report it upstream?  I could apply the patch as is but I think users may
>> not be pleased by this.  WDYT?
>>
>> Thank you for your time, and sorry for the extra round trip!
>
> Hi Ludo',
>
> Thank you again. Indeed, "/" gets littered with some files that out to
> go into share. This has been noted in discussions upstream.
>
> Though we've put a bunch of work into this, I think it would be good to
> pause and see if we can make some of these changes upstream, as you
> suggest.
>
> (Also I need some time to brush up on CMake -- perhaps I can contribute
> some of these changes myself.)
>
> Warm regards,
> Eric

Thanks for all your work on this package.  Did you ever make further
progress on this?  Are you still interested in working on getting
OpenMolcas in Guix?

--
Sarah

bug#32511: mariadb 10.1.35 fails to build on x86_64

[Sarah Morgensen]

Hello,

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

> Hello,
>
> On berlin, mariadb 10.1.35 has one test failure (this is
> /gnu/store/a5jm2hyalyblgjnxx5x3ly4fwvfivq5m-mariadb-10.1.35.drv, as
> found in Guix commit b0cb92b2d43a2c4d5fa9b3f8c04c5732c60061e7, for
> instance):
>
> The servers were restarted 933 times
> Spent 43877.794 of 6960 seconds executing testcases
>
> Failure: Failed 1/1941 tests, 99.95% were successful.
>
> Failing test(s): tokudb_bugs.5733_innodb

Closing this old bug; this was "fixed" in bba7a77 by disabling the
TokuDB backend; for more info:
https://issues.guix.gnu.org/35521

--
Sarah

bug#31789: nss-mdns test is failing

[Sarah Morgensen]

Hello,

Thanks for the report.  Apologies that it's taken two years (!) for a
response.  I can not replicate this; does this still occur for you?

Clément Lassieur  writes:

> nss-mdns test is failing.  Here is the output:
>
>  Starting test avahi
> Group begin: avahi
> Test begin:
>   test-name: "wait for services"
>   source-file: "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
>   source-line: 1
>   source-form: (test-assert "wait for services" (marionette-eval (quote 
> (begin (use-modules (gnu services herd)) (start-service (quote nscd)) (let 
> ((sock (socket PF_UNIX SOCK_STREAM 0))) (let try () (catch (quote 
> system-error) (lambda () (connect sock AF_UNIX "/var/run/nscd/socket") 
> (close-port sock) (format #t "nscd is ready~%")) (lambda args (format #t 
> "waiting for nscd...~%") (usleep 50) (try) (start-service (quote 
> avahi-daemon)) (start-service (quote networking)) #t)) marionette))
> Test end:
>   result-kind: pass
>   actual-value: #t
> Test begin:
>   test-name: "avahi-resolve-host-name"
>   source-file: "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
>   source-line: 1
>   source-form: (test-equal "avahi-resolve-host-name" 0 (marionette-eval 
> (quote (system* "/run/current-system/profile/bin/avahi-resolve-host-name" 
> "-v" "komputilo.local")) marionette))
> Test end:
>   result-kind: pass
>   actual-value: 0
>   expected-value: 0
> Test begin:
>   test-name: "avahi-browse"
>   source-file: "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
>   source-line: 1
>   source-form: (test-equal "avahi-browse" 0 (marionette-eval (quote (system* 
> "avahi-browse" "-avt")) marionette))
> Test end:
>   result-kind: pass
>   actual-value: 0
>   expected-value: 0
> Test begin:
>   test-name: "getaddrinfo .local"
>   source-file: "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
>   source-line: 1
>   source-form: (test-assert "getaddrinfo .local" (match (marionette-eval 
> (quote (getaddrinfo "komputilo.local")) marionette) (((? vector? addrinfos) 
> ..1) (pk (quote getaddrinfo) addrinfos) (and (any (lambda (ai) (= AF_INET 
> (addrinfo:fam ai))) addrinfos) (any (lambda (ai) (= AF_INET6 (addrinfo:fam 
> ai))) addrinfos)
> Test end:
>   result-kind: fail
>   actual-value: #f
>   actual-error: (match-error "match" "no matching pattern" #f)
> Test begin:
>   test-name: "gethostbyname .local"
>   source-file: "/gnu/store/b5gvmlh78s40xvxq73dpdqr7sv0skhmy-nss-mdns-builder"
>   source-line: 1
>   source-form: (test-assert "gethostbyname .local" (match (pk (quote 
> gethostbyname) (marionette-eval (quote (gethostbyname "komputilo.local")) 
> marionette)) ((? vector? result) (and (string=? (hostent:name result) 
> "komputilo.local") (= (hostent:addrtype result) AF_INET)
> Test end:
>   result-kind: fail
>   actual-value: #f
>   actual-error: (match-error "match" "no matching pattern" #f)
> Group end: avahi
> # of expected passes  3
> # of unexpected failures  2

--
Sarah

bug#32247: HandBrake shows no icons

[Sarah Morgensen]

Hello,

Ben Sturmfels  writes:

> On Mon, 23 Jul 2018, Andreas Enge wrote:
>
> I just ran the current version of Handbrake in Guix and can see icons,
> so it may be that this has been fixed elsewhere or through upgrades.
> Would you mind testing again please to see if this is fixed for you?

I just tested and can see the icons as well without doing anything
special.  Given that this is now a two-year old bug, I'll be closing it;
if someone encounters this again, please reopen.

Thanks,
--
Sarah

bug#31991: Packages enki and aseba fail. Organizations behind software restructured

[Sarah Morgensen]

Hi, just following up on this old bug.

Björn Höfling  writes:

> I saw that enki fails due to Qt 5.11.

Enki is now building fine.

> Note that aseba doesn't have a good build history anyway:
>
> https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.x86_64-linux/all
> https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.i686-linux/all
> https://hydra.gnu.org/job/gnu/master/aseba-1.6.0-0.3b35de8.armhf-linux
>
> Anyone using it?
>
> General note:
>
> As far as I know, this package is here for the Thymio robot, not for
> the asaba Framework as such.
>
> In spring 2018, Mobsya (the organisation behind Thymio) decided to go
> their own way, because they don't have the capacity to maintain the
> whole aseba framework as such. Maintainer wanted for the old aseba
> project. See this announcement for more details:
>
> https://github.com/aseba-community/aseba#thymio-and-mobsya-fork
> https://docs.google.com/document/d/1ijY2dZR2TbSySMqFfbCgG_ifZPGoxrAQaVuZVQZHKlY/edit#
>
> So, in the long term, we should base the package definition on their
> repository:
>
> https://github.com/Mobsya/aseba
>
> They don't have a released version yet. And they pull in a lot more
> dependencies via git.

It looks like they have a released version now (2.2.0, in fact).

There is also the Debian-maintained fork of the original:

https://salsa.debian.org/science-team/aseba

Since aseba continues to fail building, we should either remove it, or
switch to one of those two.

--
Sarah

bug#31970: epiphany: Strange "XXXXXXXXXXXXX..." entries in library RPATHs

[Sarah Morgensen]

Hi,

Mark H Weaver  writes:

> Since the upgrade from epiphany-3.24.4 to 3.28.1 in commit
> fc5c5b92cf7a1f6d65079f3840df502edcf58f50,
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fc5c5b92cf7a1f6d65079f3840df502edcf58f50
>
> which also changed the build-system from 'glib-or-gtk-build-system' to
> 'meson-build-system', warnings started appearing in the build logs for
> epiphany complaining about "XX"
> appearing in the RPATH of the built libraries.

Closing this old issue.  (On current master, the build logs no longer
show that error, and `readelf -d' reports no such bogus entries.)

--
Sarah

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

[Sarah Morgensen]

Maxim Cournoyer  writes:
 George Clemmer (2018-05-08 20:04 -0400) wrote:

> In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed
> by manifest (attached) into the "empty" default profile ...
>
> 'guix package -m manifest'
>
> ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't
> appear with the same manifest installed in the "foo" profile ...
>
> Assuming you run Emacs in that foo profile and don't see the font,
> that's probably because XDG_DATA_DIRS is unset in that other profile.
> glib is one of the package setting that variable.
>
> I'm merging this bug with 22138, which would fix the root cause.

Will this be fixed by #50358?  If so, could you close this when that is
merged?

Thanks,

--
Sarah

bug#30210: pandoc not reproducible

[Sarah Morgensen]

Hello,

Ricardo Wurmus  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Ricardo Wurmus  skribis:
>>
 The only file that differs is this:

   
 /gnu/store/8ynsssfjjdjbawndmjlnjlqrh027rl9g-ghc-pandoc-1.17.2-check/lib/ghc-7.10.2/ghc-pandoc-1.17.2.conf.d/package.cache
   
 /gnu/store/8ynsssfjjdjbawndmjlnjlqrh027rl9g-ghc-pandoc-1.17.2/lib/ghc-7.10.2/ghc-pandoc-1.17.2.conf.d/package.cache
>>>
>>> At least they seem to contain the same strings albeit in a different
>>> order.  “diff <(strings a|sort) <(strings b|sort)” shows no
>>> differences.  (Of course there could be other differences than order,
>>> which simply don’t appear to be strings.)
>>
>> That sounds like code using readdir(2) and not sorting the returned
>> entries, as was the case for gtk-update-icon-cache or whatever it’s
>> called.
>
> This package.cache problem has been fixed with commit
> 5de93cdba77db3777f8f026c029acadd7b8bdde3.
>
> Unfortunately it is now bin/pandoc that differs across builds.
>
> --
> Ricardo

I found this old bug.  I tested both pandoc and ghc-pandoc and it looks
like this is no longer an issue (perhaps fixed partially in #43834), so
I'm closing.  Please reopen otherwise.

Thanks,
--
Sarah

bug#50557: Unable to access remote logs

[Sarah Morgensen]

Hello Guix,

For whatever reason, it seems build logs are not available from
ci.guix.gnu.org and bordeaux.guix.gnu.org.  "Invoking guix publish" says
that they should be available at /log/store-name, but...

--8<---cut here---start->8---
$ guix build hello
0.1 MB will be downloaded:
   /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10
substituting /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10...
downloading from 
https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 ...
 hello-2.10  51KiB
249KiB/s 00:00 [##] 100.0%

/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10

$ wget https://ci.guix.gnu.org/log/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10
--2021-09-12 18:05:39--  
https://ci.guix.gnu.org/log/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10
Resolving ci.guix.gnu.org (ci.guix.gnu.org)... 141.80.181.40
Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-09-12 18:05:40 ERROR 404: Not Found.

$ guix build hello --log-file
guix build: error: no build log for 
'/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10'
--8<---cut here---end--->8---

--
Sarah

bug#30591: Vinagre segmentation fault - and gdb cannot find symbols?

[Sarah Morgensen]

Hi Chris,

Chris Marusich  writes:

> The backtrace makes it look like maybe the segfault occurred in gtk-vnc,
> not vinagre itself, so I guess I'll need to customize more packages to
> build more debug outputs and try again...
>
> I'll keep poking at this as I get time.  If anyone has any tips, I'd
> really appreciate it.

I can't replicate this, and it's rather old, so I'm closing this.  It
looks like this may have been an issue with freerdp [0] which was since
fixed.

Please reopen if this is still an issue.  Thanks,

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898448

--
Sarah

bug#30512: phonon-backend-gstreamer has a ./gnu/store subdirectory

[Sarah Morgensen]

Hi,

Ricardo Wurmus  writes:

> The package phonon-backend-gstreamer is configured to install icons in
> $out/gnu/store/…-phonon-backend-gstreamer-…/ instead of $out.

$ find 
/gnu/store/79kjp62wsdlrqzjzg920dgz0acjhqdkk-phonon-backend-gstreamer-4.10.0 
-name gnu
$

This is no longer the case, so closing.

--
Sarah

bug#50556: Clang retains extraneous references to GCC (and zlib)

[Sarah Morgensen]

Hello Guix,

I recently noticed that Clang has some extra references:

--8<---cut here---start->8---
$ guix size clang
store item   totalself
/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0   979.2   
496.0  50.7%
/gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0234.1   
162.7  16.6%
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0  178.5   
107.3  11.0%
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2146.2
57.1   5.8%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   3.8%
/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib   71.0
32.6   3.3%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6   3.3%
/gnu/store/nzfhh1rm85lx2p5plbx45qqj82pcv5hp-clang-runtime-12.0.095.9
24.9   2.5%
/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32  88.0
17.0   1.7%
/gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10  81.1 
7.9   0.8%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16   1.6 
1.6   0.2%
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16 39.4 
1.0   0.1%
/gnu/store/r7k859hmcnkazf492fasqvk25jflnfk6-xz-5.2.473.0 
0.9   0.1%
/gnu/store/g2s5jfkfd4k973wb58476b1bbv9zpm6m-zlib-1.2.11 38.6 
0.2   0.0%
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11 71.2 
0.2   0.0%
/gnu/store/bw15z9kh9c65ycc2vbhl2izwfwfva7p1-libffi-3.3  71.2 
0.2   0.0%
total: 979.2 MiB
--8<---cut here---end--->8---

It retains references two *two* separate gcc-7.5.0-lib outputs, two
separate zlib-1.2.11 outputs, and a gcc-7.5.0 output (clang shouldn't
need GCC, right?)

--8<---cut here---start->8---
$ guix gc --references /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2
/gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10
/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31
/gnu/store/nzfhh1rm85lx2p5plbx45qqj82pcv5hp-clang-runtime-12.0.0
/gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0
/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0
--8<---cut here---end--->8---

Okay, so only the gcc references are direct.  Where is the double
gcc-7.5.0-lib reference coming from?

--8<---cut here---start->8---
$ readelf -d 
/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/bin/clang-12 | grep 
runpath
 0x001d (RUNPATH)Library runpath: 
[/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/lib:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/rmc131fpy2hv408a1awd2wm7kiwyf7d7-llvm-12.0.0/lib:/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib/lib]

$ ldd /gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/bin/clang-12 | 
grep -v LLVM
linux-vdso.so.1 (0x7ffe55cbb000)
libpthread.so.0 => 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0 
(0x7f0cd9d1b000)
libstdc++.so.6 => 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6 
(0x7f0cd6f33000)
libm.so.6 => 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libm.so.6 
(0x7f0cd6df2000)
libgcc_s.so.1 => 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libgcc_s.so.1 
(0x7f0cd6dd9000)
libc.so.6 => 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6 
(0x7f0cd6c1c000)

/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-linux-x86-64.so.2 
(0x7f0cdcf19000)
librt.so.1 => 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/librt.so.1 
(0x7f0cd64ed000)
libdl.so.2 => 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libdl.so.2 
(0x7f0cd64e8000)
libz.so.1 => 
/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib/libz.so.1
(0x7f0cd64c8000)
--8<---cut here---end--->8---

It has an extra runpath but doesn't use it... Why does it have it?

--8<---cut here---start->8---
$ rg "db2-gcc-7.5.0-lib" 
/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0
/gnu/store/vn69pklab842xyig8d0c6xq6s9iyqhl0-clang-12.0.0/include/clang/Config/config.h
58:#define GCC_INSTALL_PREFIX 
"/gnu/store/f0ca0lf64bw08srv1bj7gkg6ag0sbdb2-gcc-7.5.0-lib"
--8<---cut here---end--->8---

So the 

bug#49921: go-1.16 build failing on aarch64: "fatal error: runtime.newosproc"

[Sarah Morgensen]

Sarah Morgensen  writes:

> Sarah Morgensen  writes:
>
>> Hello Guix,
>>
>> I just noticed go-1.16 is failing on aarch64 [0]. I am not having any
>> success tracking down the cause. It looks like the error is the same as
>> was happening for go-1.14 circa 11 Mar [1], which was fixed by 9 Apr
>> [2], but I cannot tell what resolved the issue. I've attached the
>> relevant part of the build log; the full log is available at [0].
>>
>> Any ideas?
>>
>> [0] https://ci.guix.gnu.org/build/949823/details
>> [1] https://ci.guix.gnu.org/build/71004/details
>> [2] https://ci.guix.gnu.org/build/19478/details
>>
>> starting phase `build'
>> runtime: failed to create new OS thread (have 2 already; errno=22)
>> fatal error: runtime.newosproc
>
> I think this might be related to [0], although if it's true that CI uses
> native builders for aarch64 now, I have no idea.
>
> I've been able to reproduce this with both go-1.14 and go-1.16 when
> building with --system=aarch64-linux from an amd64 system.  I tried to
> apply the patch in the thread I mentioned, but go-1.4 won't build at all
> with QEMU.
>
> [0] <https://github.com/golang/go/issues/20763> runtime: cannot run
> cross compiled ARM binary on QEMU
>
> --
> Sarah

I've written this up into a patch (attached below); I don't think
there's much of a way to test this other than just letting CI build it.
It's a backport, so it shouldn't hurt even if it doesn't fix it.

--
Sarah

>From a5824c2495f5a547499ab200cd5b270b38f571d6 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Sarah Morgensen 
Date: Thu, 9 Sep 2021 18:23:10 -0700
Subject: [PATCH core-updates] gnu: go-1.4: Fix running with qemu-aarch64.

Backport the fix for running go with qemu-aarch64.

* gnu/packages/patches/go-1.4-fix-running-with-qemu.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/golang.scm (go-1.4)[origin]: Apply patch.
---
This might fix #49921, but I can't test it as there are a number of issues
preventing go-1.4 from compiling on qemu-aarch64.

It builds fine on x86_64, so it didn't break anything there.

--
Sarah

 gnu/local.mk  |  1 +
 gnu/packages/golang.scm   |  4 +-
 .../go-1.4-fix-running-with-qemu.patch| 38 +++
 3 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/go-1.4-fix-running-with-qemu.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 20f0b8f081..39e17bb3bc 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1144,6 +1144,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/gobject-introspection-absolute-shlib-path.patch \
   %D%/packages/patches/gobject-introspection-cc.patch		\
   %D%/packages/patches/gobject-introspection-girepository.patch	\
+  %D%/packages/patches/go-1.4-fix-running-with-qemu.patch	\
   %D%/packages/patches/go-fix-script-tests.patch			\
   %D%/packages/patches/go-skip-gc-test.patch			\
   %D%/packages/patches/gpm-glibc-2.26.patch			\
diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index d3ef39a2e6..33f3120a09 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -1035,7 +1035,9 @@ your Go binary to be later served from an http.FileSystem.")
   name version ".tar.gz"))
   (sha256
(base32
-"0liybk5z00hizsb5ypkbhqcawnwwa6mkwgvjjg4y3jm3ndg5pzzl"
+"0liybk5z00hizsb5ypkbhqcawnwwa6mkwgvjjg4y3jm3ndg5pzzl"))
+  (patches
+   (search-patches "go-1.4-fix-running-with-qemu.patch"
 (build-system gnu-build-system)
 (outputs '("out"
"doc"
diff --git a/gnu/packages/patches/go-1.4-fix-running-with-qemu.patch b/gnu/packages/patches/go-1.4-fix-running-with-qemu.patch
new file mode 100644
index 00..52914c71a5
--- /dev/null
+++ b/gnu/packages/patches/go-1.4-fix-running-with-qemu.patch
@@ -0,0 +1,38 @@
+Backport from upstream: https://github/golang/go/commit/2673f9ed
+
+Original header:
+
+From 2673f9ed23348c634f6331ee589d489e4d9c7a9b Mon Sep 17 00:00:00 2001
+From: Austin Clements 
+Date: Wed, 12 Jul 2017 10:12:50 -0600
+Subject: [PATCH] runtime: pass CLONE_SYSVSEM to clone
+
+SysV semaphore undo lists should be shared by threads, just like
+several other resources listed in cloneFlags. Currently we don't do
+this, but it probably doesn't affect anything because 1) probably
+nobody uses SysV semaphores from Go and 2) Go-created threads never
+exit until the process does. Beyond being the right thing to do,
+user-level QEMU requires this flag because it depends on glibc to
+create new threads and glibc uses this flag.
+
+Fixes #20763.
+
+---
+ src/runtime/os_linux.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/runtime/os_linux.c b/

bug#50493: Update go-build-system to use Go 1.17.

[Sarah Morgensen]

Hello Guix,

This is intended to be a tracking issue for updating go-build-system to
use Go 1.17 by default.  The build system currently uses Go 1.14, which
no longer receives security updates [0].

Here's what needs to be done:

1. Address the aarch64 bug [1], either by verifying that it only happens
on emulated systems, or by fixing it if not.

2. Make some much-needed improvements to go-build-system [2]:

* replace the *slow* phase 'remove-go-references with -trimpath option

* avoid building a directory union of Go inputs (and then copying it!)

* add a "go-std-cache-for-build" package (hidden; name to be
bikeshedded), which will be an implicit input in go-build-system (needed
since we removed the pre-built standard library in go-1.17)

3. Some/all Docker packages still require Go 1.14; make them use go-1.14
explicitly.  Alternatively, update Docker (significant effort involved).

4. Update or patch broken packages.  I've got patches for four so far:

go-github-com-urfave-cli
go-github-com-urfave-cli-v2
go-github-com-sevlyar-go-daemon
go-github-com-keybase-go-ps

I'll submit them as a separate patch and block this with it.  If anyone
else would like to see if their favorite package works with Go 1.17, you
can build it with:

  go build --with-input=go@1.14=go@1.17 

[0] https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance
[1] https://issues.guix.gnu.org/49921
[2] https://issues.guix.gnu.org/50227#10

--
Sarah

bug#50461: [core-updates-frozen] backtrace on `guix package -A'

[Sarah Morgensen]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Sarah Morgensen  skribis:
>
>> I'm getting a backtrace on `guix package -A'.  The argument doesn't seem
>> to matter, and `guix package -s' works fine.
>
> [...]
>
>> In gnu/packages/tex.scm:
>>   4104:26  1 (_ _ _)
>> In ice-9/boot-9.scm:
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
>> struct): #
>
> I believe rebuilding will fix it:
>
>   rm gnu/packages/*.go && make -j4

That fixed it.  Sorry for the alarm!

(It seems that "make" for guix/guile is not very good at determining
what needs to be recompiled... this isn't the first time "make"
succeeded by still caused issues.)

--
Sarah

bug#50461: [core-updates-frozen] backtrace on `guix package -A'

[Sarah Morgensen]

Hello Guix,

I'm getting a backtrace on `guix package -A'.  The argument doesn't seem
to matter, and `guix package -s' works fine.

--8<---cut here---start->8---
sarah@gnu ~/guix-cu-frozen [env]$ ./pre-inst-env guix describe
Git checkout:
  repository: /home/sarah/guix/.git/worktrees
  branch: HEAD
  commit: 445eec918332c1b8d4a6ba4baf1322e13076029b
sarah@gnu ~/guix-cu-frozen [env]$ ./pre-inst-env guix package -A foo
Backtrace:
In srfi/srfi-1.scm:
   460:18 19 (fold # …)
In guix/packages.scm:
  1088:40 18 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
100:0 17 (_ # (# …) …)
In guix/packages.scm:
  1084:10 16 (_)
In srfi/srfi-1.scm:
   460:18 15 (fold # …)
In guix/packages.scm:
  1088:40 14 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
100:0 13 (_ # (# …) …)
In guix/packages.scm:
  1084:10 12 (_)
In srfi/srfi-1.scm:
   460:18 11 (fold # …)
In guix/packages.scm:
  1088:40 10 (_ _ ("x86_64-linux" "i686-linux"))
In guix/memoization.scm:
100:0  9 (_ # (# …) …)
In guix/packages.scm:
  1092:35  8 (_)
  1331:16  7 (package->bag _ _ _ #:graft? _)
  1432:48  6 (thunk)
In gnu/packages/docbook.scm:
   479:28  5 (inputs #)
   405:19  4 (inputs #)
In gnu/packages/tex.scm:
  4103:18  3 (texlive-updmap.cfg _)
In srfi/srfi-1.scm:
   460:18  2 (fold # …)
In gnu/packages/tex.scm:
  4104:26  1 (_ _ _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting 
struct): #
--8<---cut here---end--->8---

--
Sarah

bug#50441: Wrong build directory number shown in environment-variables file

[Sarah Morgensen]

Hello Christine,

Christine Lemmer-Webber  writes:

> I was doing guix build with "--keep-missing" and looking around in a few
> of the output directories.  I was peeking in:
>
>   /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4
>
> But wait... the "environment-variables" file says:
>
> #+BEGIN_SRC sh
> export TEMP=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TEMPDIR=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TMP=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TMPDIR=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> #+END_SRC
>
> Now wait a minute.  Look at that last number.  What the hell is going on
> here?  Is this a bug in Guix?  Why is it pointing at -0 in the -4 build
> directory?
>
> Does this point at a more serious issue?  What's going on?

I've definitely noticed this before as well, and had to work around it
(I needed to inspect temp caches).  Thanks for actually sending a bug
report :)

I'm not at all familiar with the nix code, but it looks like this might
be related:

nix/libstore/build.cc:1654
--8<---cut here---start->8---
/* In a sandbox, for determinism, always use the same temporary
   directory. */
tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" + 
drvName + "-0" : tmpDir;

/* For convenience, set an environment pointing to the top build
   directory. */
env["NIX_BUILD_TOP"] = tmpDirInSandbox;

/* Also set TMPDIR and variants to point to this directory. */
env["TMPDIR"] = env["TEMPDIR"] = env["TMP"] = env["TEMP"] = tmpDirInSandbox;

/* Explicitly set PWD to prevent problems with chroot builds.  In
   particular, dietlibc cannot figure out the cwd because the
   inode of the current directory doesn't appear in .. (because
   getdents returns the inode of the mount point). */
env["PWD"] = tmpDirInSandbox;
--8<---cut here---end--->8---

I'm not entirely sure what's going on.  I think we build in chroot by
default, which would explain why the temp vars get set to "-0" even
though everything else seems to work okay.

--
Sarah

bug#50433: shotcut 21.06.29 missing bin files

[Sarah Morgensen]

Hello,

Thanks for your report.

Fulbert  writes:

> Hello,
>
> shotcut 21.06.29 (guix ce65f2b) appears to have missing bin files. When trying
> to export a video, the status of the task is "failed" inside the GUI, and 
> below
> is the debug message on the terminal.
>
> [Debug  ] 
> "/gnu/store/qz8nr42ax7k3v0cysmh6afhmy93vvj82-shotcut-21.06.29/bin/melt-7 
> -verbose -progress2 -abort xml:%2Ftmp%2Fshotcut-xNVrrX.mlt"
> [Info   ]  job failed with 127
>
> And here is the content of the bin directory :
>
> $ ls -la $(dirname $(realpath $(which shotcut)))
> total 3248
> dr-xr-xr-x 2 root root    4096  1 janv.  1970 .
> dr-xr-xr-x 4 root root    4096  1 janv.  1970 ..
> -r-xr-xr-x 2 root root    1840  1 janv.  1970 shotcut
> -r-xr-xr-x 2 root root    1401  1 janv.  1970 .shotcut-real
> -r-xr-xr-x 2 root root 3308600  1 janv.  1970 ..shotcut-real-real

I compared this to the release binaries and there really is just the one
'shotcut' executable.  I think you're correct that the '127' error is
due to it not finding an executable, but I think that's happening
because shotcut got double-wrapped (or wrapped incorrectly).

Unfortunately I'm not knowledgeable with qt-wrapping so I can't help any
further, but I hope that helps!

--
Sarah

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Guillaume Le Vaillant  writes:

> Sarah Morgensen  skribis:
>
>> The remaining packages have a total of 19 dependents, 7 of which belong
>> to ocl-icd@2.2.12.  As soon as ocl-icd's website is back online, updating
>> it to 2.2.13 should fix the build.
>
> I just saw that on the master branch ocl-icd has been deprecated and
> replaced by opencl-icd-loader. However I've not tried merging master
> into core-updates-frozen to see if it the build works.

I've just submitted a patch to fix ocl-icd [0].

Hmmm.  It looks like it was removed because it "disappeared", but it
just changed locations...

[0] https://issues.guix.gnu.org/50418

--
Sarah

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Hi again,

>> libappindicator@12.10.0
>> pipewire@0.2.7

I've sent patches for these [0][1], with a total of 22 dependents.

The remaining packages have a total of 19 dependents, 7 of which belong
to ocl-icd@2.2.12.  As soon as ocl-icd's website is back online, updating
it to 2.2.13 should fix the build.

[0] https://issues.guix.gnu.org/50392
[1] https://issues.guix.gnu.org/50396

--
Sarah

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Hi Ludo,

>> lablgtk@2.18.10
>> libsrtp@2.3.0
>> ocaml4.07-lablgtk@1.18.10

I've sent patches [0] [1] to fix these by updating them.  Together they
have 79 dependents.

[0] https://issues.guix.gnu.org/50388
[1] https://issues.guix.gnu.org/50389

--
Sarah

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Sarah Morgensen]

Hi all,

Thanks for your comments.  I'm replying specifically to this message but
these thoughts apply to the issue as a whole.

Maxime Devos  writes:

> Sarah Morgensen schreef op do 02-09-2021 om 21:06 [-0700]:
>> Hello Guix,
>> 
>> This patch adds a shorthand for "(define-public name (package ...))":
>> 
>> (define-package my-favorite-package
>>   (name "my-favorite-package")
>>   ...)
>
> This could be even shorter in the special case that the variable name
> and package name are the same (modulo types):
>
> (define-package "my-favorite-package"
>   (version ...)
>   ...)
>
> 'datum->syntax' and 'string->symbol' can be used to turn "my-favorite-package"
> into an identifier.
>
> A 'define-unexported-package' might be required in some places.

Sure, or perhaps 'define-private-package'.  I think this is pretty rare,
though?  And often in those cases other forms are used which may be
incompatible with the macro, so they'll have to use the original syntax
anyway.  Either way is fine IMO.

There are also about 150 packages which use 'package/inherit'.  Should
we introduce special syntax for them?  What about 'hidden-package'
(about 60 packages)?  (And 11 use both!)

About the only form I can think of that wouldn't break the composability
of these kinds of things is something like

  (define-package* hello (hidden)
(name "hello")
...)

or

  (define-package* hello (hidden inherit-replacements)
(name "hello")
...)

Where 'hidden', 'inherit-replacements', and so on would be procs to
apply (in the same order as compose?) that each transform the package.
Or we could even have them transform the package syntax directly.

But that's even more magic; it would take a fair amount of work, and be
hard to get right.  (How well would it hold up to syntax errors?)

>
> [...]
> This looks nice to me.  IIUC, the define-package is intended to be clearer
> to newcomers, so you might want to ask for feedback on the new syntax on
> help-g...@gnu.org.

Thanks for the suggestion, I definitely will.

With an eye toward newcomers, I think one "gotcha" of the "optional
name" version is inheritance.  If I have

(define-package rust-actix-0.10
  (name "rust-actix")
  ...)

and then I write

(define-package rust-actix-0.20
  (inherit rust-actix-0.10)
  ...)

At best, I would be unsure about whether this package would inherit the
name.  At worst, I would assume the name is inherited, and I would be
wrong.  If I have to write the name, there is no ambiguity.

For the automatic naming (because of gotchas like that), and for
possible extensions discussed above, I think right now I'm tempted to
agree with Ludo's comment when this last came around (thanks to Tobias
for pointing out the conversation)[0]:

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

> However, I prefer treating packages just like any other Scheme object,
> and to avoid introducing “magic” with macros like this.

I could be convinced with an elegant enough implementation though! ;)

[0] https://lists.gnu.org/archive/html/bug-guix/2013-09/msg5.html
--
Sarah

bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Sarah Morgensen]

Hi Taylan,

Taylan Kammer  writes:

> On 04.09.2021 16:44, Tobias Geerinckx-Rice wrote:
>> Taylan Kammer 写道：
>>> To me the most obvious thing to do seems
>>>
>>>   (define-package foo ...)  ;no explicit name needed
>>>
>>> to bind the variable 'foo' and use symbol->string for the name of the
>>> package, with the possibility to override the name like
>>>
>>>   (define-package foo (name "foobar") ...)
>>>
>>> which would bind the variable 'foo' to a package named "foobar".
>> 
>> Right, that's what I meant, and it's how I read bug #15284, and it looks 
>> remarkably like the form I use in my personal channels (and I'm sure I'm not 
>> the first! :-).
>> 
>> You're much better at the language/implementation side of things than I am, 
>> Taylan.  Would this negatively affect performance (including ‘guix pull’ 
>> compilation)?
>> 
>> Kind regards,
>> 
>> T G-R

I agree; if we added that magic, that's definitely how it should be.

>
> I'm flattered, but don't really know the answer, so I decided to attempt
> some sort of benchmark. :-P
>
> test1.scm uses the syntax-case macro, test2.scm just define-public.
>
> I don't actually import the Guix modules, so the (package ...) form isn't
> macro-expanded, regardless of whether it's used directly or results from
> expanding define-package.
>
> This way, the impact of define-package should dominate the time difference.
>
> The results are... interesting.  I started out with 256 definitions in the
> files, and the define-package one would take about 4.2s to compile while
> the regular one about 3.9s.  There was some jitter in the results though
> after running it several times so I thought, let's increase the number of
> packages to reduce noise.
>
> With 512 packages, the one using regular define-public takes a whole
> minute to compile, whereas the define-package one just ~14 seconds!
>
> So no idea what's going on there, and how the use of this macro in the
> actual (gnu packages ...) modules would affect performance. :-)

Thanks for running some benchmarks. Were both those latter runs with a
warm cache?

If so, is it possible that due to a compilation optimization, many of
the global symbol lookups only happen once with the define-package
macro?

If you were really interested, I suppose you could test with compilation
optimization off, but I'd be more interested in the performance impact
with (guix packages) imported.

--
Sarah

bug#49921: go-1.16 build failing on aarch64: "fatal error: runtime.newosproc"

[Sarah Morgensen]

Sarah Morgensen  writes:

> Hello Guix,
>
> I just noticed go-1.16 is failing on aarch64 [0]. I am not having any
> success tracking down the cause. It looks like the error is the same as
> was happening for go-1.14 circa 11 Mar [1], which was fixed by 9 Apr
> [2], but I cannot tell what resolved the issue. I've attached the
> relevant part of the build log; the full log is available at [0].
>
> Any ideas?
>
> [0] https://ci.guix.gnu.org/build/949823/details
> [1] https://ci.guix.gnu.org/build/71004/details
> [2] https://ci.guix.gnu.org/build/19478/details
>
> starting phase `build'
> runtime: failed to create new OS thread (have 2 already; errno=22)
> fatal error: runtime.newosproc

I think this might be related to [0], although if it's true that CI uses
native builders for aarch64 now, I have no idea.

I've been able to reproduce this with both go-1.14 and go-1.16 when
building with --system=aarch64-linux from an amd64 system.  I tried to
apply the patch in the thread I mentioned, but go-1.4 won't build at all
with QEMU.

[0] <https://github.com/golang/go/issues/20763> runtime: cannot run
cross compiled ARM binary on QEMU

--
Sarah

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Sarah Morgensen]

Hello Guix,

GCC 10 changed the default behavior when encountering multiple
definitions of a global (often an enum) [0].  This causes error messages
like [1]:

--8<---cut here---start->8---
  ld: a.o:(.bss+0x0): multiple definition of `a'; main.o:(.data+0x0): first 
defined here
--8<---cut here---end--->8---

Gentoo's tracker for this issue [2] also has some more info.  I manually
searched Cuirass build logs and found 28 packages failing on x86_64 with
this error:

arcan-sdl@0.5.5.2-1.b4dd1fb
aris@2.2
blastem@0.6.2
chocolate-doom@3.0.1
crispy-doom@5.8.0
geeqie@1.5
glabels@3.4.1
gmtp@1.3.11
gpredict@2.2.1
gtksheet@4.3.5
jumpnbump@1.61
lablgtk@2.18.10
libappindicator@12.10.0
libopenshot@0.2.5
libsrtp@2.3.0
linsmith@0.99.31
megaglest@3.13.0
mupen64plus-core@2.5
ocaml4.07-lablgtk@1.18.10
ocl-icd@2.2.12
opencpn@5.0.0
pcsxr@1.9.95
pipewire@0.2.7
transcode@1.1.7
transmission-remote-gtk@1.4.1
uget@2.2.1
uim-gtk@1.8.8
uim-qt@1.8.8

I submitted an issue upstream for transmission-remote-gtk [3], but I
haven't taken a look at the others.  Any takers?

[0] https://gcc.gnu.org/gcc-10/porting_to.html
[1] 
https://wiki.gentoo.org/wiki/Project:Toolchain/Gcc_10_porting_notes/fno_common
[2] https://bugs.gentoo.org/705764
[3] 
https://github.com/transmission-remote-gtk/transmission-remote-gtk/issues/122

--
Sarah

bug#49202: guix import go type error (failed regex match?)

[Sarah Morgensen]

Hi,

Maxim Cournoyer  writes:

> So we're down to:
>
> $ guix import go github.com/cockroachdb/cockroach-go
> Backtrace:
>9 (primitive-load "/home/maxim/.config/guix/current/bin/guix")
> In guix/ui.scm:
>2185:7  8 (run-guix . _)
>   2148:10  7 (run-guix-command _ . _)
> In guix/scripts/import.scm:
>120:11  6 (guix-import . _)
> In guix/scripts/import/go.scm:
>115:27  5 (guix-import-go . _)
> In guix/import/go.scm:
>531:18  4 (go-module->guix-package _ #:goproxy _ #:version _ 
> #:pin-versions? _)
> In guix/git.scm:
> 247:4  3 (update-cached-checkout _ #:ref _ #:recursive? _ #:check-out? _ 
> #:starting-commit _ # _ # _)
>236:18  2 (resolve _)
> In git/reference.scm:
>  60:8  1 (_ _ _)
> In git/bindings.scm:
>  77:2  0 (raise-git-error _)

This one is happening because the go.mod served by pkg.go.dev reports
that the module version is "2.0.1+incompatible".  This is because the
proper import path is "github.com/cockroachdb/cockroach-go/v2" as the
first line of the project's go.mod states.  An import for that path is
successful.

>
> $ guix import go dmitri.shuralyov.com/gpu/mtl
> Backtrace:
>5 (primitive-load "/home/maxim/.config/guix/current/bin/guix")
> In guix/ui.scm:
>2185:7  4 (run-guix . _)
>   2148:10  3 (run-guix-command _ . _)
> In guix/scripts/import.scm:
>120:11  2 (guix-import . _)
> In guix/scripts/import/go.scm:
>115:27  1 (guix-import-go . _)
> In guix/import/go.scm:
>615:19  0 (go-module->guix-package "dmitri.shuralyov.com/gpu/mtl" 
> #:goproxy _ #:version _ # _)
>
> guix/import/go.scm:615:19: In procedure go-module->guix-package:
> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
> struct): #f

This one is happening because the url

   "dmitri.shuralyov.com/gpu/mtl?go-get=1"

which is used to determine the VCS type and location, does not actually
have the headers it is supposed to (instead, they are written in text on
the body of the page...)  It should be addressed upstream, but we should
also have a better error than a backtrace.

>
> Thanks,
>
> Maxim

bug#49947: Backtrace on "@abbr{...}" in package description

[Sarah Morgensen]

Hello Guix,

The Texinfo manual says [0] that I should be able to use @abbr, and
prefer it over @acronym when the text is not all capital letters, but I
get a backtrace when I try to use it in a package description:

--8<---cut here---start->8---
Backtrace:
In ice-9/boot-9.scm:
  1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  15 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 14 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 13 (_ #(#(#)))
In guix/ui.scm:
   2185:7 12 (run-guix . _)
  2148:10 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/package.scm:
906:9  9 (_)
In srfi/srfi-1.scm:
634:9  8 (for-each # ?)
In ice-9/boot-9.scm:
  1747:15  7 (with-exception-handler # ?)
In srfi/srfi-1.scm:
634:9  6 (for-each # ?)
In guix/ui.scm:
  1558:14  5 (package->recutils _ # _ # _ # _)
  1432:23  4 (texi->plain-text _)
In texinfo.scm:
  1132:22  3 (parse _)
   967:36  2 (loop # (*fragment*) # ?)
 92:2  1 (command-spec _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `parser-error' with args `(#f "Unknown command" abbr)'.
--8<---cut here---end--->8---

If this isn't an oversight, and not all Texinfo markup is supported,
that should be noted in the manual.

[0] 
https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#g_t_0040abbr

--
Sarah

bug#49921: go-1.16 build failing on aarch64: "fatal error: runtime.newosproc"

[Sarah Morgensen]

Hello Guix,

I just noticed go-1.16 is failing on aarch64 [0]. I am not having any
success tracking down the cause. It looks like the error is the same as
was happening for go-1.14 circa 11 Mar [1], which was fixed by 9 Apr
[2], but I cannot tell what resolved the issue. I've attached the
relevant part of the build log; the full log is available at [0].

Any ideas?

[0] https://ci.guix.gnu.org/build/949823/details
[1] https://ci.guix.gnu.org/build/71004/details
[2] https://ci.guix.gnu.org/build/19478/details

starting phase `build'
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: runtime.newosproc

runtime stack:
runtime.throw(0x5342c6)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/panic.go:491
 +0xa4
runtime.newosproc(0x10722000, 0x10732000)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/os_linux.c:170
 +0xec
newm(0xa4080, 0x0)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:1157
 +0xbc
runtime.newsysmon()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:169
 +0x2c
runtime.onM(0x54c228)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:256
 +0x74
runtime.mstart()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:818

goroutine 1 [running]:
runtime.switchtoM()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:193
 +0x4 fp=0x1071c7c0 sp=0x1071c7bc
runtime.main()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.go:32
 +0x4c fp=0x1071c7e4 sp=0x1071c7c0
runtime.goexit()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:1322
 +0x4 fp=0x1071c7e4 sp=0x1071c7e4
Building Go cmd/dist using 
/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003. ()
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: runtime.newosproc

runtime stack:
runtime.throw(0x5342c6)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/panic.go:491
 +0xa4
runtime.newosproc(0x10722000, 0x10732000)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/os_linux.c:170
 +0xec
newm(0xa4080, 0x0)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:1157
 +0xbc
runtime.newsysmon()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:169
 +0x2c
runtime.onM(0x54c228)

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:256
 +0x74
runtime.mstart()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.c:818

goroutine 1 [running]:
runtime.switchtoM()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:193
 +0x4 fp=0x1071c7c0 sp=0x1071c7bc
runtime.main()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/proc.go:32
 +0x4c fp=0x1071c7e4 sp=0x1071c7c0
runtime.goexit()

/gnu/store/ax3zhpkysy3nl5ipw3qb9yh2g04a0f1s-go-1.4-bootstrap-20171003/src/runtime/asm_arm.s:1322
 +0x4 fp=0x1071c7e4 sp=0x1071c7e4
command "sh" "make.bash" "--no-banner" failed with status 2
builder for `/gnu/store/dfqww60vr4gykvz3fz4mj9sgk0x4jypz-go-1.16.7.drv' failed 
with exit code 1
@ build-failed /gnu/store/dfqww60vr4gykvz3fz4mj9sgk0x4jypz-go-1.16.7.drv - 1 
builder for `/gnu/store/dfqww60vr4gykvz3fz4mj9sgk0x4jypz-go-1.16.7.drv' failed 
with exit code 1

bug#49815: Upcoming timekeeping failure in gpsd

[Sarah Morgensen]

Hi Leo,

Leo Famulari  writes:

> I got past the previous build failure by setting the environment
> variable "TAR=noop" (found in the Nix package [0])... who knows what
> that means? It only appears in the Nix packaging.
>
> So now, using the attached patch, it fails to build because it can't
> find limits.h, as shown below. Any ideas?
>

[...]

>
> diff --git a/gnu/packages/gps.scm b/gnu/packages/gps.scm
> index 0eb4362858..df4c8ef4f6 100644
> --- a/gnu/packages/gps.scm
> +++ b/gnu/packages/gps.scm
> @@ -222,14 +222,16 @@ such as elevation, speed, heart rate, power, 
> temperature, and gear shifts.")
>  (define-public gpsd
>(package
>  (name "gpsd")
> -(version "3.21")
> +(version "3.23-rc1")
>  (source
>   (origin
> -   (method url-fetch)
> -   (uri (string-append "https://download-mirror.savannah.gnu.org;
> -   "/releases/gpsd/gpsd-" version ".tar.gz"))
> +   (method git-fetch)
> +   (uri (git-reference
> +  (url "https://gitlab.com/gpsd/gpsd;)
> +  (commit "7f30d88d04dc62b8bd6265ad1d09d72d220f97f6")))
> +   (file-name (git-file-name name version))
> (sha256
> -(base32 "14gyqrbrq6jz4y6x59rdpv9d4c3pbn0vh1blq3iwrc6kz0x4ql35"
> +(base32 "0n2ba6n2z3qjnjl2lvzqrp71x2rkip17p0r9hflviwkzcfr7ppdk"
>  (build-system scons-build-system)
>  (native-inputs
>   `(("bc" ,bc)
> @@ -259,6 +261,7 @@ such as elevation, speed, heart rate, power, temperature, 
> and gear shifts.")
> (modify-phases %standard-phases
>   (add-after 'unpack 'fix-build
> (lambda* (#:key outputs #:allow-other-keys)
> + (setenv "TAR" "noop")
>   (substitute* "SConstruct"
  ^ Should be "SConscript"

This fixes the build.

> (("envs = \\{\\}")
>  "envs = os.environ"))

Hope that helps!

--
Sarah

bug#49815: Upcoming timekeeping failure in gpsd

[Sarah Morgensen]

Hi,

Just a quick suggestion from a bystander...

Thiago Jung Bauermann  writes:

> The SCons build system sets the compiler include path from the $CPPPATH
> environment variable while GCC and Guix use $C_INCLUDE_PATH, so set the
> former with the value of the latter.
>
> * guix/build/scons-build-system.scm (build): Set $CPPPATH from
> $C_INCLUDE_PATH.
> ---
>
> Hi Leo,
>
> I was able to build your patch using this one.
>
> Thanks,
> Thiago
>
>
>  guix/build/scons-build-system.scm | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/guix/build/scons-build-system.scm 
> b/guix/build/scons-build-system.scm
> index 17a0b7b877e6..fa422c41a172 100644
> --- a/guix/build/scons-build-system.scm
> +++ b/guix/build/scons-build-system.scm
> @@ -20,6 +20,7 @@
>  (define-module (guix build scons-build-system)
>#:use-module ((guix build gnu-build-system) #:prefix gnu:)
>#:use-module (guix build utils)
> +  #:use-module (srfi srfi-26)
>#:export (%standard-phases
>  scons-build))
>  
> @@ -32,6 +33,10 @@
>  (define* (build #:key outputs (build-targets '()) (scons-flags '()) 
> (parallel-build? #t) #:allow-other-keys)
>(let ((out (assoc-ref outputs "out")))
>  (mkdir-p out)
> +;; SCons expects the include path in $CPPPATH, so copy from
> +;; $C_INCLUDE_PATH.
> +(let ((c-include-path (getenv "C_INCLUDE_PATH")))
> +  (and=> c-include-path (cut setenv "CPPPATH" <>)))

To avoid importing srfi-26, you could write

 (and c-include-path (setenv "CPPPATH" c-include-path))

Or, if you're confident C_INCLUDE_PATH is always set (since
scons-build-system extends gnu-build-system, which includes gcc):

 (setenv "CPPPATH" (getenv "C_INCLUDE_PATH"))

>  (apply invoke "scons"
> (append (if parallel-build?
> (list "-j" (number->string

--
Sarah

bug#49916: etc/committer: backtrace on gexp

[Sarah Morgensen]

Hello Guix,

(Ricardo, I've Cc'd you since it seems etc/committer.scm is mostly your
work.)

It looks like etc/committer.scm is choking on gexps on core-updates-frozen:

--8<---cut here---start->8---
~/guix-cu-frozen [env]$ etc/committer.scm
ice-9/read.scm:126:4: In procedure read-expr*:
gnu/packages/games.scm:13005:11: Unknown # object: "#~"
--8<---cut here---end--->8---

...and this is the offending package:

--8<---cut here---start->8---
(define-public 0ad-data
  (package
(name "0ad-data")
(version "0.0.23b-alpha")
(source
 (origin
   (method url-fetch)
   (uri (string-append "https://releases.wildfiregames.com/0ad-;
   version "-unix-data.tar.xz"))
   (file-name (string-append name "-" version ".tar.xz"))
   (sha256
(base32
 "04x7729hk6zw1xj3n4s4lvaviijsnbjf5rhzvjxlr5fygvg4l6z1"))
   (modules '((guix build utils)))
   (snippet
#~(begin
(for-each (lambda (name)
(let* ((dir (string-append "binaries/data/mods/" name))
   (file (string-append dir "/" name ".zip"))
   (unzip #$(file-append unzip "/bin/unzip")))
  (invoke unzip "-d" dir file)
  (delete-file file)))
  '("mod" "public"))
#t
(build-system trivial-build-system)
--8<---cut here---end--->8---

I think with the changes from new style inputs, gexps in packages are
going to become more common, so etc/committer.scm should support them.

WDYT?

--
Sarah

bug#49827: Error message for missing synopsis in opam importer

[Sarah Morgensen]

Hi,

Thanks for the report. I'm CC'ing Simon since they have been working on
improved error handling/reporting for the importers.

Alice BRENON  writes:

> Hello,
>
> I triggered a confusing behaviour from the opam importer trying to
> import package iter 1.2.1 today on a Guix System install.
>
> The package iter is missing a "synopsis" field as can be seen on
> https://opam.ocaml.org/packages/iter/ , which when I tried
>
> guix import opam iter
>
> yielded the following backtrace:
>
> Backtrace:
>8 (primitive-load "/home/alice/.config/guix/current/bin/g…")
> In guix/ui.scm:
>2185:7  7 (run-guix . _)
>   2148:10  6 (run-guix-command _ . _)
> In guix/scripts/import.scm:
>120:11  5 (guix-import . _)
> In guix/scripts/import/opam.scm:
>104:23  4 (guix-import-opam . _)
> In guix/utils.scm:
> 752:8  3 (call-with-temporary-output-file _)
> In guix/import/opam.scm:
>337:34  2 (_ _ _)
> In srfi/srfi-1.scm:
>460:18  1 (fold # …)
> In guix/import/opam.scm:
>193:15  0 (_ _ _)
>
> guix/import/opam.scm:193:15: Throw to key `match-error' with args
> `("match" "no matching pattern" string-pat)'.
>
>
> the final error is raised l.193 of guix/import/opam.scm because
> metadata-ref supports various types for a metadata field, but not the
> lack of it. As discussed with Maxime Devos on the IRC channel, it would
> be helpful to either allow the import of a package with a missing field
> (possibly filling it in the output scheme code for the imported package
> with some bad value requiring the user to fill it and causing any build
> to crash until replaced properly) or at least to handle that missing
> field with a more explicit error message than the above backtrace
> (something like "Can't import that package because it's missing such or
> such field").

IMO, a warning should be emitted, but the package should be buildable if
at all possible; it's the submitter's responsibility to vet imported
packages.

Simon, how's that error handling rework coming? ;)

>
> Thanks,
>
> Alice BRENON

--
Sarah

bug#49439: grafts cause “guix environment” to get killed with OOM

[Sarah Morgensen]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Thinking about it, the grafts code depends on what’s in the store: when
>> nothing is in the store, it bounces to the “build handler”, which
>> accumulates the list of missing store items, until it starts building
>> them.
>
> So I can reproduce the problem Ricardo and you initially reported by
> running:
>
>   ./pre-inst-env guix environment pigx-scrnaseq --search-paths
>
> after removing some of the ungrafted store items with:
>
>   guix gc -D $(guix build r-rlang --no-grafts) \
> $(guix gc --references $(guix build pigx-scrnaseq --no-grafts))

Same here. I'm glad we were able to pinpoint this!

>
> The seemingly endless CPU usage and unbound memory use comes from the
> ‘build-accumulator’ build handler.  Here, the graph of ‘pigx-scrnaseq’
> has many nodes, and many of them depend on, say, ‘r-rlang’.  Thus, when
> ‘r-rlang’ is not in the store, the grafting code keeps asking for it by
> calling ‘build-derivations’, which aborts to the build handler; the
> build handler saves the .drv file name and the continuation and keeps
> going.  But since the next package also depends on ‘r-langr’, we abort
> again to the build handler, and so on.
>
> The end result is a very long list of  nodes, probably of
> this order in this case:
>
>   $ guix graph -t reverse-package r-rlang |grep 'label = "'|wc -l
>   594
>
> Presumably, the captured continuations occupy quite a bit of memory,
> hence the quick growth.
>
> I suppose one solution is to fire suspended builds when the build
> handler sees a build request for a given derivation for the second time.
> It needs more thought and testing…

I wonder if instead it's possible to reduce the memory taken by the
continuations? As someone who has absolutely no experience with the
build/derivation system, it seems like all we *should* need to save is
the derivation file name.

>
> Ludo’.
>
> PS: Did you know ‘pigx-scrnaseq’ has twice as many nodes as
> ‘libreoffice’?
>
>   $ guix graph -t bag pigx-scrnaseq |grep 'label = "'|wc -l
>   1359
>   $ guix graph -t bag libreoffice |grep 'label = "'|wc -l
>   699
>
> That makes it a great example to study and fix scalability issues!

For those interested, I've compiled a list of the top 60
highest-dependency packages, as reported by package-closure:

pigx1630
nextcloud-client1539
akregator   1486
kmail   1484
korganizer  1481
kdepim-runtime  1480
kincidenceeditor1478
keventviews 1477
kmailcommon 1476
kcalendarsupport1475
kmessagelib 1474
knotes  1472
kaddressbook1469
libksieve   1467
kdepim-apps-libs1465
libgravatar 1463
kpimcommon  1462
akonadi-calendar1453
pigx-bsseq  1448
elisa   1446
kaffeine1432
kdenlive1431
kmailtransport  1431
dolphin-plugins 1426
k3b 1424
libkgapi1422
dolphin 1421
kopete  1403
pigx-sars-cov2-ww   1401
krdc1398
baloo-widgets   1397
baloo   1396
pigx-chipseq1396
krfb1389
ffmpegthumbs1388
kget1382
kmplayer1381
kdelibs4support 1375
pigx-scrnaseq   1342
kdevelop1340
kmailimporter   1326
libkdepim   1325
pigx-rnaseq 1324
labplot 1316
smb4k   1315
kleopatra   1311
kalarmcal   1311
choqok  1311
okular  1310
ktnef   1310
ktorrent1310
kate1308
akonadi-search  1308
kcalutils   1307
yakuake 1306
khelpcenter 1305
libksysguard1305
kdeconnect  1304
konsole 1304
libkleo 1304

There seem to be a lot of kde packages in there, so perhaps this issue
isn't as rare as we might otherwise expect?

--
Sarah

bug#49439: grafts cause “guix environment” to get killed with OOM

[Sarah Morgensen]

Hi,

Ludovic Courtès  writes:

[...]

>> I can reproduce this with pigx-scrnaseq as well a number of other
>> packages (listed below).
>>
>> $ ./pre-inst-env guix describe -f channels
>> (list (channel
>> (name 'guix)
>> (url "/home/sarah/guix")
>> (commit
>>   "3217a04b0352c2dd13323257b369604eeabfccc3")))
>>
>> Does not complete within 5 minutes:

Okay, so all of a sudden I can't reproduce this; even with the same
commit as above, it completes in ~20s.

  guix time-machine --commit=3217a04 -- environment pigx-scrnaseq 
--search-paths >/dev/null

> What hardware are you using?

Virtualbox VM with VT-x etc. on a host i7-6700. The VM has 6GB of memory.

>
> Here’s what I observe (with everything already in store and on a hot
> cache, with an i7 CPU):
>
> $ guix describe
> Generacio 188 Jul 25 2021 12:47:29(nuna)
>   guix a92dfbc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: a92dfbce30777de6ca05031e275410cf9f56c84c
> $ time GUIX_PROFILING=gc guix environment pigx-scrnaseq --search-paths 
> --no-grafts >/dev/null
> Garbage collection statistics:
>   heap size:160.31 MiB
>   allocated:1440.70 MiB
>   GC times: 39
>   time spent in GC: 4.51 seconds (46% of user time)
>
> real  0m7.534s
> user  0m9.747s
> sys   0m0.167s
> $ time GUIX_PROFILING=gc guix environment pigx-scrnaseq --search-paths  
> >/dev/null
> Garbage collection statistics:
>   heap size:168.31 MiB
>   allocated:2111.71 MiB
>   GC times: 53
>   time spent in GC: 6.92 seconds (45% of user time)
>
> real  0m12.100s
> user  0m15.517s
> sys   0m0.198s
>
>
> Commit 78daf9e02e5bc51f91488d8237cab2050cc060cf optimizes
> ‘coalesce-duplicate-inputs’, which was quadratic in the number of inputs (!).
> After that change, I get:
>
> $ time GUIX_PROFILING=gc ./pre-inst-env guix environment pigx-scrnaseq 
> --search-paths --no-grafts  >/dev/null
> Garbage collection statistics:
>   heap size:168.31 MiB
>   allocated:716.58 MiB
>   GC times: 24
>   time spent in GC: 2.65 seconds (40% of user time)
>
> real  0m5.720s
> user  0m6.708s
> sys   0m0.149s
> $ time GUIX_PROFILING=gc ./pre-inst-env guix environment pigx-scrnaseq 
> --search-paths  >/dev/null
> Garbage collection statistics:
>   heap size:160.31 MiB
>   allocated:1387.96 MiB
>   GC times: 42
>   time spent in GC: 5.87 seconds (43% of user time)
>
> real  0m10.821s
> user  0m13.513s
> sys   0m0.198s
>
> Could you tell me if it improves the situation for you?

*Now* my experience is like yours:

--8<---cut here---start->8---
$ guix describe
Generation 9Jul 27 2021 12:35:05(current)
  guix d0ec739
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d0ec73907c2995034a34339f4a7c2c72c2e21fea

time GUIX_PROFILING=gc guix time-machine --commit=3217a04 -- environment 
pigx-scrnaseq --search-paths >/dev/null
Garbage collection statistics:
  heap size:176.31 MiB
  allocated:2107.82 MiB
  GC times: 52
  time spent in GC: 5.26 seconds (23% of user time)

real0m20.471s
user0m22.605s
sys 0m0.372s

$ time GUIX_PROFILING=gc guix environment pigx-scrnaseq --search-paths 
>/dev/null
Garbage collection statistics:
  heap size:152.31 MiB
  allocated:1367.16 MiB
  GC times: 40
  time spent in GC: 3.25 seconds (21% of user time)

real0m14.701s
user0m15.698s
sys 0m0.361s
--8<---cut here---end--->8---

But why was it occurring before? The only I thing I can think of is that
I didn't have everything in the store first. Is there a way I can prune
just the relevant items from the store to test this?

>
> It’s not the end of the road, but it should be an improvement.
>
> Thanks,
> Ludo’.

--
Sarah

bug#49582: [PATCH] gnu: Add tosdr-chromium.

[Sarah Morgensen]

Hi,

Apologies, I didn't see this patch when I sent my previous reply.

This patch applies and builds, but the bulk of my previous suggestions
remain.

Justin Veilleux  writes:

> this patch adds the tos;dr initiative's extension
>
> From c6881b9b065cf2a85b604c8a1e5ddbae77822034 Mon Sep 17 00:00:00 2001
> From: terramorpha 
> Date: Thu, 15 Jul 2021 14:03:19 -0400
> Subject: [PATCH] gnu: Add tosdr-chromium.
>
> * gnu/packages/browser-extensions.scm (tosdr, tosdr-chromium): New variables.
> ---
>  gnu/packages/browser-extensions.scm | 50 -
>  1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/browser-extensions.scm 
> b/gnu/packages/browser-extensions.scm
> index a6120baf96..7a1a5bda69 100644
> --- a/gnu/packages/browser-extensions.scm
> +++ b/gnu/packages/browser-extensions.scm
> @@ -1,5 +1,6 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2020, 2021 Marius Bakke 
> +;;; Copyright © 2021 Justin Veilleux 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -21,10 +22,14 @@
>#:use-module (guix git-download)
>#:use-module (guix build-system copy)
>#:use-module (guix build-system gnu)
> +  #:use-module (guix build-system trivial)
>#:use-module ((guix licenses) #:prefix license:)
>#:use-module (gnu build chromium-extension)
>#:use-module (gnu packages compression)
> -  #:use-module (gnu packages python))
> +  #:use-module (gnu packages python)
> +  #:use-module (gnu packages base)
> +  #:use-module (gnu packages bash)
> +  #:use-module (gnu packages node))
>  
>  (define play-to-kodi
>(package
> @@ -121,3 +126,46 @@ ungoogled-chromium.")
>  
>  (define-public ublock-origin/chromium
>(make-chromium-extension ublock-origin "chromium"))
> +
> +(define tosdr
> +  (package
> +(name "tosdr")
> +(version "4.1.1")
> +(source
> + (origin
> +   (uri
> +(git-reference
> + (url "https://github.com/tosdr/browser-extensions.git;)
> + (commit version)))
> +   (sha256
> +(base32 "0wz31f9rz087yw1a7cdhdgqvgnhbk569jywv846n122m4bpk3yw0"))
> +   (method git-fetch)))
> +(inputs
> + `(("bash" ,bash)
> +   ("coreutils" ,coreutils)
> +   ("node" ,node)
> +   ("zip" ,zip)
> +   ("unzip" ,unzip)))
> +(arguments
> + `(#:builder
> +   (begin
> + (use-modules (guix build utils))
> + (set-path-environment-variable "PATH"
> + '("bin")
> + (map cdr %build-inputs))

Also, these should be spaces, not tabs.

> + (copy-recursively (assoc-ref %build-inputs "source") ".")
> + (invoke "sh" "./build.sh")
> + (invoke "unzip" "dist/chrome.zip" "-d" %output)
> + #t)
> +   #:modules ((guix build utils
> +(build-system trivial-build-system)
> +(synopsis "extension to inform of the important aspects of the terms and
> +conditions of a web service")
> +(description "This extension informs you instantly of your rights online 
> by
> +showing an unintrusive icon in the toolbar. You can click on this icon to get
> +summaries from the Terms of Service; Didn't Read initiative.")
> +(license license:agpl3)
> +(home-page "https://tosdr.org/;)))
> +
> +(define-public tosdr-chromium
> +  (make-chromium-extension tosdr))

--
Sarah

bug#30287: Go compiler tries writing to the store

[Sarah Morgensen]

Closing this as it seems this is no longer an issue with the go versions
currently packaged.

Sarah Morgensen  writes:

> Hello,
>
> Looking through old Go bugs I found this. Is this still an issue for
> anyone? I just tested with go@1.14 and go@1.16 and I got expected
> behavior (binary was installed in ~/go/bin, since ~/go is the default
> GOPATH).
>
> Leo Famulari  writes:
>
>> On Mon, Jan 29, 2018 at 10:50:10AM +0100, Peter Mikkelsen wrote:
>>> Hi guix,
>>
>> Hi, thanks for this report! I saw your brief conversation on #guix with
>> civodul. Unfortunately I've only been paying attention to packaging Go
>> software with Guix, so I didn't notice this issue.
>>
>>> For example, after setting the environment variable GOPATH to
>>> /home/peter/go, and creating a small hello world program in there, I
>>> would normally be able to run 'go install' in that folder, and the
>>> hello world binary would end up in my gopath. But on guixSD this is
>>> not the case, since it seems like 'go install' is trying to compile
>>> every single library provided by to go package itself, and that means
>>> writing to the store, which is not possible.
>
> --
> Sarah

bug#49063: GNOME Music fails to start

[Sarah Morgensen]

Hello Guix,

I am able to reproduce this with guix c3c003b and GNOME Music 3.34.5. I also
get some GDBus errors, but perhaps that's because my desktop is XFCE?

--8<---cut here---start->8---
$ gnome-music
removed, grl-bookmarks
invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.UDisks2VolumeMonitor:: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gtk.vfs.UDisks2VolumeMonitor was not provided by any .service files 
(g-dbus-error-quark, 2)
invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.AfcVolumeMonitor:: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gtk.vfs.AfcVolumeMonitor was not provided by any .service files 
(g-dbus-error-quark, 2)
invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.GPhoto2VolumeMonitor:: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gtk.vfs.GPhoto2VolumeMonitor was not provided by any .service files 
(g-dbus-error-quark, 2)
invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.MTPVolumeMonitor:: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gtk.vfs.MTPVolumeMonitor was not provided by any .service files 
(g-dbus-error-quark, 2)
invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.GoaVolumeMonitor:: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gtk.vfs.GoaVolumeMonitor was not provided by any .service files 
(g-dbus-error-quark, 2)
removed, grl-metadata-store
removed, grl-filesystem
removed, grl-podcasts
Traceback (most recent call last):
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/bin/..gnome-music-real-real",
 line 153, in 
sys.exit(main())
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/bin/..gnome-music-real-real",
 line 148, in main
return run_application()
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/bin/..gnome-music-real-real",
 line 135, in run_application
app = Application('org.gnome.Music')
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/application.py",
 line 70, in __init__
self._player = Player(self)
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/player.py",
 line 397, in __init__
self._gst_player = GstPlayer(application)
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/gstplayer.py",
 line 86, in __init__
self._setup_replaygain()
  File 
"/gnu/store/rkhkqv9lvww40nqs25i8fmwf4870xsvw-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/gstplayer.py",
 line 111, in _setup_replaygain
self._filter_bin.add(self._rg_volume)
TypeError: Argument 1 does not allow None as a value
--8<---cut here---end--->8---

Luis Felipe  writes:

> Hi, this happens on Guix System, using Guix 154a4e0 and GNOME Music 3.34.5.
>
> STEPS TO REPRODUCE
>
> 1. Click on Activities
> 2. Click on Show Apps button (nine dots button)
> 3. Click on the Music app
>
> EXPECTED RESULT
>
> The application starts.
>
> UNEXPECTED RESULT
>
> You can see the application icon displayed next to the GNOME Activities 
> button with a loading indicator. But, after some seconds, it disappears and 
> the application never starts.
>
> ADDITIONAL INFO
>
> Running the application from a terminal results in the following error:
>
> 
> $ gnome-music
> removed, grl-bookmarks
> removed, grl-metadata-store
> removed, grl-filesystem
> Traceback (most recent call last):
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/bin/..gnome-music-real-real",
>  line 153, in 
> sys.exit(main())
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/bin/..gnome-music-real-real",
>  line 148, in main
> return run_application()
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/bin/..gnome-music-real-real",
>  line 135, in run_application
> app = Application('org.gnome.Music')
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/application.py",
>  line 70, in __init__
> self._player = Player(self)
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/player.py",
>  line 397, in __init__
> self._gst_player = GstPlayer(application)
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/gstplayer.py",
>  line 86, in __init__
> self._setup_replaygain()
>   File 
> "/gnu/store/v9vs6yai5dlyf5avly5ni3xxpk7xhfv0-gnome-music-3.34.5/lib/python3.8/site-packages/gnomemusic/gstplayer.py",
>  line 111, in _setup_replaygain
>  

bug#49125: python-gitdb upgrade hangs after executing "guix pull && guix refresh"

[Sarah Morgensen]

Hello,

Thanks for the bug report.

Emad Alblueshi  writes:

> Hi, 
>
> python-gitdb upgrade hangs after executing "guix pull && guix refresh"
>
> The attached file contains the full log
>
> Best regards
>
> ➜  ~ guix pull && guix refresh

Are you still experiencing this issue?  If so, can you try 'hash guix'
after the pull and before the refresh?  (Without 'hash guix' to tell the
shell where to find the new 'guix', the second command might be invoking
the old 'guix'.)

Or, if you're no longer experiencing this issue, do you have an idea of
what fixed it?

--
Sarah

bug#49233: gmnisrv: missing mime.types

[Sarah Morgensen]

Hello,

Christopher Howard  writes:

> Hi, I am trying to use the gmnisrv service as described in the Guix
> manual, using the default configuration:
>
>  (services
>   (append
>(list (service gmnisrv-service-type)
>(service openssh-service-type)
>(service network-manager-service-type)
>(service wpa-supplicant-service-type))
>%base-services))
>
> However, gmnisrv keeps dying with this error:
>
> gmnisrv: src/mime.c:37: mime_init: Assertion `0' failed.
> Unable to open MIME database for reading: No such file or directory
> Is /etc/mime.types installed?
>
> Is the gmnisrv package or service missing a dependency that is supposed to 
> provide the mime.types file, or am I supposed to copy one from somewhere?

It turns out that the gmnisrv package was misconfigured so that it was
necessary to have /etc/mime.types present. I've submitted a patch at

  https://issues.guix.gnu.org/49705

to fix that (as well as not looking for /etc/gmnisrv.conf if present) if
you would like to test it before it makes it into master.

>
> My system information:
>
> christopher@galadriel ~$ neofetch --stdout
> christopher@galadriel 
> - 
> OS: Guix System b36267b1d96ac344d2b42c9822ce04b4c3117f85 x86_64 
> Host: OptiPlex 7010 01 
> Kernel: 5.12.13-gnu 
> Uptime: 24 mins 
> Packages: 51 (guix-system), 35 (guix-user) 
> Shell: bash 5.0.16 
> Terminal: /dev/pts/0 
> CPU: Intel i5-3570 (4) @ 3.800GHz 
> GPU: Intel HD Graphics 
> Memory: 93MiB / 15929MiB 

--
Sarah

bug#49314: Stan package broken

[Sarah Morgensen]

Hello,

Thanks for the bug report.

Kyle Andrews  writes:

[...]

> #+BEGIN_EXAMPLE
> Error in dyn.load(libLFile) : 
>   unable to load shared object '/tmp/Rtmp1AXXXr/file1ffd36a95fa3.so':
>   
> /gnu/store/741057r2x06zwg6zcmqmdyv51spm6n9i-gfortran-7.5.0-lib/lib/libstdc++.so.6:
>  version `GLIBCXX_3.4.29' not found (required by 
> /tmp/Rtmp1AXXXr/file1ffd36a95fa3.so)

This kind of error typically occurs when something is compiled with a
newer version of GCC/glibc and then linked with an older version. Do you
happen to have a gcc or gcc-toolchain installed in your profile (and
does removing it solve this issue)?

> Error in sink(type = "output") : invalid connection
> #+END_EXAMPLE
>
> I setup my environment with:
>
> : guix environment --ad-hoc r-rstan r-rstanarm r

Alternatively, you could try

  guix environment --pure --ad-hoc r-rstan r-rstanarm r bash coreutils

(Using --pure prevents packages from your profile being used.)

--
Sarah

bug#49439: grafts cause “guix environment” to get killed with OOM

[Sarah Morgensen]

Hello,

Ricardo Wurmus  writes:

> With a recent version of Guix, “guix environment” will not 
> terminate on its own, keeps the CPU busy, and gets killed when the 
> system eventually runs out of memory.
>
> $ guix describe -f channels
>
> (list (channel
> (name 'guix)
> (url "/home/rekado/dev/gx/branches/master")
> (commit
>   "685cfdec94e5e48c4ad28de53466a28dfc258edb")))
>
>
> $ guix environment pigx-scrnaseq
> [wait until it gets killed]

I can reproduce this with pigx-scrnaseq as well a number of other
packages (listed below).

$ ./pre-inst-env guix describe -f channels
(list (channel
(name 'guix)
(url "/home/sarah/guix")
(commit
  "3217a04b0352c2dd13323257b369604eeabfccc3")))

Does not complete within 5 minutes:
package# inputs  # transitive inputs
 (from package-transitive-inputs)
pigx-chipseq   48338
pigx-scrnaseq  41321
r-cellchat 34110
pigx-rnaseq34343
pigx-bsseq 32358
pigx-sars-cov2-ww  25261
r-circus   16134

Does complete:
r-chipseq  6 37 completes in >2m
r-shortread1736 completes in >1m
python-scanpy  25113completes in <15s

I suspect it has something to do with the number of transitive inputs,
because it is so prevalent with these R packages, which all use
propagated inputs. However... python-scanpy succeeds in under 15
seconds, and it has more transitive inputs than r-chipseq.

Can we reproduce this with a large number of low-transitivity packages
directly on the command line?

>
> The problem disappears when grafts are disabled:
>
> $ guix environment --no-grafts pigx-scrnaseq
> $ [env] yay!

--
Sarah

bug#49613: On WSL1/2, guix install: error: cannot kill processes for uid `999': failed with exit code 1

[Sarah Morgensen via Bug reports for GNU Guix]

Hello Guix,

Anadon  writes:

> Talking with iskarian on IRC, we've confirmed that guix successfully
> installs, almost successfully sets up (the init.d isn't set up to
> actually daemonize), but for `guix build`, `guix install` and `guix
> pull` all fail with "guix : error: cannot kill processes for
> uid `998': failed with exit code 1" when using WSL1/2.

I've investigated this a bit and it seems to be an issue with the return
code from `kill` when no other processes owned by that user exist to
kill. If I set a process to continually spawn with uid 998, I no longer
encounter the above error. Also, if there is a zombie process under that
uid, I no longer encounter the above error until I manually kill it.
This is on WSL1; I do not know if this technique also applies to WSL2.

For reference, the relevant portion of `nix/libutil/util.cc`:

--8<---cut here---start->8---
Pid pid = startProcess([&]() {

if (setuid(uid) == -1)
throw SysError("setting uid");

while (true) {
#ifdef __APPLE__
/* OSX's kill syscall takes a third parameter that, among
   other things, determines if kill(-1, signo) affects the
   calling process. In the OSX libc, it's set to true,
   which means "follow POSIX", which we don't want here
 */
if (syscall(SYS_kill, -1, SIGKILL, false) == 0) break;
#elif __GNU__
/* Killing all a user's processes using PID=-1 does currently
   not work on the Hurd.  */
if (kill(getpid(), SIGKILL) == 0) break;
#else
if (kill(-1, SIGKILL) == 0) break;
#endif
if (errno == ESRCH) break; /* no more processes */
if (errno != EINTR)
throw SysError(format("cannot kill processes for uid `%1%'") % 
uid);
}

_exit(0);
});

int status = pid.wait(true);
#if __GNU__
/* When the child killed itself, status = SIGKILL.  */
if (status == SIGKILL) return;
#endif
if (status != 0)
throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % 
statusToString(status));
--8<---cut here---end--->8---

Perhaps the way WSL handles the return code for ``kill` is not as
expected? On a cursory inspection, though, the relevant parts of WSL2's
kernel/signal.c seem the same as the vanilla Linux kernel...

Or perhaps for some reason `kill(-1, SIGKILL)` under WSL is attempting
to kill the calling process (why?) and failing, therefore returning an
error.

Note that the error code 1 reported by Guix does not seem to be the
actual errno reported by `kill`.

I've seen Guix working on WSL2 in the wild before [0] so this is a
really odd error. I'm stumped.

[0] 
https://github.com/giuliano108/guix-packages/blob/master/notes/Guix-on-WSL2.md

--
Sarah

bug#39400: Go retains a reference to GCC

[Sarah Morgensen via Bug reports for GNU Guix]

Hi,

Ludovic Courtès  writes:

>> Go invokes gcc when compiling with cgo, and cgo (or at least the usage
>> of standard libraries which use cgo) is getting fairly common. If we do
>> not provide a default gcc with Go, a plain "go build" will produce an
>> error if it encounters something which uses cgo and it can't find gcc:
>>
>> $ go build
>> # runtime/cgo
>> cgo: exec gcc: exec: "gcc": executable file not found in $PATH
>
> Ah, I didn’t know about cgo (a helper for C bindings, right?).

Yes, cgo allows you to compile Go programs which interface with C, as
well as straight .c files.

>
> I think it’s a case where “dynamic composition” (i.e., looking for gcc
> in $PATH at run time) is preferable, because there are lots of
> situations where gcc is not needed at all.
>
> [...]
>
>> I have experimented with a couple ways of removing the gcc-7.5.0 reference:
>>
>> 1. Simply set CC=gcc. This works to remove gcc-7.5.0 from references,
>> but we still get a gcc-7.5.0-lib runpath. We can't remove this runpath
>> completely, as anything using cgo-enabled parts of the standard library
>> require it, and Go does not save the library location anywhere.
>
> Sounds good to me.  (gcc-7.5.0-lib is always in the RUNPATH of
> executables, we don’t have to worry about this one.)

I recently discovered that there is actually an issue with this
particular approach. If the user uses a newer gcc-toolchain, the
always-added gcc-7.5.0-lib shadows the newer libraries and newer symbols
are unavailable. See .

>
>> 2. Make Go require external linking for anything using cgo, which would
>> remove the need to patch internal linking at all. Some platforms do not
>> support internally linking cgo at all, so Go should have no trouble
>> handling this. It does break some tests which expect to be able to
>> internally link, but I have not yet found any actual packages it breaks.
>
> What do you mean by “external linking” and “internal linking” in this
> context?  (I know very little about Go.)

"external linking" => Go invokes gcc to link object files together
"internal linking" => Go does the linking itself

--
Sarah

bug#39400: Go retains a reference to GCC

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

A quick addendum...

Sarah Morgensen  writes:

> This means that even if the user provides a different CC, the
> gcc-7.5.0-lib dir will also be in the runpath. I do not know if, or how
> much, this would conflict with other gcc-lib runpaths.
>

I have just seen the consequences of this: the binary is unable to load
symbols from the newer library. More info at
<https://issues.guix.gnu.org/36823>.

> I have experimented with a couple ways of removing the gcc-7.5.0 reference:
>
> 1. Simply set CC=gcc. This works to remove gcc-7.5.0 from references,
> but we still get a gcc-7.5.0-lib runpath. We can't remove this runpath
> completely, as anything using cgo-enabled parts of the standard library
> require it, and Go does not save the library location anywhere.
>

--
Sarah

bug#49427: grpc build failure

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Thanks for taking the time to file a report! (Even if it turned out to be
a non-issue)

Andy Tai  writes:

> Never mind; after a new
>
> guix pull
>
>
> this no longer happens.  Please close this bug

For future reference, to close a bug you can address your mail to
nnn-d...@debbugs.gnu.org, where nnn is the bug number in your
confirmation, as I have done with this mail.

>> > If you wish to submit further information on this problem, please
>> > send it to 49...@debbugs.gnu.org.
^

--
Sarah

bug#49350: gcc-toolchain compilation error with -nostdinc++

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Thanks for the report.

Ontje Lünsdorf  writes:

> Hi all,
>
>
> I've problems compiling LLVM manually with the gcc-toolchain.
> sanitizer_posix_libcdep.cpp is build with -nostdinc++ and fails to find
> bits/c++config.h.
>
> I think the issue can be reproduced with this example test.cpp:
>
> #include 
> int main() { return 0; }

I am able to repro with this test case on Guix System, both in and
outside of a guix environment --pure.

>
> c++ from archlinux compiles that file, while c++ from gcc-toolchain doesn't:
>
> $ c++ -nostdinc++ test.cpp
> $ guix environment --ad-hoc gcc-toolchain -- c++ -nostdinc++ test.cpp
> In file included from 
> /gnu/store/nh9r04xhzmbk3hjsj92yhlhmjsp521g4-profile/include/c++/stdlib.h:36,
>  from test.cpp:1:
> /gnu/store/nh9r04xhzmbk3hjsj92yhlhmjsp521g4-profile/include/c++/cstdlib:41:10:
>  fatal error: bits/c++config.h: No such file or directory
>41 | #include 
>   |  ^~
> compilation terminated.
>
> Is this expected and I'm doing something wrong?

The issue seems to be with the (automatically set by Guix)
CPLUS_INCLUDE_PATH environment variable. The following works as
expected:

  guix environment --pure --ad-hoc gcc-toolchain -- CPLUS_INCLUDE_PATH= c++ 
-nostdinc++ test.cpp

It seems that -nostdinc++ controls whether GCC decides to add the C++
std include paths internally, but it still looks in the paths indicated
by CPLUS_INCLUDE_PATH. Guix sets CPLUS_INCLUDE_PATH and friends because
there is no system-wide /include. I'm not sure how expected this
specific behavior is, though...

>
> Thanks & best regards,
> Ontje

Hope that helps,
Sarah

bug#48111: tilde in Go package names (eg. sourcehut hosted packages)

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Leo Prikler  writes:

> Am Donnerstag, den 29.04.2021, 19:54 +0200 schrieb raingloom:
>> Trying to import kineto and getting this error when building it:
>> 
>> guix build: error: invalid character `~' in name
>> `go-git-sr-ht-~sircmpwn-kineto-0.0.0-20210225135222-edd4fe31f16f-
>> checkout.drv'
>> 
>> I know the names are significant in go-build-system so I'm not sure
>> how
>> to work around the issue without breaking anything.

As far as I can tell, the go-build-system doesn't care about the actual
package names, just #:import-path and #:unpack-path. The names should
only be significant to the go importer insofar as
go-module->guix-package-name does not generate collisions.

> The way Go works, I would hazard a guess, that 
>   module git.sr.ht/~sircmpwn/kineto
> and 
>   module git.sr.ht/sircmpwn/kineto
> name two different modules.  However, as the latter can't exist since
> sr.ht prefixes user names with ~, I think a name transformation, that
> maps the former to the latter should be safe.  On the other hand, since
> this just affects store file names, we might instead want to map "~" to
> "-" in the general case of it appearing anywhere.  WDYT?

It might be slightly uglier, but I think it's better to keep a
consistent policy of "replace any invalid characters with a hyphen", as
it is less likely to generate collisions and it provides a hint to the
reader that there *is* a character there.

I have attached a patch to do so below, verified that a recursive import
of the package mentioned above builds without modification (well, I had
to update a dependency...) and verified that there are not currently any
go packages using a tilde in their name with:

$ egrep -r '"go-[^"]*~[^"]*"' gnu/packages

>From 2c942a06cf94acdca07f2a59736c89521953af0f Mon Sep 17 00:00:00 2001
Message-Id: <2c942a06cf94acdca07f2a59736c89521953af0f.1625436903.git.iskar...@mgsn.dev>
From: Sarah Morgensen 
Date: Sun, 4 Jul 2021 15:00:15 -0700
Subject: [PATCH] import: go: Replace tildes with hyphens in package names.

Fixes <https://issues.guix.gnu.org/48111>.

* guix/import/go.scm (go-module->guix-package-name): Replace tildes with
hyphens.
---
 guix/import/go.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index 5e23d6a2b3..d8f838f635 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -430,9 +430,9 @@ hence the need to derive this information."
 (define* (go-module->guix-package-name module-path #:optional version)
   "Converts a module's path to the canonical Guix format for Go packages.
 Optionally include a VERSION string to append to the name."
-  ;; Map dot, slash and underscore characters to hyphens.
+  ;; Map dot, slash, underscore and tilde characters to hyphens.
   (let ((module-path* (string-map (lambda (c)
-(if (member c '(#\. #\/ #\_))
+(if (member c '(#\. #\/ #\_ #\~))
 #\-
 c))
   module-path)))

base-commit: 9e63bafafbe7a7c2d9804fae62302ac8a7e90090
-- 
2.31.1


--
Sarah

bug#36823: gcc bug prevents go program from starting newer gcc results in race condition

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Thanks for the report.

Malte Frank Gerdes  writes:

> Hi,
>
> The precompiled version of Hugo-extended was not able to find some
> runtime dependencies:
>libstdc++.so.6  => not found
>libgcc_s.so.1   => not found

In case you haven't discovered this in the past two years (oops), this
is because Guix does not typically work with pre-compiled software that
relies on system libraries being in /lib, since there is no system-wide
/lib.

> This seems like a version mismatch to me, so i built Hugo with the
> following command:
>   go build --tags extended
>
> Now the error is ( = ypiv8dj4lkvsnm82s639h18l87frrh5g):
>   /gnu/store/-gcc-6.5.0-lib/lib/libstdc++.so.6: version
>   `GLIBCXX_3.4.26' not found

If I build hugo with gcc-toolchain@7 in my user profile, it works fine.
However I can still repro this issue with gcc-toolchain@8+:

$ go build --tags extended
$ ./hugo --help
./hugo: 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
version `GLIBCXX_3.4.26' not found (required by ./hugo)
./hugo: 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
version `GLIBCXX_3.4.29' not found (required by ./hugo)

This is because gcc 7's libraries are shadowing the newer gcc's
libraries:

$ readelf -d hugo | grep RUNPATH
 0x001d (RUNPATH)Library runpath: 
[/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib:/home/sarah/.guix-profile/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.1.0/../../..]

If I use patchelf to remove the gcc 7 library dir from RUNPATH, hugo
works fine. This is because Go is patched to unconditionally add a
runpath to gcc 7's libraries but erroneously does not explicitly set
CXX. (See also .)

The following patch should explicitly set CXX for Go, so that it always
uses the "system" version:

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 0318918a37..a27f57aa30 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -395,6 +395,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
;; FIXME: Some of the .a files are not bit-reproducible.
(let* ((output (assoc-ref outputs "out")))
  (setenv "CC" (which "gcc"))
+ (setenv "CXX" (which "g++"))
  (setenv "GOOS" "linux")
  (setenv "GOROOT" (dirname (getcwd)))
  (setenv "GOROOT_FINAL" output)
@@ -577,6 +578,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
   (loader (string-append (assoc-ref inputs "libc")
  ,(glibc-dynamic-linker
  (setenv "CC" (which "gcc"))
+ (setenv "CXX" (which "g++"))
  (setenv "GO_LDSO" loader)
  (setenv "GOOS" "linux")
  (setenv "GOROOT" (dirname (getcwd)))

Hope that helps,
Sarah

bug#39400: Go retains a reference to GCC

[Sarah Morgensen via Bug reports for GNU Guix]

Hello all,

(I have CC'd Tobias since we briefly discussed this on #guix recently.)

Ludovic Courtès  writes:

> Hello!
>
> It seems that Go unduly retains a reference to GCC:
>
> $ guix size go
> store item   totalself
> /gnu/store/g4rrz9rnr8ssbnj3gx3dmsxv4glll8nf-go-1.12.15 646.3   
> 355.9  55.1%
> /gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0  177.4   
> 107.2  16.6%
> [...]

This is still the case:

$ guix size go
store item   totalself
/gnu/store/vvly7zgn981brb37v8y8a7f9psx7c6ay-go-1.16.5  570.0   
371.5  65.2%
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0  178.5   
107.3  18.8%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31  38.4
36.7   6.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib   71.0
32.6   5.7%
/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32  88.0
17.0   3.0%
/gnu/store/kl68v5mclwp511xgpsl2h1s9gmsdxpzh-tzdata-2021a 1.9 
1.9   0.3%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16   1.6 
1.6   0.3%
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16 39.4 
1.0   0.2%
/gnu/store/g2s5jfkfd4k973wb58476b1bbv9zpm6m-zlib-1.2.11 38.6 
0.2   0.0%
/gnu/store/zfbbn61ij7w0bl4wbrwi87x5ghqx968c-net-base-5.3 0.0 
0.0   0.0%
total: 570.0 MiB

But... is the "baking-in" of (a particular version of) GCC a bad thing?
I am not sure either way.

Go invokes gcc when compiling with cgo, and cgo (or at least the usage
of standard libraries which use cgo) is getting fairly common. If we do
not provide a default gcc with Go, a plain "go build" will produce an
error if it encounters something which uses cgo and it can't find gcc:

$ go build
# runtime/cgo
cgo: exec gcc: exec: "gcc": executable file not found in $PATH

The user would then have to either install a gcc-toolchain, or figure
out that they must set CGO_ENABLED=0. From this perspective, it is more
convenient to have GCC baked-in for the average user, who likely has no
reason to want a different CC anyway.

On the other hand, currently GCC is baked-in to Go in two ways:

* CC is set to /gnu/store/...-gcc-7.5.0/bin/gcc
* Go is patched so that it adds /gnu/store/...-gcc-7.5.0-lib/lib as a
runpath when linking with cgo files

This means that even if the user provides a different CC, the
gcc-7.5.0-lib dir will also be in the runpath. I do not know if, or how
much, this would conflict with other gcc-lib runpaths.

I have experimented with a couple ways of removing the gcc-7.5.0 reference:

1. Simply set CC=gcc. This works to remove gcc-7.5.0 from references,
but we still get a gcc-7.5.0-lib runpath. We can't remove this runpath
completely, as anything using cgo-enabled parts of the standard library
require it, and Go does not save the library location anywhere.

2. Make Go require external linking for anything using cgo, which would
remove the need to patch internal linking at all. Some platforms do not
support internally linking cgo at all, so Go should have no trouble
handling this. It does break some tests which expect to be able to
internally link, but I have not yet found any actual packages it breaks.

My instinct says that removing the reference, and doing so via #2, is
the way to go, but I am just a newcomer to Guix. WDYT?

--
Sarah

bug#30287: Go compiler tries writing to the store

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Looking through old Go bugs I found this. Is this still an issue for
anyone? I just tested with go@1.14 and go@1.16 and I got expected
behavior (binary was installed in ~/go/bin, since ~/go is the default
GOPATH).

Leo Famulari  writes:

> On Mon, Jan 29, 2018 at 10:50:10AM +0100, Peter Mikkelsen wrote:
>> Hi guix,
>
> Hi, thanks for this report! I saw your brief conversation on #guix with
> civodul. Unfortunately I've only been paying attention to packaging Go
> software with Guix, so I didn't notice this issue.
>
>> For example, after setting the environment variable GOPATH to
>> /home/peter/go, and creating a small hello world program in there, I
>> would normally be able to run 'go install' in that folder, and the
>> hello world binary would end up in my gopath. But on guixSD this is
>> not the case, since it seems like 'go install' is trying to compile
>> every single library provided by to go package itself, and that means
>> writing to the store, which is not possible.

--
Sarah

bug#49228: guix import go fails when module does not have a documenation on pkg.go.dev

[Sarah Morgensen via Bug reports for GNU Guix]

Hi,

raingloom  writes:

>> If you look at the page
>> 
>> https://pkg.go.dev/github.com/caspr-io/yamlpath
>> 
>> It has no Description, because the site cannot parse license
>> information correctly and thus conservatively does not display any
>> info.
>
> Could we use godocs.io? It's more copyleft friendly AFAIK.
> But that's just hearsay, I'm only getting into Go now, so idk much
> about the services surrouding it yet.

Right now the information from pkg.go.dev is used to populate the package's
  * synopsis
  * description, and
  * license
sections.

As far as I can tell, godocs.io does not have any information about the
package's license... *eventually* we may want to consider writing a
license guesser of our own, as that could potentially be useful across
all of Guix.

As for description, godocs.io seems to collects description information
differently (inferiorly?) than pkg.go.dev. For example, compare:

  https://godocs.io/github.com/mitchellh/go-homedir
  https://pkg.go.dev/github.com/mitchellh/go-homedir

I wonder how complicated it would be to guess at a synopsis/description
ourselves? It may be worth asking the initial committers of the go
importer.

--
Sarah

bug#49228: guix import go fails when module does not have a documenation on pkg.go.dev

[Sarah Morgensen via Bug reports for GNU Guix]

Hello,

Thanks for the report.

Björn Höfling  writes:

> $ ./pre-inst-env guix import go github.com/caspr-io/yamlpath 
> [...]
> ice-9/eval.scm:619:8: Throw to key `match-error' with args `("match" "no 
> matching pattern" #f)'.
>
> If you look at the page
>
> https://pkg.go.dev/github.com/caspr-io/yamlpath
>
> It has no Description, because the site cannot parse license
> information correctly and thus conservatively does not display any info.

There is currently a patch for this (mine; though I could have named it
better, I suppose):

https://issues.guix.gnu.org/49200

> Additionally, it would be nice if the go-module->guix-package would
> print out the module it would fetch next (like I did above). Then the
> broken module would be easier to find in recursive mode.

Error reporting in the importers is currently pretty inconsistent and
could use a lot of improvement. You might be interested in taking a look
at the PATCH v3 in  which somewhat
addresses this. Comments are always welcome! :)

Sarah

bug#49202: guix import go type error (failed regex match?)

[Sarah Morgensen via Bug reports for GNU Guix]

Sarah Morgensen  writes:

>
> // When updating replace rules, make sure to also update the rules in 
> integration/client/go.mod
> replace (
>   // prevent transitional dependencies due to containerd having a circular
>   // dependency on itself through plugins. see .empty-mod/go.mod for 
> details
>   github.com/containerd/containerd => ./.empty-mod/
>   github.com/gogo/googleapis => github.com/gogo/googleapis v1.3.2
>   // urfave/cli must be <= v1.22.1 due to a regression: 
> https://github.com/urfave/cli/issues/1092
>   github.com/urfave/cli => github.com/urfave/cli v1.22.1
>   google.golang.org/genproto => google.golang.org/genproto 
> v0.0.0-20200224152610-e50cd9704f63
> )
>
> Based on the trace it seems like it's treating the k8s.io/utils require
> as a replace directive, but I have no idea why.
>

Looking at this again, I realize I misread the code: the "k8s.io/utils"
etc. is actually the head of the already-parsed requirements list.

Instead, when the error is thrown, we are in replace-directive, which is
called by in-replace...

--8<---cut here---start->8---
  (define (in-replace requirements replaced)
(let ((line (read-line)))
  (cond
   ((eof-object? line)
;; this should never happen here but we ignore silently
(values requirements replaced))
   ((string=? line ")")
;; end of block, coming back to toplevel
(toplevel requirements replaced))
   (#t
(call-with-values (lambda ()
(replace-directive requirements replaced line))
  in-replace)
--8<---cut here---end--->8---

...which does not handle comments. (Even the top-level parser doesn't
explicitly handle comments, it just discards any line that does not
start with "require" or "replace.")

Looks like the parser could use a little more robustness! :)

Hope that helps,
Sarah

bug#49202: guix import go type error (failed regex match?)

[Sarah Morgensen via Bug reports for GNU Guix]

zimoun  writes:

> Hi,
>
> Thanks for the report.
>
> On Thu, 24 Jun 2021 at 02:11, raingloom  wrote:
>
>> When I run
>> guix import go -r github.com/golang-migrate/migrate/v4
>> it works for a looong time (something else to work on I guess. maybe
>> fetching every git repo is not the best solution.) and then gives this
>> error:
>>
>> In procedure vector-ref: Wrong type argument in position 1 (expecting
>> vector): #f
>
> I seems to work without the option recursive '-r'.  So, I guess it is
> related to the patch [1] and issues with the recursive importers, see
> [2].

I do not think it is related to recursive import... I was able to narrow
down the repro to

guix import go github.com/containerd/containerd

with the same trace. The offending go.mod:

--8<---cut here---start->8---
module github.com/containerd/containerd

go 1.16

require (
github.com/Microsoft/go-winio v0.5.0
github.com/Microsoft/hcsshim v0.8.17
github.com/containerd/aufs v1.0.0
github.com/containerd/btrfs v1.0.0
github.com/containerd/cgroups v1.0.1
github.com/containerd/console v1.0.2
github.com/containerd/continuity v0.1.0
github.com/containerd/fifo v1.0.0
github.com/containerd/go-cni v1.0.2
github.com/containerd/go-runc v1.0.0
github.com/containerd/imgcrypt v1.1.1
github.com/containerd/nri v0.1.0
github.com/containerd/ttrpc v1.0.2
github.com/containerd/typeurl v1.0.2
github.com/containerd/zfs v1.0.0
github.com/containernetworking/plugins v0.9.1
github.com/coreos/go-systemd/v22 v22.3.2
github.com/davecgh/go-spew v1.1.1
github.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c
github.com/docker/go-metrics v0.0.1
github.com/docker/go-units v0.4.0
github.com/emicklei/go-restful v2.9.5+incompatible
github.com/fsnotify/fsnotify v1.4.9
github.com/gogo/googleapis v1.4.0
github.com/gogo/protobuf v1.3.2
github.com/google/go-cmp v0.5.5
github.com/google/uuid v1.2.0
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0
github.com/hashicorp/go-multierror v1.0.0
github.com/imdario/mergo v0.3.11
github.com/klauspost/compress v1.11.13
github.com/moby/locker v1.0.1
github.com/moby/sys/mountinfo v0.4.1
github.com/moby/sys/symlink v0.1.0
github.com/opencontainers/go-digest v1.0.0
github.com/opencontainers/image-spec v1.0.1
github.com/opencontainers/runc v1.0.0
github.com/opencontainers/runtime-spec 
v1.0.3-0.20210326190908-1c3f411f0417
github.com/opencontainers/selinux v1.8.2
github.com/pelletier/go-toml v1.8.1
github.com/pkg/errors v0.9.1
github.com/prometheus/client_golang v1.7.1
github.com/prometheus/procfs v0.6.0 // indirect; temporarily force 
v0.6.0, which was previously defined in imgcrypt as explicit version
github.com/satori/go.uuid v1.2.0 // indirect
github.com/sirupsen/logrus v1.8.1
github.com/stretchr/testify v1.6.1
github.com/tchap/go-patricia v2.2.6+incompatible
github.com/urfave/cli v1.22.2
go.etcd.io/bbolt v1.3.5
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110
golang.org/x/sync v0.0.0-20201207232520-09787c993a3a
golang.org/x/sys v0.0.0-20210426230700-d19ff857e887
google.golang.org/grpc v1.38.0
google.golang.org/protobuf v1.26.0
gotest.tools/v3 v3.0.3
k8s.io/api v0.20.6
k8s.io/apimachinery v0.20.6
k8s.io/apiserver v0.20.6
k8s.io/client-go v0.20.6
k8s.io/component-base v0.20.6
k8s.io/cri-api v0.20.6
k8s.io/klog/v2 v2.4.0
k8s.io/utils v0.0.0-20201110183641-67b214c5f920
)

// When updating replace rules, make sure to also update the rules in 
integration/client/go.mod
replace (
// prevent transitional dependencies due to containerd having a circular
// dependency on itself through plugins. see .empty-mod/go.mod for 
details
github.com/containerd/containerd => ./.empty-mod/
github.com/gogo/googleapis => github.com/gogo/googleapis v1.3.2
// urfave/cli must be <= v1.22.1 due to a regression: 
https://github.com/urfave/cli/issues/1092
github.com/urfave/cli => github.com/urfave/cli v1.22.1
google.golang.org/genproto => google.golang.org/genproto 
v0.0.0-20200224152610-e50cd9704f63
)
--8<---cut here---end--->8---

Based on the trace it seems like it's treating the k8s.io/utils require
as a replace directive, but I have no idea why.

>
> 1: 
> 2: 
>
>
> All the best,
> simon

Sarah