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

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

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

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

bug#34417: Ruby is not reproducible

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

bug#34064: openshot 2.4.3 works badly

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

bug#23045: mysql_config missing references to sed and gawk

Fixed by . -- Sarah

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

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

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

x 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

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

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

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

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

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

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,

bug#32691: OpenMolcas

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? &

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ght © 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-k

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

ision "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 E

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

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

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

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

bug#50595: Faliure in guix import go

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

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

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

bug#50595: Failure in guix import go

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

bug#50595: Faliure in guix import go

er, 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,

bug#33615: xonsh build failure

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

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

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 (fortu

bug#32691: OpenMolcas

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

bug#32511: mariadb 10.1.35 fails to build on x86_64

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

bug#31789: nss-mdns test is failing

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

bug#32247: HandBrake shows no icons

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

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

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 >

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

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

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

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

bug#30210: pandoc not reproducible

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

bug#50557: Unable to access remote logs

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

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

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,

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

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

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

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

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

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

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

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

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

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 (_

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

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:

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

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

bug#50433: shotcut 21.06.29 missing bin files

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

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

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

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

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

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

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.

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 "(d

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

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

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

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

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

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):

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

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

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

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

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

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

bug#49815: Upcoming timekeeping failure in gpsd

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 >

bug#49815: Upcoming timekeeping failure in gpsd

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

bug#49916: etc/committer: backtrace on gexp

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

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

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

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

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

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

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

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

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

bug#30287: Go compiler tries writing to the store

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

bug#49063: GNOME Music fails to start

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

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

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

bug#49233: gmnisrv: missing mime.types

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

bug#49314: Stan package broken

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

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

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

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

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

bug#39400: Go retains a reference to GCC

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

bug#39400: Go retains a reference to GCC

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

bug#49427: grpc build failure

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

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

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

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

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

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

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),

bug#39400: Go retains a reference to GCC

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 >

bug#30287: Go compiler tries writing to the store

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

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

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

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

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

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

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

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

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