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

[Chris Marusich]

Hi Ludo,

Ludovic Courtès  writes:

> So you confirm that a single “echo” is not enough, right?

I didn't test one specifically. It might work with just one, but it did
work with three.  If we want to proceed with the "echo" approach, let me
know and I'll test just one echo to see if that is reliable enough.

> Perhaps we should unroll the ‘for’ loop for portability, to be on the
> safe side.  Initially I tested with Bash, Zsh, and Fish:
>
>   https://issues.guix.gnu.org/51285#0-lineno49
>
> I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
> ‘for’.

I see.  Yes, I'll do that if we decide to go with the echo-based
approach.

> I realized that setting PS1 could interfere with the logic below that
> checks for PS1.  And since it doesn’t seem to help, perhaps we can
> remove “PS1=;”?

I recall that I tried removing PS1, and I still had trouble.  I believe
it was because even if we unset PS1 as the very first command we do, the
original prompt is still printed.  Foreign distros usually set PS1 to
something, and whatever that is will be printed before we have a chance
to input any commands.  It's hard to avoid that in general.

> Thoughts?

One alternative method I tried successfully in a variety of shells was
to use shell redirection (see attached).  I like this approach.
However, this will only work in shells that support redirection.  I
recall testing with bash, ash (busybox's shell), dash, zsh, fish, ksh,
and csh.  I recall that only csh failed, since it doesn't support
redirection.

I personally like the attached patch better than what I proposed
earlier.  The earlier patch just echoes a few times.  Presumably, it
only works because the PS1 prompt is likely (but not guaranteed) to be
emitted before the last of the echo commands finishes printing.  I'd
rather just control the desired output and ignore PS1 entirely, and that
is what the attached patch accomplishes using FDs.  However, if support
for shells without redirection is a requirement, then maybe the original
hack (echo a few times) is OK, or perhaps we need something else.

How would you like to proceed?  Is it OK to rely on shell redirection?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From 9a1cef589abf01b61e22656f44c76441f4c50ffd Mon Sep 17 00:00:00 2001
From: Chris Marusich 
Date: Fri, 11 Mar 2022 00:20:12 -0800
Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.

Fixes: .

* guix/scripts/environment.scm (child-shell-environment) [shell-pipe]
[shell-pipe-in, shell-pipe-out]: New local variables.
[script]: Redirect the stdout of each command to the file descriptor of the
shell-pipe-out port.
[lines]: In the child, close shell-pipe-in before starting the shell.  In the
parent, close shell-pipe-out before sending the script to the shell.  Read
lines from shell-pipe-in, not port, so that the shell's PS1 prompt cannot
clobber the lines.  Close shell-pipe-in just before waiting on the child.
---
 guix/scripts/environment.scm | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 3216235937..f0cb341aab 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -48,6 +48,7 @@ (define-module (guix scripts environment)
   #:autoload   (gnu packages bash) (bash)
   #:autoload   (gnu packages bootstrap) (bootstrap-executable %bootstrap-guile)
   #:use-module (ice-9 match)
+  #:use-module (ice-9 format)
   #:autoload   (ice-9 rdelim) (read-line)
   #:use-module (ice-9 vlist)
   #:use-module (srfi srfi-1)
@@ -418,11 +419,23 @@ (define (child-shell-environment shell profile manifest)
   (define-values (controller inferior)
 (openpty))
 
+  (define shell-pipe (pipe))
+  (define shell-pipe-in (car shell-pipe))
+  (define shell-pipe-out (cdr shell-pipe))
+
   (define script
-;; Script to obtain the list of environment variable values.  On a POSIX
-;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
-;; 'set' truncates values and prints them in a different format.)
-"env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+;; Script to obtain the list of environment variable values.
+;;
+;; On a POSIX shell we can rely on 'set', but on fish we have to use 'env'
+;; (fish's 'set' truncates values and prints them in a different format).
+;;
+;; Unless we redirect output to a dedicated file descriptor, there is a
+;; risk that the shell's PS1 prompt might clobber the output.  See:
+;; https://issues.guix.gnu.org/53355
+(let ((out-fd (port->fdes shell-pipe-out)))
+  (format
+   #f "env 1>&~d || /usr/bin/env 1>&~d || set 1>&~d; \
+echo GUIX-CHECK-DONE 1>&~d; read x; exit\n" out-fd out-fd out-fd out-fd)))
 
   (define lines
 (match (primitive-fork)
@@ -432,17 +445,22 @@ (define lines
(load-profile profile manifest 

bug#55444: elogind startup race between shepherd and dbus-daemon

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hello!
>
> Currently (40a729a0e6f1d660b942241416c1e2c567616d4d), shepherd and
> dbus-daemon compete to start elogind: shepherd tries to start it
> eagerly, and dbus-daemon starts it on-demand upon bus activation.
>
> Sometimes dbus-daemon wins, and thus shepherd tries a few times to start
> it anyway, leading to the infamous:
>
>   elogind is already running as PID 123

Do we have a system test that sometimes reproduce it, or at least the
above message?  I have some branch where I introduce some D-Bus
synchronization primitives I had started to fix
https://issues.guix.gnu.org/issue/52051, which ended up being fixed
differently (bumping the timeout value); perhaps it could be of use
here.

Thanks,

Maxim

bug#55399: guix system reconfigure fails on channel validation

[André Batista]

Hi!

seg 23 mai 2022 às 16:18:52 (165532), l...@gnu.org enviou:
> Yes please!  You pretty much already have the code, so we could put
> together a new Guile-Git release instead of carrying these modifications
> in Guix proper.

Done! Issue 26.

https://gitlab.com/guile-git/guile-git/-/issues/26

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

On Mon, 23 May 2022 21:08:20 +0200
Denis 'GNUtoo' Carikli  wrote:
> I'll now try with the current HEAD to see if that's somehow fixed.

I've a similar failure with HEAD:
> \ 'check' phasebuilder for 
> `/gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv' 
> failed with exit code 1
> build of 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv failed
> View build log at 
> '/var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2'.
> cannot build derivation
> `/gnu/store/i6zxh4qblndfaqgz62fcm2s983pqj3ak-ruby-rubocop-1.10.0.drv':
> 1 dependencies couldn't be built

Denis.


pgpebABNWPhzO.pgp
Description: OpenPGP digital signature

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Maybe an issue is that I've 2 cores on i686 while I've 4 on armv7h.

Or Maybe I didn't see what was there before (I use screen so it's not
convenient to copy-paste the output). Now I have:
> $ guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52 -M 1 -c 1
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   f0e9048
> building 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv...
> - 'check' phasebuilder for 
> `/gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv' 
> failed with exit code 1
> build of 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv failed
> View build log at 
> '/var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2'.
> cannot build derivation 
> `/gnu/store/i6zxh4qblndfaqgz62fcm2s983pqj3ak-ruby-rubocop-1.10.0.drv': 1 
> dependencies couldn't be built
> Backtrace:
> building /gnu/store/abh2450yi3ndn66qwxlg3dpbc1j5r8g1-ruby-webmock-2.3.2.drv...
> cannot build derivation 
> `/gnu/store/pncfvxcp7irzsffydwj9f4h3i55xly11-ruby-byebug-11.1.3.drv': 1 
> dependencies couldn't be built
> building /gnu/store/8q33lywpkbx5l94hwf4k4mj6sn9zsqa2-yelp-xsl-41.0.drv...
> cannot build derivation 
> `/gnu/store/p11fi1gs5pvl8zbiqrwd5kx35x36jsk9-texlive-hyphen-afrikaans-59745.drv':
>  1 dependencies couldn't be built
> [...]
> cannot build derivation 
> `/gnu/store/76mv7y286isjcprbf4xjna9j2mhmpvky-texlive-hyphen-uppersorbian-59745.drv':
>  1 dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/m1g219klrksbrmi1x68a5n9a7aj36d9p-texlive-hyphen-welsh-59745.drv': 
> 1 dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/n5bvrf8b42cdap7abggspy96wpg22ab4-texlive-amsmath-59745.drv': 1 
> dependencies couldn't be built
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "build of 
> `/gnu/store/n5bvrf8b42cdap7abggspy96wpg22ab4-texlive-amsmath-59745.drv' 
> failed"
>   status: 100
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

And here's the log:
> $ bzcat  
> /var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2
> starting phase `set-SOURCE-DATE-EPOCH'
> phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
> starting phase `set-paths'
> environment variable `PATH' set to 
> `/gnu/store/laxk3l38cx1ighbbmhjyqi0dnqg48ps8-ruby-2.7.4/bin:/gnu/store/yg3ggbyci3c5mqmraaqhfj9vini43r4d-ruby-rake-compiler-1.1.1/bin:/gnu/store/8gnahljsd06hax5vwh5kmk751jcjjzwy-tar-1.34/bin:/gnu/store/g4fr5clvd6sb735x92dbf068jl9z0959-gzip-1.10/bin:/gnu/store/sg7xawwdh23vxb6jqbnc6sckdnx00ldg-bzip2-1.0.8/bin:/gnu/store/pps1pijrj4jcp23k658ymhisdwf58bva-xz-5.2.5/bin:/gnu/store/l8az077ik67pz29nhhjai5ra5vlrcwz4-file-5.39/bin:/gnu/store/fncbwpmpkx5walrm3bnx586wj4kppkzr-diffutils-3.8/bin:/gnu/store/408wpqw5kx0v4p304vi6g86d1a95ynyy-patch-2.7.6/bin:/gnu/store/c7md7zma2706lzn96zrnzx70pq7m2b2k-findutils-4.8.0/bin:/gnu/store/ik5jr3x2s6vr7d77lmrrc2i03mfnr3hn-gawk-5.1.0/bin:/gnu/store/8iy4h07y9rcnr0i1a17r14fl5frx283s-sed-4.8/bin:/gnu/store/14w43053md7pprc76z33rdxjwc8vnkxd-grep-3.6/bin:/gnu/store/32fqqi7hkbx22jh917mf5g7phin5r16y-coreutils-8.32/bin:/gnu/store/0nz9kdv53yf2f87bgxa6wv8fcsrsp7gi-make-4.3/bin:/gnu/store/97xwzdsw9p6019dbml5mzf781c7avfkq-bash-minimal-5.1.8/bin:/gnu/store/95fsg9yv455ybq10qs409g6wffmqpn44-ld-wrapper-0/bin:/gnu/store/aaawb28w66dpmypf7qfndp8wmgrx7d0j-binutils-2.37/bin:/gnu/store/j1qipvd6087zklgxm0b3dphsagq4s5sa-gcc-10.3.0/bin:/gnu/store/nm8h8f988c2wvjk31lg1ww5zr65cd05c-glibc-2.33/bin:/gnu/store/nm8h8f988c2wvjk31lg1ww5zr65cd05c-glibc-2.33/sbin'
> environment variable `GEM_PATH' set to 
> `/gnu/store/laxk3l38cx1ighbbmhjyqi0dnqg48ps8-ruby-2.7.4/lib/ruby/vendor_ruby:/gnu/store/mdwww2mdf58x84z7gxwhjz1p7l8dbjki-ruby-mocha-1.13.0/lib/ruby/vendor_ruby:/gnu/store/yg3ggbyci3c5mqmraaqhfj9vini43r4d-ruby-rake-compiler-1.1.1/lib/ruby/vendor_ruby'
> environment variable 

bug#55596: subversion segfaul on `guix import texlive`

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Jack Hill 写道：

"""
$ guix import texlive qrcode
command "svn" "export" "--non-interactive" "--trust-server-cert" 
"-r"

"59745"
"svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/doc/latex/qrcode/"
"/tmp/guix-directory.6aY7Gk/doc/latex/qrcode/" failed with 
signal 11

guix import: error: failed to import package 'qrcode'
"""

It seems something is unwell with our subversion package?


I don't know why I didn't think of this sooner, but I ran that svn 
command by hand (only replacing the output directory, say 
/tmp/foo) and… it ran fine.


So I checked my dmesg and it's actually Guix that's getting 
killed:


[146565.315921] guix[1767]: segfault at c0 ip 76c46ae99e70 sp 
7fffcbe9cb30 error 4 cpu 5 in 
libc-2.33.so[76c46ae57000+141000]
[146565.315937] Code: 56 41 55 41 54 55 48 89 fd 53 48 81 ec f8 04 
00 00 48 8b 05 ea 1f 15 00 48 89 34 24 89 4c 24 48 64 8b 00 89 84 
24 80 00 00 00 <8b> 87 c0 00 00 00 85 c0 0f 85 4a 02 00 00 c7 87 
c0 00 00 00 ff ff


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#55596: subversion segfaul on `guix import texlive`

[Jack Hill]

Hi Guix,

With Guix commit 4ba4cb1d49d70a00f7236f60bd92e5eccef573dd on Linux x86-64, 
I have the following problem trying to import a texlive package:


"""
$ guix import texlive qrcode
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" 
"svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/doc/latex/qrcode/" "/tmp/guix-directory.6aY7Gk/doc/latex/qrcode/" failed 
with signal 11
guix import: error: failed to import package 'qrcode'
"""

It seems something is unwell with our subversion package?

Best,
Jack

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Maxime Devos]

Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 19:30 [+0200]:
> And here I probably lack some knowledge but I was under the
> impression
> that swap was handled transparently by the kernel (through page
> tables,
> virtual memory, and so on), so applications should not notice the
> difference apart from the huge performance drop.
> 
> Though one issue could be that maybe for some reason the process
> wants
> to use more than 3GiB of memory and at least i686 processes are
> limited
> to 4GiB if you use an x86_64 kernel and about 3GiB if you use an i686
> kernel. So maybe it's somehow similar for armv7h?

That's what I was referring to.  Additionally, I've also seen ‘2GiB’
(as in: 2/2 split) mentioned somewhere, though I don't know if it
applies to arm and linux.


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

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

On Mon, 23 May 2022 16:10:04 +0200
Maxime Devos  wrote:

> Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 15:40 [+0200]:
> > Hi,
> > 
> > I've now made some free space. So we have:
> > - 1GiB of RAM and 16GiB of swap:
> >   > # cat /proc/swaps 
> >   >
> > FilenameType
> > Size Used   Priority
> >   > /dev/mmcblk0p1 
> > partition   1677721216384   -2
> 
> Could you check if it OOMs (with "sudo dmesg")?
> There were some problems in the past (maybe present too?) on i?86 with
> too much memory usage,
I've looked rapidly and I didn't see any OOMs. I've now used dmesg -c
and I'll launch the following command:
> guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52 -M 1 -c 1

And I'll see if it fails in the same way.

I also use a custom kernel and while I'm confident that the code
modifications have no impact here, I'm unsure if there are compilation
options related to OOM messages or not.

And here I probably lack some knowledge but I was under the impression
that swap was handled transparently by the kernel (through page tables,
virtual memory, and so on), so applications should not notice the
difference apart from the huge performance drop.

Though one issue could be that maybe for some reason the process wants
to use more than 3GiB of memory and at least i686 processes are limited
to 4GiB if you use an x86_64 kernel and about 3GiB if you use an i686
kernel. So maybe it's somehow similar for armv7h?

I also use Guix on an i686 installation of Parabola on my x86 laptop,
and I had issues with that in the past but recently I didn't notice
issues so at least if they are still there they are less frequent.

Maybe the difference is that on this ARM computer, I installed Guix
1.3.0 recently, and I didn't manage to do a guix pull that work yet, so
there is more diff between the current state (1.3.0) and where it wants
to go (close to HEAD on the master branch).

As of why a bigger diff would increase the probability of it failing
I've no idea.

What I could do could be to try to reproduce on an i686 Parabola VM,
this way it would be easier for people to reproduce. Though it's not
possible yet to pacstrap Parabola installations from Guix (I've some
WIP code for that but I need to fix bugs in it before being able to
send it).

Denis.


pgpc3vu3k6ufN.pgp
Description: OpenPGP digital signature

bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.

[Maxime Devos]

Brian Cully schreef op ma 23-05-2022 om 12:54 [-0400]:
> I don’t know of a good way to check this in a file-system 
> independent manner

Create a file /gnu/store/case-sensitivity-test (if it doesn't already
exist).  Open /gnu/store/CASE-SENSITIVITY-TEST.  If it succeeds, you
have a case-sensitive file system.

Greetings,
Maxime.


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

bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.

[Brian Cully via Bug reports for GNU Guix]

Maxime Devos  writes:
Not sure how a case-insensitivity would cause this, but I think 
we
can keep this open -- wouldn't it be better if "guix-daemon" 
just says

‘nope, case-sensitivity is required (*), not continuing)?

(*) For reproducible builds, and apparently for substitution.


The issue is wide-spread: there are a number of packages that will 
install files who’s names only vary by case. It’s also 
per-package; most work fine, but some will just break 
randomly. Some don’t seem to break until you try to use them, and 
then they yell and complain. This is something I run into often 
enough that it’s familiar to me and know how to fix, but not often 
enough to prevent my surprise when it happens.


Guix can’t fix it, unfortunately. Maybe checking case sensitivity 
would be a worthwhile thing to do, just to warn people, but: I 
don’t know of a good way to check this in a file-system 
independent manner, and I honestly doubt it’s something that 
actually happens that often. I’ve been trucking a ZFS storage pool 
around since I first installed it on macOS about a decade ago, and 
since macOS is case-insensitive, that’s how it was installed (case 
sensitivity causes its own issues there). Short of running Guix on 
Windows or macOS, I don’t see this being a problem.


-bjc

bug#52899: More info on guix home reconfigure behaviour

[Bastien Rivière]

Hello,

Yes, the issue is gone, thanks for the fix!

Best regards,
Bastien

On Mon, May 23, 2022, at 3:18 PM, Andrew Tropin wrote:
> On 2022-04-26 18:29, Bastien Rivière wrote:
>
>> Hello,
>>
>> Here is what I got on my end when running guix home:
>>
>>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>>> herd: exception caught while executing 'load' on service 'root':
>>> In procedure fport_write: Broken pipe
>>
>> I have same output when running ~herd load root~.
>>
>>> > herd load root /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf
>>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>>> herd: exception caught while executing 'load' on service 'root':
>>> In procedure fport_write: Broken pipe
>>
>> And the content of sheperd.conf is:
>>
>>> (begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply 
>>> register-services (map (lambda (file) (load file)) (quote 
>>> ("/gnu/store/amvwc8ljsw4v6035q5hi9wlrj5kdi8qv-shepherd-emacs-server.scm"
>>>  (action (quote root) (quote daemonize)) (format #t "Starting 
>>> services...~%") (let ((services-to-start (quote (emacs-server (if 
>>> (defined? (quote start-in-the-background)) (start-in-the-background 
>>> services-to-start) (for-each start services-to-start)) (redirect-port 
>>> (open-input-file "/dev/null") (current-input-port
>>
>> Watching the log of shepherd, I have only this line:
>>
>>> 2022-04-26 18:27:48 Loading 
>>> /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>>
>> Tell me what I can do to help you debug this.
>
> IIRC, it should be fixed already, can you please check if it's still a
> problem?
>
> -- 
> Best regards,
> Andrew Tropin
>
> Attachments:
> * signature.asc

bug#55200: Guix offload fails to allow connections while attempting to connect with the host's hostname or FQDN

[Simon Streit]

This issue is related to [1] which was resolved.  Pulling to a current
checkout solves this issue. 

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55335

bug#55335: openssh-service no longer listens on IPv6

[Simon Streit]

Ludovic Courtès  writes:

> Let me know if anything’s amiss!

Looking all good.  v4 and v6 connections are working now.

bug#55583: guix-daemon doesn't cleanly error-out on case-insensitive file systems.

[Maxime Devos]

retitle 55583 guix-daemon doesn't cleanly error-out on case-sensitive file 
systems.
thanks

Brian Cully schreef op ma 23-05-2022 om 09:00 [-0400]:
This bug was caused by having my Guix filesystem mounted on a 
case-insensitive file system. Re-running pull within the Docker 
container mounted on a case-sensitive file system works correctly.

This bug can be closed. Sorry for the noise.

-bjc

Not sure how a case-insensitivity would cause this, but I think we
can keep this open -- wouldn't it be better if "guix-daemon" just says
‘nope, case-sensitivity is required (*), not continuing)?

(*) For reproducible builds, and apparently for substitution.

Greetings,
Maxime


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

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[raingloom]

On Mon, 23 May 2022 16:10:04 +0200
Maxime Devos  wrote:

> Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 15:40 [+0200]:
> > Hi,
> > 
> > I've now made some free space. So we have:
> > - 1GiB of RAM and 16GiB of swap:
> >   > # cat /proc/swaps 
> >   >
> > FilenameType
> > Size Used   Priority
> >   > /dev/mmcblk0p1 
> > partition   1677721216384   -2  
> 
> Could you check if it OOMs (with "sudo dmesg")?
> There were some problems in the past (maybe present too?) on i?86 with
> too much memory usage,
> 
> Greetings,
> Maxime

Definitely in the present too.

bug#55399: guix system reconfigure fails on channel validation

[Ludovic Courtès]

Hi André,

André Batista  skribis:

> Anyway, the proper think to do is to update guile-git, so I'll be
> opening an issue there.

Yes please!  You pretty much already have the code, so we could put
together a new Guile-Git release instead of carrying these modifications
in Guix proper.

(For now commit b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab changes
Guile-Git in Guix to depend on libgit2 1.3 as a workaround.)

Thanks!

Ludo’.

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Maxime Devos]

Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 15:40 [+0200]:
> Hi,
> 
> I've now made some free space. So we have:
> - 1GiB of RAM and 16GiB of swap:
>   > # cat /proc/swaps 
>   >
> Filename  TypeSize
>   UsedPriority
>   > /dev/mmcblk0p1 
> partition 1677721216384   -2

Could you check if it OOMs (with "sudo dmesg")?
There were some problems in the past (maybe present too?) on i?86 with
too much memory usage,

Greetings,
Maxime


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

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Hi,

I've now made some free space. So we have:
- 1GiB of RAM and 16GiB of swap:
  > # cat /proc/swaps 
  > FilenameTypeSizeUsed
Priority
  > /dev/mmcblk0p1  partition   1677721216384   
-2

- About 6GiB of free space on / and about 30GiB of free space on /gnu:
> # df -h 
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/root   9.5G  2.8G  6.7G  30% /
> devtmpfs403M 0  403M   0% /dev
> tmpfs   500M 0  500M   0% /dev/shm
> tmpfs   200M  2.1M  198M   2% /run
> tmpfs   500M 0  500M   0% /tmp
> /dev/mmcblk2p3   16M  5.5M  9.9M  36% /efs
> /dev/mmcblk0p2   42G  3.8G   36G  10% /gnu

And in my case the TMPDIR is in /gnu/tmp so it should have plenty of
space. From /etc/systemd/system/guix-daemon.service:
> Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/root/guix-profile/lib/locale'
>  LC_ALL=en_US.utf8 TMPDIR=/gnu/tmp

So space should not be an issue anymore.

But with (I've fixed the commit to enable to retry with the same
commit):
> do guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52

I get the following error:
> Backtrace:
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))s
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/rrxr8v48zvzd73qg6f8wkn5zwbnglg5w-tar-1.34.drv' failed (usually 
> happens due to networking issues); try `--fallback' to build derivation from 
> source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

And retrying right after gives a similar error:
> Backtrace:
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/rrxr8v48zvzd73qg6f8wkn5zwbnglg5w-tar-1.34.drv' fai
> led (usually happens due to networking issues); try `--fallback' to build 
> derivation from source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

I'll try to see if guix pull also works on another ARM device (TBS
2910 with An I.MX6Q and 2GiB of RAM).

If that works I'll simply do a guix pack with -RR of valgrind and gdb
and install that in a directory that is not /gnu. So that would enable
me to keep that Guix installation and wait for help to debug that
issue.

If that doesn't work I'll unfortunately have to uninstall Guix on that
GT-I9300 variant of the Galaxy SIII and instead cross compile a guix
pack with valgrind and gdb on an x86 computer without -RR (-R and -RR
aren't supported in cross compilation).

This is because I also need to continue working on making the modem
work as part of my work on Replicant 11 (I use GNU/Linux here as they
share part of the stack and GNU/Linux is easier to work with) and I
can't delay that work forever in the hope of solving a Guix bug, and
here I've no idea of the cause and so I would need some help, and if
I keep delaying that work too much I will be in big trouble as NLnet
is running out of funds in the fund that funds this work.

bug#55335: openssh-service no longer listens on IPv6

[Ludovic Courtès]

Hi Jack,

Jack Hill  skribis:

> It's working well for me, allowing connections over both v4 and v6. I
> have another host that I can only access with a v6 via wireguard
> address, which I haven't been able to upgrade yet. I don't anticipate
> any problems there though.

Good, thanks for reporting back!

Ludo’.

bug#55139: package-location is wrong for transformed packages

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Yeah, I ended up with this [0]:
>
> (define (locate-package-via-git name)
>   "Return the location object corresponding to package NAME, searched via 
> git."
>   (let* ((input-pipe (open-pipe* OPEN_READ
>"git" "grep" "-n" "--column"
>  (format #f "^(define-public ~a$" name)))
>(output (get-string-all input-pipe)) ;file:line:column:match
>(exit-val (status:exit-val (close-pipe input-pipe
> (case exit-val
>   ((0)
>(let ((components (string-split output #\:)))
>  (location
>   (first components)   ;file
>   (string->number (second components)) ;1-indexed line
>   ;; FIXME: Comment discrepancy in (guix diagnostics), which
>   ;; says the column is 0-indexed.
>   (and=> (string->number (third components)) 1- ;0-indexed column
>   ((1) #f);no match
>   (else (error "git grep failed with status" exit-val)
>
> and it does feel silly to have to shell out to git, but it did the job.
>
> Thanks,
>
> Maxim
>
> [0]  
> https://notabug.org/apteryx/guix-api-examples/src/master/purge-python2-packages.scm#L42

Nice, it’s good to have these examples—and hopefully we’ll soon be able
to remove a whole bunch of ‘python2-’ packages!

As for ‘package-definition-location’, I don’t think we can reasonably do
any better, so I’m tempted to close the bug.

WDYT?

Ludo’.

bug#52899: More info on guix home reconfigure behaviour

[Andrew Tropin]

On 2022-04-26 18:29, Bastien Rivière wrote:

> Hello,
>
> Here is what I got on my end when running guix home:
>
>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>> herd: exception caught while executing 'load' on service 'root':
>> In procedure fport_write: Broken pipe
>
> I have same output when running ~herd load root~.
>
>> > herd load root /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf
>> Loading /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>> herd: exception caught while executing 'load' on service 'root':
>> In procedure fport_write: Broken pipe
>
> And the content of sheperd.conf is:
>
>> (begin (use-modules (srfi srfi-34) (system repl error-handling)) (apply 
>> register-services (map (lambda (file) (load file)) (quote 
>> ("/gnu/store/amvwc8ljsw4v6035q5hi9wlrj5kdi8qv-shepherd-emacs-server.scm" 
>> (action (quote root) (quote daemonize)) (format #t "Starting services...~%") 
>> (let ((services-to-start (quote (emacs-server (if (defined? (quote 
>> start-in-the-background)) (start-in-the-background services-to-start) 
>> (for-each start services-to-start)) (redirect-port (open-input-file 
>> "/dev/null") (current-input-port
>
> Watching the log of shepherd, I have only this line:
>
>> 2022-04-26 18:27:48 Loading 
>> /gnu/store/p74aw384nqzlw73ccr0167lyj8vlj3mr-shepherd.conf.
>
> Tell me what I can do to help you debug this.

IIRC, it should be fixed already, can you please check if it's still a
problem?

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#55583: nar-error on pull

[Brian Cully via Bug reports for GNU Guix]

This bug was caused by having my Guix filesystem mounted on a 
case-insensitive file system. Re-running pull within the Docker 
container mounted on a case-sensitive file system works correctly.


This bug can be closed. Sorry for the noise.

-bjc

bug#55587: `guix import texlive PKG` fails with signal 11, no output

[Hugo Nobrega]

Hello,

The guix 'texlive' package importer is not working with any package, as
far as I can tell. It does *some* legwork, managing to figure out the
correct URI of the package, but then errors out with signal 11.

Having had a look at previous bug reports, it seems this "signal 11"
thing is not new (e.g., bug#28303), but in any case I am not seeing any
output after the error (unlike what seemed to be happening in bug#28303)

Example:

hugo@hp-guix ~$ guix import texlive cite
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r"
"59745"
"svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/doc/latex/cite/"
"/tmp/guix-directory.09UnsN/doc/latex/cite/" failed with signal 11 guix
import: error: failed to import package 'cite'

Best regards,
Hugo

bug#55406: GUIX Image API: wrong fs type and flag

[Mathieu Othacehe]

Hello Pavel,

> Ok, I tried to format them :)

Thanks, I added commit messages following our guidelines, fixed the
indentation and a few other small details.

Pushed on master!

Mathieu