bug#63756: python-shiboken-6-6.3.2 fails to build
python-shiboken-6 fails to build on Guix
guix b96b82b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master commit: b96b82bcd4bc24529941ff74a91432481f1a71b5
With this error thrown during the build process:
Traceback (most recent call last):
File
"/tmp/guix-build-python-shiboken-6-6.3.2.drv-0/pyside-setup-opensource-src-6.3.2/sources/shiboken6/libshiboken/embed/embedding_generator.py",
line 255, in
create_zipfile(args.use_pyc, args.quiet)
File
"/tmp/guix-build-python-shiboken-6-6.3.2.drv-0/pyside-setup-opensource-src-6.3.2/sources/shiboken6/libshiboken/embed/embedding_generator.py",
line 130, in create_zipfile
with open(boot_name, "rb") as ldr, open("signature_bootstrap_inc.h", "w") as
inc:
FileNotFoundError: [Errno 2] No such file or directory:
'signature_bootstrap.pyc'
make[2]: *** [libshiboken/CMakeFiles/libshiboken.dir/build.make:92:
libshiboken/embed/signature_bootstrap_inc.h] Error 1
make[2]: Leaving directory
'/tmp/guix-build-python-shiboken-6-6.3.2.drv-0/pyside-setup-opensource-src-6.3.2/sources/build'
make[1]: *** [CMakeFiles/Makefile2:405:
libshiboken/CMakeFiles/libshiboken.dir/all] Error 2make[1]: *** Waiting for
unfinished jobs
bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading
Hi, Christopher Baines skribis: > May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and > (defined? (quote transient?)) (map (# ?) ?)). > May 24 11:17:02 localhost shepherd[1]: Evaluating user expression > (register-services (primitive-load "/gnu/st?") ?). > May 24 11:17:03 localhost shepherd[1]: Service host-name has been started. > May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started. > May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1 > May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1 > May 24 11:18:41 localhost shepherd[1]: Exiting shepherd... > May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; > sending -337 SIGKILL. > May 24 11:23:55 localhost shepherd[1]: Service root is not running. The grace period expiration thing is probably due to the fact that shepherd is no longer processing signals, as I described here: https://issues.guix.gnu.org/63736 Could you share all of /var/log/messages (possibly privately, and limiting to “shepherd” lines) starting from when the machine booted? I’d like to see if there are hints of something that went wrong. Ludo’.
bug#63736: [Shepherd] Loss of SIGCHLD notifications
Ludovic Courtès skribis: > Long story short: there seems to be a problem with signal delivery. > Most likely, the initial grace period expiration above when stopping > nscd is a symptom of shepherd no longer receiving/processing SIGCHLD > rather than the cause. Another possibility is lockup: one of the relevant fibers is either gone or stuck in ‘put-message’ or ‘get-message’. I did two things: b9a37f3 shepherd: Make signal handling fiber an essential task. 8ae2780 service: Do not attempt to restart transient services. Commit 8ae2780 fixes a bug whereby ‘herd restart’ could end up attempting to restart a transient service, which would lock up the calling fiber because the service’s controlling fiber would first receive the 'terminate message, so it would return and nobody would be reading further messages send on its channel. Commit b9a37f3 will allows us to ensure that the signal-handling fiber never exits (and we’ll get a trace in the log if it tries to). Ludo’.
bug#53580: shepherd's architecture
[forked from: bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system] > So I think we’re mostly okay now. The one thing we could do is load > the whole config file in a separate fiber, and maybe it’s fine to keep > going even when there’s an error during config file evaluation? > > WDYT? i think there's a fundamental issue to be resolved here, and addressing that would implicitly resolve the entire class of issues that this one belongs to. guile (shepherd) is run as the init process, and because of that it may not exit or be respawn. but at the same time when we reconfigure a guix system, then shepherd's config should not only be reloaded, but its internal state merged with the new config, and potentially even with an evolved shepherd codebase. i still lack a proper mental model of all this to succesfully predict what will happen when i `guix system reconfigure` after i `guix pull`-ed my service code, and/or changed the config of my services. this problem of migration is pretty much a CS research topic... ideally, there should be a non-shepherd-specific protocol defined for such migrations, and the new shpeherd codebase could migrate its state from the old to the new, with most of the migration code being automatic. some of it must be hand written as rquired by some semantic changes. even more ideally, we should reflexive systems; admit that source code is a graph, and store it as one (as opposed to a string of characters); and our systems should have orthogonal persistency, etc, etc... a far cry from what we have now. Fare's excellent blog has some visionary thoughts on this, especially in: https://ngnghm.github.io/blog/2015/09/08/chapter-5-non-stop-change/ but given that we will not have these any time soon... what can we do now? note: what follows are wild ideas, and i'm not sure i have the necessary understanding of the involved subsystems to properly judge their feasibility... so take them with a pinch of salt. idea 1 it doesn't seem to be an insurmontable task to make sure that guile can safely unlink a module from its heap, check if there are any references into the module to be dropped, and then reload this module from disk. the already runing fibers would keep the required code in the heap until after they are stopped/restarted. then the module would get GC'd eventually. this would help solve the problem that a reconfigured service may have a completely different start/stop code. and by taking some careful shortcuts we may be able to make reloading work without having to stop the service process in question. idea 2 another, probably better idea: split up shepherd's codebase into isolated parts: 1) the init process 2) the service runners, which are spawned by 1). let's call this part 'the runner'. 3) the CLI scripts that implement stuff like `reboot` by sending a message to 1). the runner would spawn and manage the actual daemon binaries/processes. the init process would communicate with the runners through a channel/pipe that is created when the runner are spawn. i.e. here we wouldn't need an IPC socket file like we need for the communication between the scripts and the init process. AFAIU the internal structure of shepherd is already turning into something like this with the use of fibers and channels. i suspect Ludo has something like this on his mind already. in this setup most of the complexity and the evolution of the shepherd codebase would happen in the runner, and the other two parts could be kept minimal and would rarely need to change (and thus require a reboot). the need for a reboot could be detected by noticing that the compiled binary of the init process has changed compared to what is currently running as PID 1. the driver process of a service could be reloaded/respawned the next time when the daemon is stopped or it quits unexpectedly. recently i've succesfully wrote a shepherd service that spawns a daemon, and from a fiber it does two way communication with the daemon using a pipe connected to the daemon's stdio. i guess that counts as a proof of concept for the second idea, but i'm not sure about its stability. a stuck/failing service is a different issue than a stuck/failing init process. for reference, the spawning of the daemon: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/services/swarm.scm#L315 the fiber's code that talks to it: https://github.com/attila-lendvai/guix-crypto/blob/8f996239bb8c2a1103c3e54605faf680fe1ed093/src/guix-crypto/swarm-utils.scm#L133 -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We reject: kings, presidents and voting. We believe in: rough consensus and running code.” — David Clark for the IETF
bug#63526: [PATCH v2] gnu (hubbub): Fix build
Fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
* gnu/packages/web.scm (hubbub): [source](patches): Add patch to fix build.
*
gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch:
New file
* gnu/local.mk (dist_patch_DATA): Add it.
---
gnu/local.mk | 2 +
...aybe-uninitialized-build-failure-wit.patch | 40 +++
gnu/packages/web.scm | 4 +-
3 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644
gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 18e8235140..e2b42ca676 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -58,6 +58,7 @@
# Copyright © 2022 jgart
# Copyright © 2023 Zheng Junjie <873216...@qq.com>
# Copyright © 2023 Ivana Drazovic
+# Copyright © 2023 Andy Tai
#
# This file is part of GNU Guix.
#
@@ -1349,6 +1350,7 @@ dist_patch_DATA =
\
%D%/packages/patches/http-parser-CVE-2020-8287.patch \
%D%/packages/patches/htslib-for-stringtie.patch \
%D%/packages/patches/hubbub-sort-entities.patch \
+
%D%/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
\
%D%/packages/patches/hueplusplus-mbedtls.patch \
%D%/packages/patches/hurd-add-without-rump-configure-option.patch \
%D%/packages/patches/hurd-fix-types-of-read-write-and-readables-methods-2.patch
\
diff --git
a/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
b/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
new file mode 100644
index 00..6f289a770e
--- /dev/null
+++
b/gnu/packages/patches/hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch
@@ -0,0 +1,40 @@
+From 69d81a8a4d4c223aad67cde0fdf64d64351b9802 Mon Sep 17 00:00:00 2001
+From: Andy Tai
+Date: Sat, 27 May 2023 00:01:34 -0700
+Subject: [PATCH] prevent -Werror=maybe-uninitialized build failure with gcc 11
+ when building tests tokeniser2 and tokeniser3
+
+---
+ test/tokeniser2.c | 2 +-
+ test/tokeniser3.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/test/tokeniser2.c b/test/tokeniser2.c
+index c8ab9c0..4caae38 100644
+--- a/test/tokeniser2.c
b/test/tokeniser2.c
+@@ -438,7 +438,7 @@ hubbub_error token_handler(const hubbub_token *token, void
*pw)
+ /* Expected token only contained part of the data
+* Calculate how much is left, then try again with
+* the next expected token */
+- hubbub_token t;
++ hubbub_token t = { 0 };
+
+ t.type = HUBBUB_TOKEN_CHARACTER;
+ t.data.character.ptr += len;
+diff --git a/test/tokeniser3.c b/test/tokeniser3.c
+index e33d018..b3be901 100644
+--- a/test/tokeniser3.c
b/test/tokeniser3.c
+@@ -447,7 +447,7 @@ hubbub_error token_handler(const hubbub_token *token, void
*pw)
+ /* Expected token only contained part of the data
+* Calculate how much is left, then try again with
+* the next expected token */
+- hubbub_token t;
++ hubbub_token t = { 0 };
+
+ t.type = HUBBUB_TOKEN_CHARACTER;
+ t.data.character.ptr += len;
+--
+2.40.1
+
diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 3af4aa0b8d..387ceac058 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -5242,7 +5242,9 @@ (define-public hubbub
(sha256
(base32
"1dimfyblmym98qa1b80c5jslv2zk8r44xbdrgrsrw1n9wr9y4yly"))
- (patches (search-patches "hubbub-sort-entities.patch"
+ (patches (search-patches
+ "hubbub-sort-entities.patch"
+
"hubbub-prevent-Werror-maybe-uninitialized-build-failure-wit.patch"
(build-system gnu-build-system)
(native-inputs
(list netsurf-buildsystem
base-commit: b96b82bcd4bc24529941ff74a91432481f1a71b5
--
2.40.1
