Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?
On 2022-05-23 03:14 +, Foo Chuan Wei wrote: > `(invoke "sh" "-c" "trap")` is merely a trivial example for > demonstrating that the shell ignores SIGINT and SIGQUIT. This might be > significant if the build step invokes the shell to do something more > significant (e.g. to build something). > > Anyway, I found that this behavior is possibly related to one specified > by POSIX [1]: > > > 2.11. Signals and Error Handling > > > > If job control is disabled (see the description of set -m) when the > > shell executes an asynchronous list, the commands in the list shall > > inherit from the shell a signal action of ignored (SIG_IGN) for the > > SIGINT and SIGQUIT signals. Maybe not. Guix's `invoke` procedure uses Guile's `system*` procedure, which ignores SIGINT and SIGQUIT as can be seen in Guile's source code: https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c?h=v3.0.8#n1524 > Do you have a solution to this problem? Guile's `system` procedure does not have this problem (compare `(system "bash -c trap")` with `(system* "bash" "-c" "trap")`). One possible solution is to replace `invoke` with `system`: diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm index 04411c02c3..fafdba9a3f 100644 --- a/gnu/packages/sml.scm +++ b/gnu/packages/sml.scm @@ -175,10 +175,14 @@ function interface, and a symbolic debugger.") "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")) ;; Build. - (invoke "./config/install.sh" "-default" - (if (string=? "i686-linux" ,(%current-system)) - "32" - "64")) + (let ((exit-code + (system (string-append "./config/install.sh -default " +(if (string=? "i686-linux" + ,(%current-system)) +"32" +"64") + (unless (zero? exit-code) + (error (format #f "Exit code: ~a" exit-code ;; Undo the binary patch. (for-each
Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?
On 2022-05-22 14:14 +, Ryan Prior wrote: > --- Original Message --- > On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei > wrote: > > > The shell in the environment where packages are built ignores SIGINT > > and SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build > > phase > > That executes a shell which traps and then immediately exits. By the > next step of the build phase execution it's already gone. The shell > isn't ignoring you - it's not running at all. `(invoke "sh" "-c" "trap")` is merely a trivial example for demonstrating that the shell ignores SIGINT and SIGQUIT. This might be significant if the build step invokes the shell to do something more significant (e.g. to build something). Anyway, I found that this behavior is possibly related to one specified by POSIX [1]: > 2.11. Signals and Error Handling > > If job control is disabled (see the description of set -m) when the > shell executes an asynchronous list, the commands in the list shall > inherit from the shell a signal action of ignored (SIG_IGN) for the > SIGINT and SIGQUIT signals. To reproduce: Method 1: $ set +m $ bash -c 'trap' & Method 2: $ bash -c 'bash -c "trap" &' Output: trap -- '' SIGINT trap -- '' SIGQUIT Method 2 probably shows what is happening in Guix. > Sounds extremely cursed. :D Do you have a solution to this problem? [1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
Why does sh in the build environment ignore SIGINT and SIGQUIT?
The shell in the environment where packages are built ignores SIGINT and SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase, this output is produced during the build: trap -- '' INT trap -- '' QUIT Why does the shell in the build environment need to ignore these two signals? For context, this affects the build of the smlnj package (gnu/packages/sml.scm). The resulting executable seems to inherit the signal dispositions of the shell where the executable is built, with the result that CTRL-C is ignored at the sml REPL.
Re: cl-gsll fails to load
On 2021-12-07 12:27 +, Guillaume Le Vaillant wrote:
> I think the problem comes from the fact that the build system for
> cl-xxx packages doesn't use the custom phases added to some sbcl-xxx
> packages (like the 'fix-cffi-paths' phase of sbcl-gsll). Instead a fixed
> set of phases is used (see '%standard-phases/source' from
> "guix/build/asdf-build-system.scm", used in the
> 'sbcl-package->cl-source-package' function from
> "guix/build-system/asdf.scm").
Are you sure about this? From my observations, the cl-xxx packages do
use the custom phases added to the sbcl-xxx packages. When I install
cl-gsll and look into its store directory
(~/.guix-profile/share/common-lisp/source/cl-gsll/), I do see the
effect of sbcl-gsll's custom phase ("fix-cffi-paths").
cl-gsll fails to load
I am using Guix on Ubuntu 20.04, and SBCL 2.1.9 (installed using `guix install sbcl`). I have installed cl-gsll (`guix install cl-gsll`), but `(asdf:load-system :gsll)` fails. Why? This is my ASDF configuration --8<---cut here---start->8--- File: ~/.config/common-lisp/source-registry.conf.d/guix-asdf.conf (:tree "~/.guix-profile/share/common-lisp/") --8<---cut here---end--->8--- This is the error message when `(asdf:load-system :gsll)` fails: --8<---cut here---start->8--- ; pkg-config libffi --cflags ; ERROR: Couldn't execute "pkg-config": No such file or directory ; Attempting to continue anyway. ; gcc -o /home/fcw/.cache/common-lisp/sbcl-2.1.9-linux-x64/gnu/store/5c2r9qg7krpnsqiia34jf6s8w71vgqsf-cl-cffi-0.24.1/share/common-lisp/source/cl-cffi/libffi/libffi-types__grovel-tmpTASQCYAW.o -c -g -Wall -Wundef -Wsign-compare -Wpointer-arith -O3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wunused-parameter -fno-omit-frame-pointer -momit-leaf-frame-pointer -fPIC -I/gnu/store/5c2r9qg7krpnsqiia34jf6s8w71vgqsf-cl-cffi-0.24.1/share/common-lisp/source/cl-cffi/ /home/fcw/.cache/common-lisp/sbcl-2.1.9-linux-x64/gnu/store/5c2r9qg7krpnsqiia34jf6s8w71vgqsf-cl-cffi-0.24.1/share/common-lisp/source/cl-cffi/libffi/libffi-types__grovel.c While evaluating the form starting at line 21, column 0 of #P"/gnu/store/q27bpjg4pcm81j9ij66fhdpvlwx3jdcz-cl-gsll-0.0.0-1.1a8ada2/share/common-lisp/source/cl-gsll/gsll.asd": debugger invoked on a ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR in thread #: Error while trying to load definition for system gsll from pathname /gnu/store/q27bpjg4pcm81j9ij66fhdpvlwx3jdcz-cl-gsll-0.0.0-1.1a8ada2/share/common-lisp/source/cl-gsll/gsll.asd: Couldn't execute "gcc": No such file or directory Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY] Retry # on #. 1: [ACCEPT ] Continue, treating # on # as having been successful. 2: [RETRY] Retry EVAL of current toplevel form. 3: [CONTINUE ] Ignore error and continue loading file "/gnu/store/q27bpjg4pcm81j9ij66fhdpvlwx3jdcz-cl-gsll-0.0.0-1.1a8ada2/share/common-lisp/source/cl-gsll/gsll.asd". 4: [ABORT] Abort loading file "/gnu/store/q27bpjg4pcm81j9ij66fhdpvlwx3jdcz-cl-gsll-0.0.0-1.1a8ada2/share/common-lisp/source/cl-gsll/gsll.asd". 5: Retry # on #. 6: Continue, treating # on # as having been successful. 7: Retry ASDF operation. 8: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 9: Retry ASDF operation. 10: Retry ASDF operation after resetting the configuration. 11: Exit debugger, returning to top level. ((FLET "H0" :IN ASDF/ACTION:PERFORM) #) ; File has been modified since compilation: ; SYS:CONTRIB;ASDF;ASDF.LISP.NEWEST ; Using form offset instead of character position. error finding frame source: invalid feature expression: "#.(UIOP/UTILITY:SYMBOL-TEST-TO-FEATURE-EXPRESSION (COMMON-LISP:QUOTE #:COMPILER-ERROR-CONTEXT-%SOURCE) (COMMON-LISP:QUOTE #:SB-C))" source: NIL 0] --8<---cut here---end--->8--- The problem does not appear when using sbcl-gsll instead of cl-gsll. How do I fix the problem when using cl-gsll? It seems to be missing some kind of input or native-input.
python-build-system does not wrap script correctly
I am trying to package "Speedometer" [1]. This is the package
definition:
--8<---cut here---start->8---
(define-public speedometer
(package
(name "speedometer")
(version "2.8")
(source
(origin
(method url-fetch)
(uri (pypi-uri "Speedometer" version))
(sha256
(base32 "0qgpjmahy0wlfszqxg0067ck2xab5k6j42d0ifxg1j281yqnm9bx"
(build-system python-build-system)
(arguments
`(#:python ,python-2))
(propagated-inputs
`(("python2-urwid" ,python2-urwid)))
(home-page "https://excess.org/speedometer/";)
(synopsis "Measure and display the rate of data across a network
connection")
(description
"Console monitor of the rate of data across a network connection or data
being stored in a file.")
(license license:lgpl2.1+)))
--8<---cut here---end--->8---
It builds and installs successfully. However, when the wrapper script is
run, this error appears:
--8<---cut here---start->8---
Traceback (most recent call last):
File
"/gnu/store/chr1cx6ia0is8s9d07s1nzdla30r6vs1-speedometer-2.8/bin/.speedometer-real",
line 11, in
load_entry_point('Speedometer==2.8', 'console_scripts', 'speedometer')()
File
"/gnu/store/d3jwdk2v7xck82z3y3hs99033m9nkkw0-python2-2.7.17/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 489, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File
"/gnu/store/d3jwdk2v7xck82z3y3hs99033m9nkkw0-python2-2.7.17/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 2852, in load_entry_point
return ep.load()
File
"/gnu/store/d3jwdk2v7xck82z3y3hs99033m9nkkw0-python2-2.7.17/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 2443, in load
return self.resolve()
File
"/gnu/store/d3jwdk2v7xck82z3y3hs99033m9nkkw0-python2-2.7.17/lib/python2.7/site-packages/pkg_resources/__init__.py",
line 2449, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File
"/gnu/store/chr1cx6ia0is8s9d07s1nzdla30r6vs1-speedometer-2.8/bin/speedometer.py",
line 2
export
PYTHONPATH="/gnu/store/chr1cx6ia0is8s9d07s1nzdla30r6vs1-speedometer-2.8/lib/python2.7/site-packages:/gnu/store/d3jwdk2v7xck82z3y3hs99033m9nkkw0-python2-2.7.17/lib/python2.7/site-packages:/gnu/store/1iszjcyvb537m6cif7fqrrh95r0sg9wp-python2-urwid-2.1.0/lib/python2.7/site-packages${PYTHONPATH:+:}$PYTHONPATH"
^
SyntaxError: invalid syntax
--8<---cut here---end--->8---
There is apparently something wrong with the wrapper script. What is it?
I worked around the problem by adding this phase:
--8<---cut here---start->8---
(add-after 'unpack 'fix-script
(lambda _
(substitute* "setup.py"
(("'scripts': \\['speedometer.py'\\],")
"'packages': ['.'],"
--8<---cut here---end--->8---
[1]: https://github.com/wardi/speedometer/tree/release-2.8
Common Lisp package: all test cases pass but 'check' phase fails
I have submitted patches to add Common Lisp packages "cl-assoc-utils" [1] and "cl-let-over-lambda" [2]. If tests are enabled in the package definition of these two packages, all test cases pass, but an error occurs at the end of the 'check' phase. For example, the error message for "cl-let-over-lambda" is: Summary: All 1 file passed. Unhandled ASDF/FIND-COMPONENT:MISSING-DEPENDENCY in thread #: Component LET-OVER-LAMBDA-ASD::LET-OVER-LAMBDA-TEST not found, required by # In lisp-xyz.scm, I see that the "cl-locale" package has the same problem with its tests. Does anyone here know the cause of the error above? [1]: https://lists.gnu.org/archive/html/guix-patches/2021-11/msg00786.html [2]: https://lists.gnu.org/archive/html/guix-patches/2021-11/msg00787.html
