bug#49372: lagrange: illegal instruction

[Efraim Flashner]

It sounds like everything's working now so I'm going to close the bug.

On Sun, Jul 04, 2021 at 05:40:41PM -0800, Christopher Howard wrote:
> I rebuilt from source and challenge now seems to be okay:
> 
> christopher@nightshade ~/Repos/guix-working$ guix challenge lagrange
> 
> 1 store items were analyzed:
>   - 1 (100.0%) were identical
>   - 0 (0.0%) differed
>   - 0 (0.0%) were inconclusive
> 
> -- 
> Christopher Howard
> my gemini capsule: gemini://gem.librehacker.com
> gemini browser: https://git.skyjake.fi/gemini/lagrange/releases
> 
> 
> On Sun, 2021-07-04 at 16:40 -0800, Christopher Howard wrote:
> > It seems to have downloaded as a substitute, and I was able to launch the 
> > program without getting an error.
> > 
> > ```
> > christopher@nightshade ~/Repos/guix-working$ guix build lagrange
> > 11.0 MB will be downloaded:
> >/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
> > substituting /gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2...
> > downloading from 
> > https://ci.guix.gnu.org/nar/lzip/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
> >  ...
> >  lagrange-1.5.2  11.4MiB
> > 
> >4.4MiB/s 00:03
> > [##] 100.0%
> > 
> > The following graft will be made:
> >/gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> > applying 3 grafts for 
> > /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv ...
> > grafting '/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2' -> 
> > '/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2'...
> > successfully built 
> > /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> > /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2
> > christopher@nightshade ~/Repos/guix-working$ 
> > /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2/bin/lagrange
> > 
> > (launched without trouble)
> > ```
> > 
> 

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#49372: lagrange: illegal instruction

[Christopher Howard]

I rebuilt from source and challenge now seems to be okay:

christopher@nightshade ~/Repos/guix-working$ guix challenge lagrange

1 store items were analyzed:
  - 1 (100.0%) were identical
  - 0 (0.0%) differed
  - 0 (0.0%) were inconclusive

-- 
Christopher Howard
my gemini capsule: gemini://gem.librehacker.com
gemini browser: https://git.skyjake.fi/gemini/lagrange/releases


On Sun, 2021-07-04 at 16:40 -0800, Christopher Howard wrote:
> It seems to have downloaded as a substitute, and I was able to launch the 
> program without getting an error.
> 
> ```
> christopher@nightshade ~/Repos/guix-working$ guix build lagrange
> 11.0 MB will be downloaded:
>/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
> substituting /gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2...
> downloading from 
> https://ci.guix.gnu.org/nar/lzip/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
>  ...
>  lagrange-1.5.2  11.4MiB  
>   
>4.4MiB/s 00:03
> [##] 100.0%
> 
> The following graft will be made:
>/gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> applying 3 grafts for 
> /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv ...
> grafting '/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2' -> 
> '/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2'...
> successfully built 
> /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
> /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2
> christopher@nightshade ~/Repos/guix-working$ 
> /gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2/bin/lagrange
> 
> (launched without trouble)
> ```
> 

bug#49372: lagrange: illegal instruction

[Christopher Howard]

It seems to have downloaded as a substitute, and I was able to launch the 
program without getting an error.

```
christopher@nightshade ~/Repos/guix-working$ guix build lagrange
11.0 MB will be downloaded:
   /gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
substituting /gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2...
downloading from 
https://ci.guix.gnu.org/nar/lzip/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2
 ...
 lagrange-1.5.2  11.4MiB

   4.4MiB/s 00:03
[##] 100.0%

The following graft will be made:
   /gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
applying 3 grafts for 
/gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv ...
grafting '/gnu/store/n45izfbldxjxdzfry2l4gn81lm18gmp0-lagrange-1.5.2' -> 
'/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2'...
successfully built 
/gnu/store/9n5nyy324bp50yjc7pxv6a53zq7b9cza-lagrange-1.5.2.drv
/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2
christopher@nightshade ~/Repos/guix-working$ 
/gnu/store/jj873xpq7h0rxm3rzc4b7rm6kzwnbby4-lagrange-1.5.2/bin/lagrange

(launched without trouble)
```

-- 
Christopher Howard
my gemini capsule: gemini://gem.librehacker.com
gemini browser: https://git.skyjake.fi/gemini/lagrange/releases

bug#49372: lagrange: illegal instruction

[Christopher Howard]

Test it as a substitute?

-- 
Christopher Howard
my gemini capsule: gemini://gem.librehacker.com
gemini browser: https://git.skyjake.fi/gemini/lagrange/releases


On Sun, 2021-07-04 at 22:09 +0300, Efraim Flashner wrote:
> On Sat, Jul 03, 2021 at 07:32:45PM -0800, Christopher Howard wrote:
> > Hi, I've discovered lagrange is another one of those packages which, if I 
> > use a substitute, it gives the error "illegal instruction" when I try to 
> > run it. but if I download the source and build it
> > myself, I have no trouble running it. I'm certain without any research that 
> > this is a reproducibility error, due to native instructions not on my 
> > processor, but I could do the guix challenge if
> > somebody could remind me exactly how to tell guix to rebuild that one 
> > package from source.
> > 
> 
> I found that there is a spot in the code where it tests if the compiling
> computer can support sse4.1, and if so then it enables it. I've added a
> configure-flag to disable that. Can you test the new version?
> 

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

[Sarah Morgensen via Bug reports for GNU Guix]

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.drv'
>> 
>> I know the names are significant in go-build-system so I'm not sure
>> how
>> to work around the issue without breaking anything.

As far as I can tell, the go-build-system doesn't care about the actual
package names, just #:import-path and #:unpack-path. The names should
only be significant to the go importer insofar as
go-module->guix-package-name does not generate collisions.

> The way Go works, I would hazard a guess, that 
>   module git.sr.ht/~sircmpwn/kineto
> and 
>   module git.sr.ht/sircmpwn/kineto
> name two different modules.  However, as the latter can't exist since
> sr.ht prefixes user names with ~, I think a name transformation, that
> maps the former to the latter should be safe.  On the other hand, since
> this just affects store file names, we might instead want to map "~" to
> "-" in the general case of it appearing anywhere.  WDYT?

It might be slightly uglier, but I think it's better to keep a
consistent policy of "replace any invalid characters with a hyphen", as
it is less likely to generate collisions and it provides a hint to the
reader that there *is* a character there.

I have attached a patch to do so below, verified that a recursive import
of the package mentioned above builds without modification (well, I had
to update a dependency...) and verified that there are not currently any
go packages using a tilde in their 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 -0700
Subject: [PATCH] import: go: Replace tildes with hyphens in package names.

Fixes .

* guix/import/go.scm (go-module->guix-package-name): Replace tildes with
hyphens.
---
 guix/import/go.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index 5e23d6a2b3..d8f838f635 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -430,9 +430,9 @@ hence the need to derive this information."
 (define* (go-module->guix-package-name module-path #:optional version)
   "Converts a module's path to the canonical Guix format for Go packages.
 Optionally include a VERSION string to append to the name."
-  ;; Map dot, slash and underscore characters to hyphens.
+  ;; Map dot, slash, underscore and tilde characters to hyphens.
   (let ((module-path* (string-map (lambda (c)
-(if (member c '(#\. #\/ #\_))
+(if (member c '(#\. #\/ #\_ #\~))
 #\-
 c))
   module-path)))

base-commit: 9e63bafafbe7a7c2d9804fae62302ac8a7e90090
-- 
2.31.1


--
Sarah

bug#49171: OCaml packages not building (due to updated python-pyyaml)

[pukkamustard]

Xinglu Chen  writes:


I think this was fixed in commit
91b29aa37394b660117e1d79927621db1344b7fe (gnu: ocaml-dose3: Fix 
tests.),

do you think we can close the issue?


Yup, was fixed and already closed by Julien (see 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49171#13).

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

[Sarah Morgensen via Bug reports for GNU Guix]

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), this
is because Guix does not typically work with pre-compiled software that
relies on system libraries being in /lib, since there is no system-wide
/lib.

> This seems like a version mismatch to me, so i built Hugo with the
> following command:
>   go build --tags extended
>
> Now the error is ( = ypiv8dj4lkvsnm82s639h18l87frrh5g):
>   /gnu/store/-gcc-6.5.0-lib/lib/libstdc++.so.6: version
>   `GLIBCXX_3.4.26' not found

If I build hugo with gcc-toolchain@7 in my user profile, it works fine.
However I can still repro this issue with gcc-toolchain@8+:

$ go build --tags extended
$ ./hugo --help
./hugo: 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
version `GLIBCXX_3.4.26' not found (required by ./hugo)
./hugo: 
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib/libstdc++.so.6: 
version `GLIBCXX_3.4.29' not found (required by ./hugo)

This is because gcc 7's libraries are shadowing the newer gcc's
libraries:

$ readelf -d hugo | grep RUNPATH
 0x001d (RUNPATH)Library runpath: 
[/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib/lib:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib:/home/sarah/.guix-profile/lib:/gnu/store/3h7xd0d47a286b6r9qhz4ybi5iaxkfwi-gcc-11.1.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.1.0/../../..]

If I use patchelf to remove the gcc 7 library dir from RUNPATH, hugo
works fine. This is because Go is patched to unconditionally add a
runpath to gcc 7's libraries but erroneously does not explicitly set
CXX. (See also .)

The following patch should explicitly set CXX for Go, so that it always
uses the "system" version:

diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm
index 0318918a37..a27f57aa30 100644
--- a/gnu/packages/golang.scm
+++ b/gnu/packages/golang.scm
@@ -395,6 +395,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
;; FIXME: Some of the .a files are not bit-reproducible.
(let* ((output (assoc-ref outputs "out")))
  (setenv "CC" (which "gcc"))
+ (setenv "CXX" (which "g++"))
  (setenv "GOOS" "linux")
  (setenv "GOROOT" (dirname (getcwd)))
  (setenv "GOROOT_FINAL" output)
@@ -577,6 +578,7 @@ in the style of communicating sequential processes (@dfn{CSP}).")
   (loader (string-append (assoc-ref inputs "libc")
  ,(glibc-dynamic-linker
  (setenv "CC" (which "gcc"))
+ (setenv "CXX" (which "g++"))
  (setenv "GO_LDSO" loader)
  (setenv "GOOS" "linux")
  (setenv "GOROOT" (dirname (getcwd)))

Hope that helps,
Sarah

bug#49113: aarch64-linux-gnu cross-compiler fails to build [core-updates]

[Ludovic Courtès]

Hello,

Ludovic Courtès  skribis:

> Maxime Devos  skribis:
>
>> aarch64-linux-gnu-ld: skipping incompatible 
>> /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so
>>  when searching for -lc
>> [ previous line 2 times repeated ]
>> aarch64-linux-gnu-ld: cannot find -lc
>> aarch64-linux-gnu-ld: skipping incompatible 
>> /gnu/store/31pavw3yzfck5sql6rjv92ahi8x9dhaj-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so
>>  when searching for -lc
>> [ previous line 2 times repeated ]
>> collect2: error: ld returned 1 exit status
>> make[2]: *** [Makefile:985: libgcc_s.so] Error 1
>
> As discussed on IRC, the problem seems to be that, when cross-compiling,
> the ‘OUTPUT_FORMAT’ bit in libc.so is wrong (“elf64-little” instead of
> “elf64-littleaarch64”).  This, in turn, seems to be due to a regression
> in how glibc’s build machinery computes that value, which is fixed by
> this patch:
>
>   https://sourceware.org/pipermail/libc-alpha/2021-July/128333.html
>
> I haven’t had feedback from upstream yet but I’ll apply it soonish in
> Guix as it does the job.

Pushed as 949ed7aae1e9418ea99f569efe6cb03349485508!

Ludo’.

bug#49372: lagrange: illegal instruction

[Efraim Flashner]

On Sat, Jul 03, 2021 at 07:32:45PM -0800, Christopher Howard wrote:
> Hi, I've discovered lagrange is another one of those packages which, if I use 
> a substitute, it gives the error "illegal instruction" when I try to run it. 
> but if I download the source and build it
> myself, I have no trouble running it. I'm certain without any research that 
> this is a reproducibility error, due to native instructions not on my 
> processor, but I could do the guix challenge if
> somebody could remind me exactly how to tell guix to rebuild that one package 
> from source.
> 

I found that there is a spot in the code where it tests if the compiling
computer can support sse4.1, and if so then it enables it. I've added a
configure-flag to disable that. Can you test the new version?

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#49360: Updating cataclysm-dda to 0.F

[Chris Lemmer-Webber]

Nicolas Goaziou writes:

> Hello,
>
> Chris Lemmer-Webber  writes:
>
>>> There are two options.
>>>
>>> 1) We could mess with the build phase order, do a make install, then a
>>>fresh make clean, then make again with the tiles support on:
>>>  
>>> https://github.com/CleverRaven/Cataclysm-DDA/issues/42598#issuecomment-667702746
>>>
>>> 2) But that seems strange so we could make a separate
>>>cataclysm-dda-tiles output.  We already do a similar thing for crawl
>>>and crawl-tiles, so why not?
>>>
>>> What do people think?  I'm leaning towards (2).
>>>  - Chris
>>
>> I've pushed a new version in b65af6ed91.  I took the first of these two
>> routes, though I think in the long run the latter approach probably
>> makes more sense.
>
> FWIW, I also think the second path makes more sense.
>
> Regards,

Yes, it would be good to go that route if someone is willing to take the
time to split it up.

bug#49171: OCaml packages not building (due to updated python-pyyaml)

[Xinglu Chen]

On Tue, Jun 22 2021, pukkamustard wrote:

> Hi Guix,
>
> With commit ac02d423d3fcb11048ee2e4a02626fca40cf1419, which 
> updated python-pyyaml to 5.4.1 (from 5.3.1) lot of OCaml packages 
> fail to build.
>
> This seems to be due to ocaml-dose3 that has python2-pyyaml as 
> dependency for tests. ocaml-dose3 is a dependency of opam - a 
> dependency of many OCaml packages.
>
> The output when trying to build ocaml-dose3:
>
> --
> phase `build' succeeded after 14.5 seconds
> starting phase `check'
> /tmp/guix-build-ocaml-dose3-5.0.1.drv-0/dose3-5.0.1
> ocamlbuild  -j 10 applications/apps.otarget
> # No parallelism done
> make testlib
> make[1]: Entering directory 
> '/tmp/guix-build-ocaml-dose3-5.0.1.drv-0/dose3-5.0.1'
> echo
>
> make[1]: Leaving directory 
> '/tmp/guix-build-ocaml-dose3-5.0.1.drv-0/dose3-5.0.1'
> applications/dose-tests.py applications/dose-tests.list
> Traceback (most recent call last):
>   File "applications/dose-tests.py", line 17, in 
> warning('YAML C-library not available, falling back to 
> python')
> NameError: name 'warning' is not defined
> make: *** [Makefile:206: test] Error 1
> command "make" "test" 
> "LIBDIR=/gnu/store/v939nvdn67cdgb7rjkyvplfw1qr2hkjl-ocaml-dose3-5.0.1/lib/ocaml/site-lib"
>  
> failed with status 2
> note: keeping build directory 
> `/tmp/guix-build-ocaml-dose3-5.0.1.drv-3'
> builder for 
> `/gnu/store/lybbyb38k0009jrbviymq88vi6xak5ii-ocaml-dose3-5.0.1.drv' 
> failed with exit code 1
> build of 
> /gnu/store/lybbyb38k0009jrbviymq88vi6xak5ii-ocaml-dose3-5.0.1.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/ly/bbyb38k0009jrbviymq88vi6xak5ii-ocaml-dose3-5.0.1.drv.bz2'.
> guix build: error: build of 
> `/gnu/store/lybbyb38k0009jrbviymq88vi6xak5ii-ocaml-dose3-5.0.1.drv' 
> failed
> --
>
> This seems to also be what CI is encoutering: 
> https://ci.guix.gnu.org/build/623375/details
>
> Any ideas? Any other packages failing for the same reason?
>
> Would disabling tests for ocaml-dose3 be an acceptable quick hack?
>
> Cheers,
> pukkamustard

I think this was fixed in commit
91b29aa37394b660117e1d79927621db1344b7fe (gnu: ocaml-dose3: Fix tests.),
do you think we can close the issue?


signature.asc
Description: PGP signature

bug#49368: Guile 3.0.7 test failures on i686-linux, glibc 2.33 [core-updates]

[Maxime Devos]

Ludovic Courtès schreef op za 03-07-2021 om 23:41 [+0200]:
> On current ‘core-updates’
> (ca. 39f1486efd70712416ca784f9014132644b04155), Guile 3.0.7,
> specifically (@@ (gnu packages commencement) guile-final) fails tests on
> i686-linux:
> 
> --8<---cut here---start->8---
> Running numbers.test
> FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: 
> (130.0 10/7)
> [...]

Curiously, on core-updates, ceiling/ is inconsistent with ceiling-quotient
and ceiling-remainder:

scheme@(guile-user) [1]> (ceiling/ 130.0 -10/7)
$28 = -90.0
$29 = 1.4285714285714257
scheme@(guile-user) [1]> (ceiling-quotient 130.0 -10/7)
$30 = -91.0
scheme@(guile-user) [1]> (ceiling-remainder 130.0 -10/7)
$31 = 0.0

But on 'master', the results are consistent:

scheme@(guile-user)> (ceiling/ 130.0 -10/7)
$1 = -91.0
$2 = 0.0
scheme@(guile-user)> (ceiling-quotient 130.0 -10/7)
$3 = -91.0
scheme@(guile-user)> (ceiling-remainder 130.0 -10/7)
$4 = 0.0

To be investigated ...

Greetings,
Maxime.
> 


signature.asc
Description: This is a digitally signed message part

bug#49372: lagrange: illegal instruction

[Maxime Devos]

Christopher Howard schreef op za 03-07-2021 om 19:32 [-0800]:
> Hi, I've discovered lagrange is another one of those packages which, if I use 
> a substitute, it gives the error "illegal instruction" when I try to run it. 
> but if I download the source and build it
> myself, I have no trouble running it. I'm certain without any research that 
> this is a reproducibility error, due to native instructions not on my 
> processor, but I could do the guix challenge if
> somebody could remind me exactly how to tell guix to rebuild that one package 
> from source.

To test reproducibility, you can also try

# To avoid building the dependencies
$ guix environment lagrange --system=i686-linux --no-grafts
$ (exit environment)
$ guix build lagrange --no-substitutes --system=i686-linux
$ guix challenge lagrange --system=i686-linux

Maybe the issue also exists for the iN86 architecture family ...

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#49372: lagrange: illegal instruction

[Maxime Devos]

Christopher Howard schreef op za 03-07-2021 om 19:32 [-0800]:
> myself, I have no trouble running it. I'm certain without any research that 
> this is a reproducibility error, due to native instructions not on my 
> processor, but I could do the guix challenge if

$ guix gc --delete /gnu/store/...-lagrange-VERSION

Take note that lagrange must be removed from all profiles first,
and no file from the "lagrange" package may be opened ...

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#49368: Guile 3.0.7 test failures on i686-linux, glibc 2.33 [core-updates]

[Maxime Devos]

Ludovic Courtès schreef op za 03-07-2021 om 23:41 [+0200]:
> On current ‘core-updates’
> (ca. 39f1486efd70712416ca784f9014132644b04155), Guile 3.0.7,
> specifically (@@ (gnu packages commencement) guile-final) fails tests on
> i686-linux:
> 
> --8<---cut here---start->8---
> Running numbers.test
> FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: 
> (130.0 10/7)
> FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: 
> (130.0 -10/7)
> FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (130.0 
> 10/7)
> FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (-130.0 
> -10/7)
> FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (130.0 
> -10/7)
> FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (-130.0 
> 10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
> 10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
> -10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: 
> (-130.0 10/7)
> FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: 
> (-130.0 -10/7)
> --8<---cut here---end--->8---
> 
> Note that this doesn’t happen on ‘master’ (glibc 3.31).

In a REPL:

(euclidean/ 130.0 10/7)
(euclidean/ 130.0 -10/7)
(floor/ 130.0 10/7)
(floor/ -130.0 -10/7)
(ceiling/ 130.0 -10/7)
(ceiling/ -130.0 10/7)
(truncate/ 130.0 10/7)
(truncate/ 130.0 -10/7)
(truncate/ -130.0 10/7)
(truncate/ -130.0 -10/7)

Output on core-updates (using --keep-failed and ./meta/uninstalled-env guile):

scheme@(guile-user)> (euclidean/ 130.0 10/7)
$1 = 90.0
$2 = 1.4285714285714257
scheme@(guile-user)> (euclidean/ 130.0 -10/7)
$3 = -90.0
$4 = 1.4285714285714257
scheme@(guile-user)> (floor/ 130.0 10/7)
$5 = 90.0
$6 = 1.4285714285714257
scheme@(guile-user)> (floor/ -130.0 -10/7)
$7 = 90.0
$8 = -1.4285714285714257
scheme@(guile-user)> (ceiling/ 130.0 -10/7)
$9 = -90.0
$10 = 1.4285714285714257
scheme@(guile-user)> (ceiling/ -130.0 10/7)
$11 = -90.0
$12 = -1.4285714285714257
scheme@(guile-user)> (truncate/ 130.0 10/7)
$13 = 90.0
$14 = 1.4285714285714257
scheme@(guile-user)> (truncate/ 130.0 -10/7)
$15 = -90.0
$16 = 1.4285714285714257
scheme@(guile-user)> (truncate/ -130.0 10/7)
$17 = -90.0
$18 = -1.4285714285714257
scheme@(guile-user)> (truncate/ -130.0 -10/7)
$19 = 90.0
$20 = -1.4285714285714257

It appears that truncate/, ceiling/ and floor/ give the same output ...
that doesn't seem correct.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#31337: Unable to use gnuk usb smartcard token on GuixSD

[Brice Waegeneire]

Brice Waegeneire  writes:

Closing this issue since it's should be solved.  Feel free to reopen it
if it's not the case.

bug#49297: zsh-autosuggestions build fail

[Brice Waegeneire]

Hello Zacchaeus,

Zacchaeus Scheffer  writes:

> I tried installing zsh-autosuggestions, but the build fails in three places 
> on the same file when running rspec, all with the same discrepancy:

Thank you for the bug report!  The issue appear after updating tmux to
3.2a, fom its changelog it's not clear to me which commit produced this
new behaviour.  I tired patching the tests to not resize the tmux
window, to no avail, so I just disabled thoses 3 tests in
348c70f3fdb55eb1373dfd57d9128d6f6bede02d.

Cheers,
- Brice

bug#49374: no code for module (guix build qt-utils)

[Leo Prikler]

I've pushed cc73ddfb9aee8eb7481bb6ee7925c1074f20134c, which ought to
fix this.

Thanks,
Leo