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
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
>
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-i
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 copylef
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 Mik
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/g4rrz9rnr8
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), t
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.
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:
>
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
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
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
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 f
13 matches
Mail list logo
