bug#43334: Cuirass crashes

Hey Chris, >> It looks like a memory allocation failed causing a Cuirass/Guile crash. > > So, I've seen this before but in a slightly different context, [1]. To > summarise, with Guile built with libgc@8 the Guix Data Service couldn't > processes Guix revisions, because the code it had Guile bui

bug#43321: [PATCH] gnu: Fix a crash in NTP and Chrony.

Fixes . * gnu/packages/ntp.scm (ntp, chrony)[inputs]: Replace libcap with libcap/next. --- gnu/packages/ntp.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/ntp.scm b/gnu/packages/ntp.scm index 6b725c2b0f..5fa7d55845 100644 --- a

bug#43277: emacs-next is broke, "seq" missing

Hi Martin, Sorry this not working for you :-/ Martin Becze writes: > emacs-next recently broke. It now has this error on start up. > > "require: Cannot open load file: No such file or directory, seq" > > I think this must have happened relatively recently (with the last 3 > weeks) since it was w

bug#43334: Cuirass crashes

Mathieu Othacehe writes: > Hello, > > I've observed a few Cuirass crashes the past days. The log looks like: > > --8<---cut here---start->8--- > 2020-09-11T12:55:35 next evaluation in 300 seconds > GC Warning: Repeated allocation of very large block (appr. siz

bug#43344: "basic" system tests fail (and all the other ones) on guix master

Hi, as of guix master commit 0fb974be9c3e1e22a2145c9c602c44cd10cef2b0 all system tests, including "basic", fail: $ guix environment --pure guix --ad-hoc git guile-readline guile-json nano guile-zlib guile-lzlib (env)$ make TESTS=basic check-system loading '/gnu/store/s3limrgxj4pd6b4psra66phary2n

bug#21803: Guitarix builds non-deterministically

Hello, [...] > Guitarix has been updated to 0.41.0 by commit > bf592ef506e1db0340dc11faa0514fe80793e6d6. > > I have tried "guix build guitarix --no-grafts --check -K" at least 10 > times without noticing an unreproducible behaviour. > > Could someone confirm this and then close this almost 5 year

bug#43303: GCC package name

Dear, On Thu, 10 Sep 2020 at 13:16, zimoun wrote: > About discoverability (guix search gcc) there is still 2 issues: > > 1. libgccjit inherits from gcc-9 but the synopsis/description is not updated. > 2. gccgo uses custom-gcc and so reuse the same synopsis/description. [...] > Last, it is un

bug#43331: guix repl doesn't find the script to execute

Hi Simon, > It sounds similar to the recent #42543 [1]. I proposed the fix [2] > using 'canonicalize-path' but Ludo was not fine with it and then > committed d10474c38d58bdc676e64336769dc2e00cdfa8ed [3]. Thanks for the references, all that happened while I was on vacation. There is indeed some

bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times

Hi, zimoun skribis: > On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès wrote: > >> > The recent updates of ungoogled-chromium do not mention [security >> > updates]. Well, I do not know if they are. So the question would be: >> > what triggers the special security build? >> >> To me the proposal

bug#41668: Failing test: gui-installed-desktop-os-encrypted

Hi, Mathieu Othacehe skribis: >> Is it deterministic? Same story with “gui-installed-os”? >> >> I guess we can add more ‘syslog’ statements in the installer around the >> place where we restart services. Or we could run the installer entirely >> under strace. > > Now that the installation is d

bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times

zimoun writes: > On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès wrote: >> To me the proposal is more about introducing scheduling priorities. For >> these packages, it’s indeed safe to assume that every new release brings >> security fixes. > > Why would some packages be prioritized on the buil

bug#41878: 'guix substitute' and 'guix pull' fail gracelessly on flaky networks

Dear, On Sun, 30 Aug 2020 at 20:06, Brendan Tildesley wrote: > I have not looked closely but from observation I think currently guix first > decides if it is going to commit to using a substitute, or falling back to > building locally, by checking if substitutes are available then committing to >

bug#41762: Python's pip works from the store but not from profiles

Hi Pierre, On Wed, 10 Jun 2020 at 11:37, Pierre Neidhardt wrote: > Oooh! Didn't know that! > And indeed, `pip3' is a command of python@3, so the package description > is accurate. > Should we mention `pip` nonetheless in `python-wrapper's description? Well, I do not know. If you feel it can he

bug#21803: Guitarix builds non-deterministically

Dear, On Sun, 01 Nov 2015 at 11:30, l...@gnu.org (Ludovic Courtès) wrote: > Guitarix 0.33.0, as of Guix commit 3c3e697, builds > non-deterministically: > > $ ./pre-inst-env guix challenge guitarix > updating list of substitutes from 'http://hydra.gnu.org'... 100.0% > /gnu/store/6ksnwcqn92z2nf6qw5j

bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times

On Fri, Sep 11, 2020 at 09:37:59AM +0200, zimoun wrote: > I understand the annoyance and the frustration of the substitutes > availability but I am not convinced that some packages have higher > priority on the substitute delivery than others. In general, I agree with you, especially since most pa

bug#43321: programs depending on libcap 2.31 are crashing (including ntpd, chrony, and potentially others)

On Thu, Sep 10, 2020 at 10:19:54PM -0400, Leo Famulari wrote: > Great. I'm also testing the same solution for ntpd now. I'll make sure > that works and figure out what the situation is on the 5.4 kernel. It works for ntpd on Linux 5.8. Now to test the older kernels...

bug#43334: Cuirass crashes

Mathieu Othacehe writes: > Hello, > > I've observed a few Cuirass crashes the past days. The log looks like: > > --8<---cut here---start->8--- > 2020-09-11T12:55:35 next evaluation in 300 seconds > GC Warning: Repeated allocation of very large block (appr. si

bug#43334: Cuirass crashes

Hello, I've observed a few Cuirass crashes the past days. The log looks like: --8<---cut here---start->8--- 2020-09-11T12:55:35 next evaluation in 300 seconds GC Warning: Repeated allocation of very large block (appr. size 28766208): May lead to memor

bug#43331: guix repl doesn't find the script to execute

Hi Konrad, It sounds similar to the recent #42543 [1]. I proposed the fix [2] using 'canonicalize-path' but Ludo was not fine with it and then committed d10474c38d58bdc676e64336769dc2e00cdfa8ed [3]. [1] http://issues.guix.gnu.org/42543 [2] http://issues.guix.gnu.org/42543#3 [3] https://git.sava

bug#43331: Patch

The patch that I just submitted fixes the problem. However, I don't really know what the cause of the bug is, given that load-in-vicinity is undocumented and I don't fully understand its implementation. So maybe there is a better way to fix this. Konrad.

bug#43331: [PATCH] repl: Look for script files in (getcwd).

* guix/scripts/repl.scm (guix-repl): Replace "." by (getcwd) --- guix/scripts/repl.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm index 3c79e89f8d..80bf1460e9 100644 --- a/guix/scripts/repl.scm +++ b/guix/scripts/repl.scm @@ -1

bug#43331: guix repl doesn't find the script to execute

Example: $ guix repl moocrr_guix_jupyter/installed-dependencies.scm Backtrace: 1 (primitive-load-path "./moocrr_guix_jupyter/installed-d…") In ice-9/boot-9.scm: 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: In procedure primit

bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times

zimoun writes: > I understand the annoyance and the frustration of the substitutes > availability but I am not convinced that some packages have higher > priority on the substitute delivery than others. Hard to say. I think this discussion is a little premature given our historic underutiliza

bug#43075: Prioritize providing substitutes for security-critical packages with potentially long build times

Hi, On Fri, 11 Sep 2020 at 08:56, Ludovic Courtès wrote: > > The recent updates of ungoogled-chromium do not mention [security > > updates]. Well, I do not know if they are. So the question would be: > > what triggers the special security build? > > To me the proposal is more about introducing

bug#41668: Failing test: gui-installed-desktop-os-encrypted

Hello, > Is it deterministic? Same story with “gui-installed-os”? > > I guess we can add more ‘syslog’ statements in the installer around the > place where we restart services. Or we could run the installer entirely > under strace. Now that the installation is done in a container, this one do