bug#55848: [cuirass] workers stalled

2022-06-19 Thread Tom Fitzhenry
On Mon, 20 Jun 2022, at 12:39 PM, Maxim Cournoyer wrote:
> That's a known issue with mrustc; it only succeeds with x86_64; the
> other architectures have problems.  That's a bug the mrustc author would
> like to fix, so perhaps in time in will improve (especially if
> interested parties can lend a hand).

mrustc was fixed on aarch64 in https://issues.guix.gnu.org/54580 on staging, 
which was recently merged to master.

I had tested mrustc and rust-1.39 to compile on aarch64 on staging, but now I 
observe rust-1.39 failing.

I'll take a closer look, maybe I'm missing something.





bug#55848: [cuirass] workers stalled

2022-06-19 Thread Maxim Cournoyer
Hi Mathieu!

[...]

> A few issues remain for aarch64:
>
> * grunewald and kreuzberg are not on .
>   Perhaps they were taken down while the substitute ratio was low to
>   avoid each worker independently recompiling expensive toolchains?
> * rust@1.39.0 (and thus all of Rust) is missing from ci and bordeaux. I
>   had expected this would have been working. I'll take a look and raise
>   a separate issue.

That's a known issue with mrustc; it only succeeds with x86_64; the
other architectures have problems.  That's a bug the mrustc author would
like to fix, so perhaps in time in will improve (especially if
interested parties can lend a hand).

There was also an attempt to cross-compile a rust/cargo bootstrap seed
for other architectures (branch: wip-cross-built-rust) but due to
complications with building rust as a static archive (it relies on
dynamic linking for its macro expand crates), the effort stalled.

Thanks,

Maxim





bug#22020: [PATCH] gnu: guile-sdl: Update to 0.6.1

2022-06-19 Thread Thiago Jung Bauermann via Bug reports for GNU Guix
This version's testsuite passes on i686-linux.

Fixes .

* gnu/packages/sdl.scm (guile-sdl): Update to 0.6.1.
---

Hello,

I was looking at bug 22020 (guile-sdl-0.5.2 fails to install on i686) and
noticed that upgrading guile-sdl to the latest version fixes the problem so
this is what this patch does.

Note that the diff between 0.5.3 and 0.6.1 has almost 24k lines so I didn't
even try skimming it.

I did verify the tarball's signature using the maintainer's (expired) public
key that I downloaded from Savannah¹:

$ gpg --verify guile-sdl-0.6.1.tar.lz.sig 
gpg: assuming signed data in 'guile-sdl-0.6.1.tar.lz'
gpg: Signature made Sun Feb 20 21:16:09 2022 -03
gpg:using DSA key 748EA0E81CB8A7489BFA6CE4670322244C807502
gpg: Good signature from "Thien-Thi Nguyen (software signing) 
" [expired]
gpg: aka "Thien-Thi Nguyen " [expired]
gpg: aka "Thien-Thi Nguyen " [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 748E A0E8 1CB8 A748 9BFA  6CE4 6703 2224 4C80 7502

I'll send a message to the guile-sdl mailing list suggesting them to publish
a new key.

Thanks,
Thiago

¹ https://savannah.gnu.org/users/ttn

 gnu/packages/sdl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index 4c38e2f05507..49bc09312a13 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -541,7 +541,7 @@ (define-public sdl2-ttf
 (define-public guile-sdl
   (package
 (name "guile-sdl")
-(version "0.5.3")
+(version "0.6.1")
 (source (origin
   (method url-fetch)
   (uri
@@ -549,7 +549,7 @@ (define-public guile-sdl
   version ".tar.lz"))
   (sha256
(base32
-"040gyk3n3yp8i30ngdg97n3083g8b6laky2nlh10jqcyjdd550d6"
+"1q985nd3birr5pny74915x098fisa6llas3ijgf1b4gdz5717nzz"
 (build-system gnu-build-system)
 (native-inputs
  `(("lzip" ,lzip)

base-commit: 73761d8049f483e6685c2c736872d0366e03238a





bug#51466: bug#53355: guix shell --check: confusing error message

2022-06-19 Thread Chris Marusich
Hi Ludo,

Thank you for the review!

Ludovic Courtès  writes:

> LGTM, please push!

Before pushing, I did some more tests to make sure it was still working.
When I did this, I noticed that read-line was no longer returning
strings that end in "\r".  This prevents child-shell-environment from
behaving correctly, since it incorrectly assumes that all the lines end
in "\r", stripping it off unconditionally.  In the past, I'm sure
read-line was returning strings that end in "\r".  I don't know what
changed, but I've attached a second patch that fixes this issue, also.

Unless you have more feedback, I'll go ahead and push both patches to
master in a few days.

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From c4fee9e63f8cb694de86ae46bd1e2e4c692eb6f6 Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Sun, 19 Jun 2022 13:16:04 -0700
Subject: [PATCH] environment: Don't assume that lines have a trailing "\r".

I've noticed that the child-shell-environment procedure is misbehaving on my
computer because the lines returned by read-line do not have a trailing "\r".
In the past, I recall that such lines did in fact have a trailing "\r".  I'm
not sure why it changed, but it seems prudent to just rewrite this code to
tolerate both cases, since it seems that both cases can happen.

* guix/scripts/environment.scm (child-shell-environment) [lines]: Instead of
checking if the line exactly matches "GUIX_CHECK_DONE\r"; check if the line
begins with "GUIX_CHECK_DONE".  Instead of always stripping the trailing
character from the line, only do it if the line has a trailing "\r".
---
 guix/scripts/environment.scm | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index f0cb341aab..1fb4f5b7c6 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -462,13 +462,18 @@ (define lines
   ;; prompt from getting mixed into what we read.
   (match (read-line shell-pipe-in)
 ((? eof-object?) (reverse lines))
-("GUIX-CHECK-DONE\r"
+((? (lambda (line)
+  ;; The line might or might not have a trailing \r.
+  (string-prefix? "GUIX-CHECK-DONE" line)))
  (display "done\n" port)
  (reverse lines))
 (line
- ;; Drop the '\r' from LINE.
- (loop (cons (string-drop-right line 1)
- lines
+ ;; Strip the trailing '\r' from LINE if present.
+ (let ((stripped-line
+(if (string-suffix? "\r" line)
+(string-drop-right line 1)
+line)))
+   (loop (cons stripped-line lines)
  (close-port port)
  (close-port shell-pipe-in)
  (waitpid pid)
-- 
2.34.0



signature.asc
Description: PGP signature


bug#56091: Possible hash mismatch in barrier 2.4.0

2022-06-19 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix

Hi!

Thanks for reporting this.

Vishakh Kumar 写道:

I think this is a case where the hash in the package description
might be wrong?


What usually (though, mercifully, rarely) happens is that the hash 
is correct at the time of packaging, then upstream goes and moves 
a perfectly good git tag instead of making a new one, and the hash 
becomes wrong in retrospect.


This case was different: the original packager correctly ran ‘guix 
hash -rx .’ on their clone of the barrier git repository, but did 
not first check out the submodules and was unaware that these 
affect the hash.  I don't think the original package ever built, 
or at least fail to see how it could have.


Fixed on master[0].

Closing, but could you guix pull & confirm that it works for you?

Kind regards,

T G-R

[0]: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7f1cb1ebca169e3a4b5ed59fe226bb614b18b57f


signature.asc
Description: PGP signature


bug#56091: Possible hash mismatch in barrier 2.4.0

2022-06-19 Thread Vishakh Kumar

Hey there!

Am trying to install barrier on my computer and guix tells me 
there is a
hash mismatch. I’m able to install other applications, and I think 
this
is a case where the hash in the package description might be 
wrong?


More than happy to provide more info, please let me know how i can 
help

debug this.

Cheers,
Vishakh Kumar


grokkingstuff@grokkingNoether ~$ guix install barrier
The following package will be installed:
   barrier 2.4.0

The following derivations will be built:
  /gnu/store/0lwma8nhhy18z8x5v8zjjhk740bm1mv9-barrier-2.4.0.drv
  /gnu/store/lba0pd5a1hzzfbcswgx0ws1nrldfxxnp-barrier-2.4.0-checkout.drv

15.1 MB will be downloaded
 qtbase-5.15.2  14.4MiB31KiB/s 07:54 
 [##] 100.0%
building 
/gnu/store/lba0pd5a1hzzfbcswgx0ws1nrldfxxnp-barrier-2.4.0-checkout.drv…
/r:sha256 hash mismatch for 
/gnu/store/s7ivxx684bd34bzmgdc282kw1lsg407r-barrier-2.4.0-checkout:
  expected hash: 
  10xk9szxxnqgfym53mcd9hqj1cw2ipncmiixw3i3ajlj1vn88qh1
  actual hash: 
  19bwa9qidq2mxv1fkyxxc1xdmv3jx6bj35bkaaw70jzkblnfmlfs
hash mismatch for store item 
’/gnu/store/s7ivxx684bd34bzmgdc282kw1lsg407r-barrier-2.4.0-checkout’
build of 
/gnu/store/lba0pd5a1hzzfbcswgx0ws1nrldfxxnp-barrier-2.4.0-checkout.drv 
failed
View build log at 
’/var/log/guix/drvs/lb/a0pd5a1hzzfbcswgx0ws1nrldfxxnp-barrier-2.4.0-checkout.drv.bz2’.
cannot build derivation 
`/gnu/store/0lwma8nhhy18z8x5v8zjjhk740bm1mv9-barrier-2.4.0.drv’: 
1 dependencies couldn’t be built
guix install: error: build of 
`/gnu/store/0lwma8nhhy18z8x5v8zjjhk740bm1mv9-barrier-2.4.0.drv’ 
failed


bug#56086: "guix build --sources=transitive hello" does not emit transitive sources >=2 layers down

2022-06-19 Thread Maxime Devos
Try:

$ guix build --sources=transitive hello

I get:

/gnu/store/3dq55rw99wdc4g4wblz7xikc8a2jy7a3-hello-2.12.1.tar.gz
/gnu/store/qz3pck1i4bply2fvxc7a5f7h3swdwpcr-tar-1.34.tar.xz
/gnu/store/5dh059d365953arhixlx4xqkngwv2jmr-gzip-1.10.tar.xz
/gnu/store/q5sqgng4wdzxr6yrvvp706kbxa3fcfjf-bzip2-1.0.8.tar.gz
/gnu/store/snk01kyfyv0xh527j2id1jbyx9snvr1h-xz-5.2.5.tar.gz
/gnu/store/b7pj6376jv658scl9159n60jq1gsggr5-file-5.39.tar.gz
/gnu/store/87aihcxj48yslw7zrc62lrbfi5llh5rh-diffutils-3.8.tar.xz
/gnu/store/l6fbym731zg72l0rwb7zgrn011ki7dcs-patch-2.7.6.tar.xz
/gnu/store/d9ylc625pszdbdzasxx3q2147dd0knia-findutils-4.8.0.tar.xz
/gnu/store/l6wssbbngsb3nr71rdlk5m834rdzz3rq-gawk-5.1.0.tar.xz
/gnu/store/52sz6j8l5xahiqq8j20vvix4gbwc1m4w-sed-4.8.tar.xz
/gnu/store/g05jqa0d8k45p3nzqggkrksgr4vr0qag-grep-3.6.tar.xz
/gnu/store/sp86vrxg16gvii6h51himf1ivhr1h46r-coreutils-8.32.tar.xz
/gnu/store/wicnb0c4b5726d8rvvhdj8kvyylhldqa-make-4.3.tar.xz
/gnu/store/cn3ian044yv1jnnwb4ai02f2hg6kgkik-bash-5.1.tar.xz
/gnu/store/nv43fwmg2c6x69sf9wh1fxbp3ca0fsdc-binutils-2.37.tar.xz
/gnu/store/d2p5gd5fxzrm6ip3lxw6q5jyxk1lbxqc-gcc-10.3.0.tar.xz
/gnu/store/70jq7j76s5wwx6v7m8fjdkihsa8k0sxb-gmp-6.0.0a.tar.xz
/gnu/store/b3xs724vl7idch20wvxll03rix9zizqb-mpfr-4.1.0.tar.xz
/gnu/store/0bhb5fidh0vz2b5p94bqyrpqw0bpgvjg-mpc-1.2.1.tar.gz
/gnu/store/ss3ciy8z30j8qcqk8zpkpdlggmwlmmv6-glibc-2.33.tar.xz
/gnu/store/a1sqrdsy1xrk6cs84kzgg93rw28zcaa4-linux-libre-5.10.35-gnu.tar.xz

However, the soure of gzip@1.2.4 appears to be missing here, even though it
is a transitive dependency (via (gnu packages commencement).

For a simpler example, consider the following package definition:

(package
 (inherit (specification->package "hello"))
 (inputs
   (list (package
   (inherit (specification->package "hello"))
   (inputs (list
 (specification->package "gnunet-scheme"

and run "guix build --sources=transitive -f [source file]".  Notice that
the gnunet-scheme package is not included.  After some
experimentation, I found that:

  * if the package is at the top, its source code is listed
  * if it's in the inputs of the package at the top, its source code is listed
  * if it's another layer down, it isn't listed anymore (see above example)

Greetings,
Maxime.


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


bug#56084: crate importer removes test dependencies for non-top-level crates

2022-06-19 Thread Maxime Devos
Hi,

The crate importer removes #:dev-dependencies (i.e., test dependencies
and for benchmarks) for non-top-level crates, presumably because they
aren't used anyway by cargo-build-system because of the #:skip-build?.

However, antioxidant implements build results reuse, and I intend to
implement running tests as well (not yet implemented) (except for when
it would cause cycles), for which these #:dev-dependencies are actually
needed.

Proposal: don't remove the dev-dependencies in (guix import crate).

Greetings,
Maxime.


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


bug#56082: home: services: openssh: identity-file could be a list of strings.

2022-06-19 Thread Oleg Pykhalov
Currently ‘identity-file’ in ‘openssh-host’ record is a ‘maybe-string’,
but it could be a list, which generates a config like:

Host example.org
  …
  IdentityFile ~/.ssh/id_rsa_1
  IdentityFile ~/.ssh/id_rsa_2
  IdentityFile ~/.ssh/id_rsa_3

SSH_CONFIG(5) man page:
 IdentityFile
 …
 It is possible to have multiple identity files specified in con‐
 figuration files; all these identities will be tried in sequence.
 Multiple IdentityFile directives will add to the list of identi‐
 ties tried (this behaviour differs from that of other configura‐
 tion directives).

Personally I use more than one ‘IdentityFile’ as a workaround to define
a big ‘ssh_config’.  SSH connects with a first successed ‘IdentityFile’.


Oleg.


signature.asc
Description: PGP signature