bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation

This patch fixes issue in the way that it: a) calculates the result before call to (*env)->ReleaseStringUTFChars b) attempt to trick gcc optimizations by complicating path I suppose issue is with what (*env)->ReleaseStringUTFChars does and how. One should note that similar approach is not

bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64

Patching strace to add a "--trace-path" parameter to the two tests' definitions as in the patch below seems to fix this issue on both AArch64 and x86-64, and is less drastic than disabling the tests altogether. The changes limit strace's output during testing to only calls affecting files in the t

bug#49990: [PATCH] gnu: Fix classpath-bootstrap compilation

--- gnu/packages/java.scm | 3 +- .../patches/classpath-instruction-order.patch | 35 +++ 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/classpath-instruction-order.patch diff --git a/gnu/packages/java.scm b/gnu/p

bug#49801: Guix time machine provenance/manifest reproducibility issue?

Hi Denis, On Thu, 02 Sep 2021 at 16:12, Denis 'GNUtoo' Carikli wrote: > Between the two tarballs, everything is the same but the provenance > file. > > So here the idea is to make sure that the provenance file is the same > between tarballs made with and without guix time-machine. Yes, for sur

bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64

strace 5.13 in core-updates-frozen appears to build fine but fails its "readlinkat" test for me on AArch64 (real hardware; a ROCK64). This is the only test that fails. >From the build directory, strace-5.13/tests/readlinkat.dir/exp contains readlinkat(AT_FDCWD, "\x74\x65\x73\x74\x2e\x72\x65\x

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 tell what resolved t

bug#49990: [core-updates-frozen] Ant-bootstrap broken by classpath-bootstrap

Actually, Ludo's patch works, but we should not remove the workaround for isDirectory. With the patch to isFile and the workaround in isDirectory, I can build up to (but not including) icedtea@1. Ludo's patch is nicer than using -O0 :) Le 2 septembre 2021 10:15:41 GMT-04:00, Maxime Devos a éc

bug#49990: [core-updates-frozen] Ant-bootstrap broken by classpath-bootstrap

Ludovic Courtès schreef op wo 01-09-2021 om 15:53 [+0200]: > Hmm -O0 is brute-force. What about only using "-O0" for whatever C file is responsible for Java_java_io_VMFile_isFile? Greetings, Maxime signature.asc Description: This is a digitally signed message part

bug#49801: Guix time machine provenance/manifest reproducibility issue?

On Thu, 2 Sep 2021 10:10:22 +0200 zimoun wrote: > Hi Denis, > > Thanks for the investigation and the attempt. > > Well, I miss if it works or not... It doesn't work. The issue was that if you build a tarball with guix pack, without guix time-machine, you can't reproduce it with guix-time-machi

bug#50335: Inheritance vs. ‘this-package’

Hi! We stumbled upon an idiom for package arguments that, combined with package inheritance, would not work as expected. It goes like this (taken from ): --8<---cut here---start->8--- (define-public starpu (package

bug#49801: Guix time machine provenance/manifest reproducibility issue?

Hi Denis, Thanks for the investigation and the attempt. Well, I miss if it works or not... On Thu, 2 Sept 2021 at 00:27, Denis 'GNUtoo' Carikli wrote: > With and without this patch: > > diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm > > index fb8ce50fa7..af1cf77f07 100644 > > --- a