Hello,
With R 3.2.2 built from r in statistics.scm (guix 0.9.0), I'm seeing a
segfault when eigen is called with a matrix over some size. I can
trigger the error with the following code [1]:
> M <- 50
> N <- 500
> eigen(crossprod(matrix(rnorm(M * N), M, N)))
*** caught segfault
Ricardo Wurmus writes:
> Kyle Meyer writes:
>
>> With R 3.2.2 built from r in statistics.scm (guix 0.9.0), I'm seeing a
>> segfault when eigen is called with a matrix over some size. I can
>> trigger the error with the following code [1]:
>>
>> &
l...@gnu.org (Ludovic Courtès) writes:
> I can reproduce the bug with:
>
>guix environment --pure --ad-hoc r -- R
[...]
> Might be useful to report it upstream?
Yes. In preparing to do so, I figured that I should reproduce the issue
with a build outside of Guix. However, when I tried with
I've opened an issue in the OpenBLAS repo [1].
https://github.com/xianyi/OpenBLAS/issues/703
I'm trying to answer their questions, but, as is apparent in that
thread, I'm not really familiar with debugging these sorts of problems.
Since others are able to reproduce the error, any help over ther
On 10/07/20 12:35:51 +0200, zimoun wrote:
> Dear,
>
> Using Guix 04a459a, the package ’git-annex’ is not reproducible:
>
> guix build git-annex
> guix build git-annex --no-grafts --check -K
>
> return:
>
> --8<---cut here---start->8---
> guix build: error: de
Ricardo Wurmus writes:
> Importing https://github.com/immunogenomics/scpost with the CRAN
> importer fails, because the git repository does not have an
> origin/master branch. This repository only has a “main” branch.
>
> Arguably, this shouldn’t matter, but (guix git) has the “master” name
> s
Marius Bakke writes:
> Kyle Meyer skriver:
>
>> One option may be to use the remote HEAD symref.
[...]
>> Here's a quick and dirty demo that makes your reproducer work. A real
>> patch in this direction would of course look very different.
>
> Another
Ludovic Courtès writes:
>> (define* (update-cached-checkout url
>> #:key
>> - (ref '(branch . "master"))
>> + (ref '(symref .
>> "refs/remotes/origin/HEAD"))
>> rec
Christopher Howard writes:
> Hi, our emacs package, as well as the emacs-next package, appears to
> come package with its own release of org (org-mode). M-x org-version
> gives version 9.3. However, we also have an emacs-org package at 9.4.4.
> Emacs still tries to use the 9.3 version if I install
Christopher Howard writes:
> I installed emacs-org in my profile and then logged out and back into
> my DE. After that the newer org version is reported.
Thanks for the update.
> Thanks for your time - feel free to close this bug report.
Sure, closing.
a/guix/git.scm
+++ b/guix/git.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2017, 2020 Mathieu Othacehe
;;; Copyright © 2018, 2019, 2020, 2021 Ludovic Courtès
+;;; Copyright © 2021 Kyle Meyer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -209,6 +
Ludovic Courtès writes:
> Kyle Meyer skribis:
[...]
>>git-checkout make-git-checkout
>>git-checkout?
>>(url git-checkout-url)
>> - (branch git-checkout-branch (default "master"))
>> + (branch git-checkout-branch (default #f))
>&g
Kyle Meyer writes:
> @@ -356,6 +360,7 @@ (define* (update-cached-checkout url
>
> REF is pair whose key is [branch | commit | tag | tag-or-commit ] and value
> the associated data: [ | | | ].
> +IF REF is the empty list, the remote HEAD is used.
Sorry, here and ...
>
Timothy Sample writes:
> Hi,
>
> Ricardo Wurmus writes:
>
>> [...]
>>
>> It seems to me that this is a more general problem affecting all of our
>> Haskell packages. The configure phase that you didn’t paste should show
>> that modules are provided by slightly different packages.
>>
>> The hask
Zhu Zihao writes:
> Due to the inactive status of upstream. I'm planning to remove the
> emacs-libgit input of emacs-magit.
>
> magit will still work with the git executable if there's no
> emacs-libgit.
>
> Any thoughts?
Good idea. There's no real downside to disabling libgit2 support
because m
Maxime Devos writes:
> Maybe this can be fixed by patching "magit-git-executable" in Guix
> with an absolute path -- that procedure is only used on the local host,
> so that shouldn't cause any problems with TRAMP. Will send a mail to
> 30434.
Right, using an absolute path for magit-git-executab
Kyle Meyer writes:
> The latest version of b4 no longer calls dnspython's
> get_default_resolver(), so it avoids this failure. I posted a series
> for that update at https://debbugs.gnu.org/48702
> (<20210527145046.11773-1-k...@kyleam.com>). It's a bit stale at th
paren--- via Bug reports for GNU Guix writes:
> $ guix describe
> Generation 240 Nov 08 2022 18:38:30(current)
> guix c52cdd1
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: c52cdd18d6f869dfb1f8b5214a0db6ebb562
> [...]
>
> 2 u
Ludovic Courtès writes:
> For the record, I tried the attached patch in an attempt to sort things
> as discussed in the issue above, but it doesn’t have the intended
> effect. There must be other unsorted dictionaries elsewhere.
Hmm, I don't think dictionaries are a likely culprit here because
P
Aleksandr Vityazev writes:
> Hello,
>
> The b4 package sanity-check phase failure:
>
> --8<---cut here---start->8---
> starting phase `sanity-check'
> validating 'b4'
> /gnu/store/4fm7zp1kimv5cq8dvkn89a3vjpwcfbi1-b4-0.6.2/lib/python3.9/site-packages
[...]
> F
Hello,
I came across this bug report when searching for something else. In
case it helps...
Christopher Howard writes:
> Hello, for a long time I've struggled with getting a path error when I
> try to do a commit using emacs-magit. Here is an example log copied from
> the magit-process buffer:
Gábor Boskovits writes:
> Konrad Hinsen ezt írta (időpont: 2019. dec.
> 17., Ke 7:52):
[...]
>> How about a more drastic measure: deprecate "guix environment" and
>> introduce a new subcommand with the desired new behaviour?
>>
> That is also the other option I was thinking about. Do you have an
22 matches
Mail list logo
