Hi, I use guix on Arch Linux, version 050be36cbf3a42199f64f2e44c59f1cb1b3afab5. When I run guix build --check kakoune everything builds correctly. Now I change original `source` definition to fetch not from url but from git repository. Original source and version: (version "2020.09.01") (source (origin (method url-fetch) (uri (string-append "https://github.com/mawww/kakoune/" "releases/download/v" version "/" "kakoune-" version ".tar.bz2")) (sha256 (base32 "0x81rxy7bqnhd9374g5ypy4w4nxmm0vnqw6b52bf62jxdg2qj6l6")))) And my modified kakoune package: (define-module (mykak) #:use-module (guix packages) #:use-module (guix git-download) #:use-module (gnu packages text-editors)) (package (inherit kakoune) (version "2020.09.01") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/mawww/kakoune.git") (commit (string-append "v" version)))) (file-name (git-file-name "mykak" version)) (sha256 (base32 "091qzk0qs7hql0q51hix99srgma35mhdnjfd5ncfba1bmc1h8x5i"))))) Now when I run to build this package, assuming it is named `kakoune.scm`: guix build --check -f kakoune.scm it freezes with this output: phase `build' succeeded after 29.7 seconds starting phase `check' ln -sf kak.opt kak cd ../test && ./run kak-tests.R6Lc8cJk compose And the problem as I figured out with printf debugging is on this line: https://github.com/mawww/kakoune/blob/v2020.09.01/test/run#L71 Same result is when I manually download tarball from github, unpack and use it to build the package: (define-module (mykak) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix gexp) #:use-module (gnu packages text-editors)) (package (inherit kakoune) (version "2020.09.01") (source (local-file "/tmp/kakoune-2020.09.01" #:recursive? #t))) I have assumption that this is somehow connected with read-write permissions because when I keep failed builds and later try to delete them, it asks whether I really want to delete some read-only files. I have no idea how exactly that `test/run` script works with all the pipes and output redirection. And I have no idea how to check why this build phase hangs. Any tips would be really helpful. Regards, Dmitry.
Hey!
Pretty cool question, let's see if my Bash skills are not lost like tears
in the rain.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, April 18, 2021 8:26 AM, Dmitry Matveyev <greenfork.lists@yandex.com> wrote:
>
> I have assumption that this is somehow connected with read-write
> permissions because when I keep failed builds and later try to delete
> them, it asks whether I really want to delete some read-only files.
>
> I have no idea how exactly that `test/run` script works with all the
> pipes and output redirection. And I have no idea how to check why this
> build phase hangs. Any tips would be really helpful.
I agree, it looks like it's related with that.
That `cat` you marked there is reading from the file descriptor 4 and
discarding its output. That's not a reasonable thing to do in general,
*unless* you are reading from a file that is being written to as a
pipe (this case is a named pipe, done with `mkfifo`).
The `exec 4<ui-out 3>ui-in` is opening those files and binding them
to the file descriptors. So any time you see reading from the fd 4 they
are reading from ui-out
Pipes are special files that can be used for inter-process communication
in this case I think this cat is reading from the pipe until it's
empty, in order to consume the data that is being sent by a process.
My guess is that the ui-out and ui-in fifos don't have write permission
so the process is not able to run, and it hangs in the write, or it's
the `cat` who dies in the reading from an empty fifo. It's going to
wait until an EOF comes, and that's not happening, because none can
write the EOF there.
Does this make any sense?
HTH,
Ekaitz
Hi, Ekaitz!
Ekaitz Zarraga <ekaitz@elenq.tech> writes:
> Does this make any sense?
Thank you a lot, this totally makes sense. I will try to find out why
this is happening further.
Regards,
Dmitry.