bug#70278: udevd[87]: specified group 'sgx' unknown

Hi, Liliana Marie Prikler skribis: > Am Donnerstag, dem 11.04.2024 um 09:58 +0200 schrieb Ludovic Courtès: >> Ludovic Courtès skribis: >> >> > Since the recent ‘gnome-team’ merge, we get this message at boot >> > time: >> > >> >   udevd[87]:

bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial

Simon Tournier skribis: > Hi Ludo, > > On Fri, 12 Apr 2024 at 11:30, Ludovic Courtès > wrote: > >> > $ guix build -S -d hg-commitsigs >> > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% >> > 3,

bug#59365: make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux

Hello, Ludovic Courtès skribis: >> GC Warning: Failed to expand heap by 285216768 bytes >> GC Warning: Failed to expand heap by 268439552 bytes >> GC Warning: Out of Memory! Heap size: 3620 MiB. Returning NULL! >> Warning: Unwind-only out of memory exception; ski

bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial

Hello! Simon Tournier skribis: > $ guix build -S -d hg-commitsigs > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > 3,7 MB will be downloaded: > /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 > substituting

bug#70278: udevd[87]: specified group 'sgx' unknown

Ludovic Courtès skribis: > Since the recent ‘gnome-team’ merge, we get this message at boot time: > > udevd[87]: specified group 'sgx' unknown > > Should we add ‘sgx’ to ‘%base-groups’? (What is it for?) Cc’ing Vivien & Liliana who might know more about this. Ludo’.

bug#70275: Epiphany requires /run/current-system/profile/sbin/dbus-launch

Ludovic Courtès skribis: > (epiphany:9264): epiphany-WARNING **: 14:39:27.754: Web process crashed > > (process:2): libportal-CRITICAL **: 14:39:27.997: Failed to create XdpPortal > instance: Failed to execute child process “dbus-launch” (No such file or > directory) This

bug#70278: udevd[87]: specified group 'sgx' unknown

Since the recent ‘gnome-team’ merge, we get this message at boot time: udevd[87]: specified group 'sgx' unknown Should we add ‘sgx’ to ‘%base-groups’? (What is it for?) Ludo’.

bug#70275: Epiphany requires /run/current-system/profile/sbin/dbus-launch

Since the GNOME 44 upgrade, Epiphany no longer works for me (I’m using EXWM, not GNOME): --8<---cut here---start->8--- $ guix describe Generation 299 Apr 08 2024 00:55:02(current) shepherd d8d96fc repository URL:

bug#70239: (operating-system) structure requires a kernel

Hi, Tomas Volf <~@wolfsden.cz> skribis: > (operating-system > (host-name "guix") > ;; Servers usually use UTC regardless of the location. > (timezone "Etc/UTC") > (locale "en_US.utf8") > (firmware '()) > (initrd-modules '()) > ; (kernel

bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service

Hi, aurtzy skribis: > On 4/7/24 19:43, Ludovic Courtès wrote: >> Oops, sorry for not noticing it earlier! (That was a hard-to-debug one >> so kudos for the work you and others put in it.) >> >> I pushed these two commits to address the problem: >> >>4

bug#70051: bug#70266: Failure to open LUKS devices from a Shepherd service

Hi aurtzy, aurtzy skribis: > This bug has also been reported here: https://issues.guix.gnu.org/70051 > > I sent a patch that a few others have confirmed fixes the issue: > https://issues.guix.gnu.org/70051#5 Oops, sorry for not noticing it earlier! (That was a hard-to-debug one so kudos for

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

Ludovic Courtès skribis: > Ludovic Courtès skribis: > >> root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep >> machines.scm >> /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm >> root@hydra-guix-108 ~# ls -l /etc/guix/machines.sc

bug#70266: Failure to open LUKS devices from a Shepherd service

Ludovic Courtès skribis: > Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression: > when a ‘luks-device-mapping’ mapped device is opened from a Shepherd > service (for instance a ‘device-mapping-XXX’ service created by > ‘device-mapping-service-type’ because

bug#70266: Failure to open LUKS devices from a Shepherd service

Hello, Commit 6f9d844d2ece7b369d17bbe678978462425f869c led to a regression: when a ‘luks-device-mapping’ mapped device is opened from a Shepherd service (for instance a ‘device-mapping-XXX’ service created by ‘device-mapping-service-type’ because, say, /home is a separate LUKS partition), said

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

Ludovic Courtès skribis: > root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep > machines.scm > /gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm > root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm > lrwxrwxrwx 1 root root 56 Mar 7 11:53 /etc/gu

bug#42379: uninstaller

Hi, David Redick skribis: > So I installed guix as a guest on my debian laptop as an evaluation. > > Unfortunately, I couldn't find an uninstaller so I modified the > guix-install.sh to support a --uninstall parameter that would remove > guix from the host system. Thanks for the patch. It’s

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

Hi, Efraim Flashner skribis: > Some of the build nodes behind the Berlin build farm have a childhurd > which can build packages. Unfortunately, the symlink from > /etc/guix/machines.scm to the generated file in the store to setup > offloading has been garbage collected on several of the

bug#54447: cuirass: missing derivation error

Hello! News from the everlasting bug! cannot build missing derivation ‘/gnu/store/dfgc46q3l8wlnymv49a1wjnxypin8p0y-plink-1.07.drv’ (From .) Why was it missing this time? /var/log/nginx/error.log: --8<---cut

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

Ludovic Courtès skribis: > The ‘cuirass remote-server’ process goes awry when misbehaved clients > connect; specifically, some of its fibers crash, leaving it running but > inactive: > > 2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds > 2023-12-04 10:13:28

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

Hi, Maxim Cournoyer skribis: > Ludovic Courtès writes: > >> The ‘cuirass remote-server’ process goes awry when misbehaved clients >> connect; specifically, some of its fibers crash, leaving it running but >> inactive: > > I guess what I reported in bug#67633 is

bug#67649: shepherd: (shepherd support) is visible for start GEXP

Hi, Ludovic Courtès skribis: > This is a Guix bug we can fix by loading each service file in a fresh > module: [...] > I’ll push the patch soonish. Pushed as 6f9d844d2ece7b369d17bbe678978462425f869c last week. Thanks! Ludo’.

bug#68415: User's shepherd services defined in guix home config can not start after guix pull.

Hi, Feng Shu skribis: > Today, after I guix pull again and reconfig guix home, this problem > dispear, I do not know why :-) > >> Feng Shu writes: [...] >>> I tried, but I do not know why: unbound-variable service I believe this problem was due to the fact that you were running shepherd <

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

Tanguy LE CARROUR skribis: >> PS: I hear more and more long-time Python developers dismayed by the sad >> state of packaging and code evolution in Python. In Guile land, we >> say: refugees welcome! Come discover a great language and a great >> community (together with their own

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

Hi, Tanguy LE CARROUR skribis: > Quoting Ludovic Courtès (2024-03-26 17:04:52) [...] >> But then I mean, we could offer, say, ‘guix import upstream https://…’, >> and that thing could parse ‘setup.py’ or similar to produce a package >> definition from that. > >

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

Hello! Tanguy LE CARROUR skribis: > I’m pretty sure you know everything that I’m about to write, but better > say it out loud… Nope, I know nothing (I’ve just been told about using ‘pyproject.toml’ and it seemed to kinda make sense. :-)) > For a "standard modern" project managed with Poetry,

bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

Hello Python team! Should ‘guix import pypi’ attempt to get dependency information from ‘pyproject.toml’, in addition to ‘requirements.txt’ and wheel ‘METADATA’ as it already does? It might be more complicated than we’d like: in some cases, that file seems to be used as a “trampoline” to Poetry.

bug#67649: shepherd: (shepherd support) is visible for start GEXP

Hi, Attila Lendvai skribis: > start GEXP's of services are loaded into unnamed modules. the definitions > from (shepherd support) are visible in these unnamed modules. see the > attached rerpoducer. It’s more than (shepherd support): --8<---cut

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

Christopher Baines skribis: > I believe I sorted access for Ludo, but nothing was found when looking > at the logs. I’m closing it. Let’s reopen if we stumble upon a similar issue. Ludo’.

bug#68591: Error when using shepherd on foreign distro

Hi Einar, Einar Largenius skribis: > I am setting up shepherd for use by my user account on a foreign distro. I > setup as described in the manual in the section "(shepherd) Managing User > Services". When I try to run it using shepherd, it crashes on the line: > > ;; Send shepherd into

bug#67565: shepherd: FAIL: tests/close-on-exec.sh

Hi, Attila Lendvai skribis: > this log file is with my shepherd branch, i.e. it contains much more log. Could you check whether it happens with current ‘main’? The test is quite sensitive to anything that would open file descriptors, as you can imagine. Thanks, Ludo’.

bug#65463: Herd `fport_write: Broken pipe` error when running `guix home reconfigure`

Hi Richard and all, Richard Sent skribis: > However, when fish is in charge of executing on-first-login, stdout and > stderr for the user shepherd get directed to a pipe instead of > /dev/null. > > fish fds, both stdout and stderr point to a pipe: > > $ ls -l /proc//fd) > lr-x-- 1

bug#67886: herd status does not execute in virsh and macos arm64 m1 - I can press enter multiple time

Hi Roman, Sorry for the delay. Roman Frołow skribis: > guix system image --system=aarch64-linux --image-type=uncompressed-iso9660 > /gnu/store/dgiaqzxx743na0fd88a0mzj7f8jmcj5n-guix-29c94dd52-modules/share/guile/site/3.0/gnu/system/install.scm [...] > I was able to install guix. > > After

bug#66705: ‘guix shell -CW’ provides a Guix command without extra channels

Hello! I’m glad to report that this bug is fixed by c90a4e8dcd6ac650392ffcc039273baf145aa3cc. In these examples, you can see that all my channels are present, both in a bare-bones ‘shell -CW’ (where bin/ is a direct symlink to the ‘guix pull’ profile) and in ‘shell -CW coreutils’ (where bin/

bug#69812: Python fails to build on Alpine linux

Hi! Tomas Volf <~@wolfsden.cz> skribis: > 0:02:13 load avg: 9.09 Re-running test_fcntl in verbose mode (matching: > test_fcntl_64_bit) > struct.pack: > b'\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' > test_fcntl_64_bit

bug#69609: Missing Disarchive info for isl-0.19.tar.bz2

Hello, We have an empty Disarchive spec here: https://disarchive.ngyro.com/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8 https://disarchive.guix.gnu.org/sha256/d59726f34f7852a081fbd3defd1ab2136f174110fc2e0c8d10bb122173fa9ed8 This is for isl-0.19.tar.bz2, a

bug#68848: bug#68857: gnu: home: dotfiles: Avoid creating extra directory in $HOME.

Hi, Giacomo Leidi skribis: > The current implementation of the home-dotfiles-service-type contradicts > the Guix manual (see https://issues.guix.gnu.org/68848 ). This patch > properly implements both the plain and Stow dotfiles directory layouts. > > It does so by refactoring

bug#69596: ‘guix publish’ memory leak

It seems that ‘guix publish’ has been leaking memory noticeably I’d say since the beginning of the year on berlin. After roughly 10 days, it has several GiB resident and needs to be restarted or it becomes too unresponsive. I wonder what could be causing this because we used to let it run for

bug#69442: Discovered substitute servers not removed when they go offline

Hello, Substitute servers discovered over Avahi don’t disappear when they go off-line: they remain in /var/guix/discover/publish “forever” (?) and ‘guix substitute’ keeps trying to connect to them, in vain. The problem AIUI is that the mDNS records are still valid according to their TTL and thus

bug#68800: Guix waits for termination of a kernel thread

Hi Tomas, Tomas Volf <~@wolfsden.cz> skribis: >> What about this method (from shepherd)? >> >> --8<---cut here---start->8--- >> (define (linux-process-flags pid) >> "Return the process flags of @var{pid} (or'd @code{PF_} constants), >> assuming >> the Linux

bug#69070: No releases/revisions in /snapshot endpoints?

Dear SWH, In I stumbled upon what might be new behavior from the /snapshot endpoint: > The crux of the problem is that ‘snapshot-branches’ used to return > either a “revision” or a “release”, but now it can also return a > “directory”: > > $ wget -qO- >

bug#65847: system container gathering entropy takes forever

Hi, Jurij skribis: > Your container is running. > > Try to reach it, via: > sudo nsenter -a -t sh Indeed. The problem is that the “entry point” (in Docker parlance) of images created by ‘guix system image -t docker’ is shepherd (PID 1), and shepherd never exits. Ludo’.

bug#69058: Failure when fallback to Disarchive+SWH

Hi, Simon Tournier skribis: >> Fixed in 1610a632d4b3097282d18af27ff3e9e178d7dfcb. > > Cool! Thanks. > > However, it means that it stays broken for all commits before this fix, > right? Somehow, if only SWH is available, then > > guix time-machine -C channels.scm -- shell -m manifest.scm >

bug#51726: SWH: ‘lookup-origin-revision’ can miss tags

Ludovic Courtès skribis: > Quoting > <https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00291.html>: > >> However, I get this: >> >> $ guix lint -c archival sway >> gnu/packages/wm.scm:1527:5: sway@1.5.1: scheduled Sof

bug#69058: Failure when fallback to Disarchive+SWH

Ludovic Courtès skribis: > I can reproduce it with c4372f7ebfac17236299346fe60c6ca125336b1f: > > scheme@(guile-user)> (swh-download "https://gitlab.com/geontime/redkite.git; > "v0.8.0" "/tmp/redkite") > SWH: found revision 68276b9b88491198c33b03c4188d

bug#69058: Failure when fallback to Disarchive+SWH

Hi, Simon Tournier skribis: > Another example using Git. It is from v1.1.0. > > $ guix time-machine -q --commit=v1.1.0 -- build -S redkite > guile: warning: failed to install locale > The following derivation will be built: >

bug#69070: ‘guix lint -c archival python-scikit-learn’ crashes

Hi! Starting from a couple of weeks ago, probably around the time SWH deployed an updated version of their infrastructure, we get crashes like this: --8<---cut here---start->8--- $ guix describe Generation 290 Feb 11 2024 23:01:35(current) guix c4372f7

bug#68595: VLANs in static-networking-service-type hangs shepherd

Hi, Lars Rustand skribis: > Like the title says, if you add any VLAN in a > static-networking-service-type it seems like the whole shepherd daemon > freezes up and anything that depends on it stops responding. > Additionally the networking does not get fully configured either. > > After

bug#29365: [bug#68720] [PATCH] gnu: openmolar-1: Update to release 1.1.6-g81838c8 and partial runtime fix.

Hi, Marco Rimoldi skribis: > This commit fixes https://issues.guix.gnu.org/29365. Alright, applied! > The package now fails to start with this error message: > > File >

bug#68474: [PATCH] tls: Fix openssl-1.0 check phase.

Hello, Jean-Pierre De Jesus DIAZ skribis: > From: Jean-Pierre De Jesus DIAZ > > * modules/past/packages/tls.scm (openssl-1.0): Fix a time bomb in > cms-test.pl due to expired certificates. Perfect. Pushed, thanks! Ludo’.

bug#68822: Channel dependencies picked at the wrong commit

Ludovic Courtès skribis: > When a channel is specified both implicitly, as the dependency of > another channel, and explicitly, in the user-provided channels file, the > “most specific” one wins—the one that has a non-#f ‘commit’ field. > > However, the dependencies of that chan

bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests

Hi, Jean-Pierre De Jesus Diaz skribis: > And the from the error file that the test writes: > > $ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err > Verification failure > 140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate > verify

bug#68822: Channel dependencies picked at the wrong commit

When a channel is specified both implicitly, as the dependency of another channel, and explicitly, in the user-provided channels file, the “most specific” one wins—the one that has a non-#f ‘commit’ field. However, the dependencies of that channel may be read from the wrong one—the least-specific

bug#68797: Channel dependencies should be propagated

Hello! With channels flourishing, we found a bug that’s always been there. When channel C depends on B, which depends on A, in general you need both A and B to be present in the build environment of C (the derivation that compiles C when you run ‘pull’ or ‘time-machine’) because potentially B is

bug#47217: generic-html updater does not work with sqlite package

Hi! Maxim Cournoyer skribis: > Ludovic Courtès writes: > >> Léo Le Bouter skribis: >> >>> + (properties >>> +`((release-monitoring-url . "https://sqlite.org/download.html;))) >> >> Unfortunately this page uses JavaScript. Without JS,

bug#39885: Bioconductor tarballs are not archived

Hi Timothy, Timothy Sample skribis: > Hello, > > Ludovic Courtès writes: > >> As for past tarballs, #swh-devel comrades say we could send them a list >> of URLs and they’d create “Save Code Now” requests on our behalf (we >> cannot do it ourselves since the site

bug#68413: Ungexp doesn't work on deep lists

Hi, Josselin Poiret skribis: > Justin Veilleux writes: > >>> (define packages >>> (list >>> (cons "coreutils" coreutils) >>> (cons "make" gnu-make) >>> ...)) >>> >>> #~(for-each >>>(lambda (f) >>> ... do-something) >>>'#$packages) >> >> If I send

bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

Hi, Ludovic Courtès skribis: > Cuirass commits 10a5117936bb51c54a362172b6e53ef5150ab909 and > b8ee2486ce877e42a3f910610d3efa8274e2603f appear to fix issues when > building in local build mode that most likely explain what you were > observing. If you run ‘guix pull’ now, you’ll

bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

Hi, Maxim Cournoyer skribis: > Simon Tournier writes: > >> Hi Inria’s folks, :-) >> >> On Sat, 02 Dec 2023 at 18:13, Maxim Cournoyer >> wrote: >> >>> I'd rather we try it with a few more software such as 'dnf' to narrow it >>> down to just 'yum', or some other issues in our Guix-generated

bug#68378: Gawk 5.3.0 test suite fails non-deterministically

Hello, Evaluation of ‘core-updates’ (commit ec1ce76a3a604efdc329b482fb46fa03cd11e184) failed due to test failures in /gnu/store/pjdg38adv5d8lad0kk7cga4dd57cpvb4-gawk-5.3.0.drv: --8<---cut here---start->8--- --- time.ok

bug#68333: Time bomb in icedtea/openjdk

Ludovic Courtès skribis: >>From 92561a776ad88eb73034948beedbe9e6be4077b4 Mon Sep 17 00:00:00 2001 > Message-ID: > <92561a776ad88eb73034948beedbe9e6be4077b4.1704897216.git.l...@gnu.org> > From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= > Date: Wed, 10 Jan 2024 15:27:47 +0100 &g

bug#68333: Time bomb in icedtea/openjdk

Hi, Rostislav Svoboda skribis: > From 1e86e32825a5025b4ef439e7f678143416f622b5 Mon Sep 17 00:00:00 2001 > Message-ID: > <1e86e32825a5025b4ef439e7f678143416f622b5.1704815654.git.rostislav.svob...@gmail.com> > From: Rostislav Svoboda > Date: Tue, 9 Jan 2024 14:08:02 +0100 > Subject: [PATCH]

bug#68237: Cuirass 1.2.0-1.bdc1f9f local builds never occur

Hi Collin and Kjetil, "Collin J. Doering" skribis: > After updating cuirass (details below), my cuirass instance no longer builds > anything! It continues to poll channels, run evaluations and queue builds, > but none of the builds ever run. > > Before: Cuirass 1.1.0-13.1341725 (guix checkout

bug#68333: Time bomb in icedtea/openjdk

Hello! Julien Lepiller skribis: > There seems to be a time bomb in icedtea@2 and openjdk@9. while > building it: > > Error: time is more than 10 years from present: 138852720 > java.lang.RuntimeException: time is more than 10 years from present: > 138852720 at >

bug#39885: Bioconductor URI, fallback and time-machine

Hi, (Replying to a 1.5-year-old message…) Ricardo Wurmus skribis: > I have finally taken the time to review this and implement a first draft > of a change to the bioconductor importer and updater. > > There are some limitations: > > - we cannot use the updater to go from “url-fetch” to

bug#39885: Bioconductor tarballs are not archived

Hi! Simon Tournier skribis: >> I was wondering whether we’re now doing better for Bioconductor >> tarballs. The answer, based on small sample, seems to be “not quite”: [...] > but, now the past reads, > > $ for url in >

bug#64653: ‘static-networking’ fails to start

Hi! Ludovic Courtès skribis: > Evaluating user expression (catch #t (lambda () (load "/gnu/store/64?")) # ?). > starting > '/gnu/store/gn8q7p790a9zdnlciyp1vlncpin366r0-hurd-v0.9.git20230216/hurd/pfinet > "--ipv6" "/servers/socket/26" "--i

bug#64653: ‘static-networking’ fails to start

Hello! Ludovic Courtès skribis: > [ 121.282538] shepherd[1]: Service user-homes started. > [ 121.368316] ipmi_si IPI0001:00: Using irq 10 > [ 121.405790] ipmi_si IPI0001:00: IPMI message handler: Found new BMC > (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20) > [ 121.419

bug#67988: [Cuirass] ‘request-work’ responses received by several workers

Hello, I’m under the impression that sometimes, when the server replies to ‘worker-request-work’ messages, its reply is received by more than just the target worker, leading to builds being performed twice: --8<---cut here---start->8--- ludo@berlin ~$ sudo

bug#39885: Bioconductor URI, fallback and time-machine

zimoun skribis: > $ guix time-machine --commit=77e2de365497bf4c8b81cbd78624f78293490485 \ >-- build r-biocneighbors -S [...] > Trying to use Disarchive to assemble > /gnu/store/zgf7x09kgiqbvj0dmhplxi1xzpljxd7k-BiocNeighbors_1.4.1.tar.gz... > could not find its Disarchive specification

bug#39885: Bioconductor tarballs are not archived

Hello! zimoun skribis: > Since 2020, I provided several examples of breakage with bug#39885 [1]. > Here another one: > > $ guix time-machine --commit=77e2de365497bf4c8b81cbd78624f78293490485 \ >-- build r-biocneighbors -S [...] > Starting download of >

bug#65419: [Shepherd] Non-responding service control fiber

Hello, Attila Lendvai skribis: > i think i have found the root cause of this, as documented here: > https://issues.guix.gnu.org/67839 > > that issue contains patches for shepherd to reproduce it in its test suite. Yes, it looks like this long-standing and hard-to-debug issue may well be fixed

bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.

Hello, Ludovic Courtès skribis: > Fixes <https://issues.guix.gnu.org/30948>. > > * guix/build/gnu-build-system.scm (separate-from-pid1): New procedure. > (%standard-phases): Add it. > * guix/build-system/gnu.scm (gnu-build): Add #:separate-from-pid1? and > hono

bug#30948: [PATCH core-updates] guix: Reap finished child processes in build containers.

Hey Maxim, Maxim Cournoyer skribis: > I haven't yet looked at the code, but looking at the bigger picture, > wouldn't it be a useful behavior to have for Guile itself? Perhaps not, > as there already exists a Guile init manager (GNU Shepherd), but if it's > something relatively simple/compact

bug#67802: Shepherd is not able to run simple networked programs as services

Hi, Lars Rustand skribis: > So, I figured this out. It had nothing to do with networking even though > it looked like it. The problem was that I had cargo cult-copied a > #:pid-file parameter from another service, believing that this was just > a path were Shepherd could create a pid-file for

bug#67839: shepherd: sometimes hangs on `guix system reconfigure`

Hi Attila, Attila Lendvai skribis: > * modules/shepherd.scm (main): Switch with-service-registry and > with-process-monitor. This way the parameterize of the process monitor covers > everything else. This fixes the bug that caused `guix system reconfigure` to > hang in certain situations.

bug#30948: [PATCH core-updates] build-system/gnu: Turn PID 1 into an “init”-style process by default.

Fixes . * guix/build/gnu-build-system.scm (separate-from-pid1): New procedure. (%standard-phases): Add it. * guix/build-system/gnu.scm (gnu-build): Add #:separate-from-pid1? and honor it. (gnu-cross-build): Likewise. Reported-by: Carlo Zancanaro Change-Id:

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

Hi, Nils Landt skribis: >> Ludovic Courtès hat am 06.12.2023 23:58 CET geschrieben: >> >> >> Hi, >> >> Nils Landt skribis: >> >> > I use guix home for almost everything, but I have installed glibc-locales >> > in my "

bug#67532: “make check” requires network

Hi, Simon Tournier skribis: > Running ’make check’ without network leads to errors, for instance. [...] > $ cat tests/derivations.log > substitute: guix substitute: warning: ACL for archive imports seems to be > uninitialized, substitutes may be unavailable > substitute: guix substitute:

bug#67044: [bug#67686] bug#67044: C.utf8 locale cannot be built

Hi Tomas, Tomas Volf <~@wolfsden.cz> skribis: >> (glibc-2.35)[arguments]: Delete ‘install-utf8-c-locale’ phase. > > I do think 2.35 should install the locale as well. That would require to > change > > (invoke (string-append bin "/localedef") > "--no-archive" "--prefix" locale

bug#67714: “guix build racket” different from “guix shell racket”

Hi, Simon Tournier skribis: > Using Guix aabfddb (Oct 2023), > > $ guix build racket-minimal --no-grafts -d > /gnu/store/hcdvhp36c51f6854mzggacsylkks24jj-racket-minimal-8.10.drv > > $ guix shell racket-minimal --no-grafts --dry-run > substitute: updating substitutes from

bug#67708: ‘guix system reconfigure’ crashes upon host name resolution failure

On a system where DNS resolution is failing, I get: --8<---cut here---start->8--- ~# guix system reconfigure /etc/config.scm Backtrace: In ice-9/boot-9.scm: 1752:10 19 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 661:37 18 (thunk)

bug#67707: Fresh installation leaks details about ISO build environment

On a fresh installation of 1.4.0, we get: --8<---cut here---start->8--- # guix system describe Génération 108 déc. 2023 10:39:47 (actuelle) nom de fichier : /var/guix/profiles/system-1-link nom de fichier canonique :

bug#67044: C.utf8 locale cannot be built

Hello! Tomas Volf <~@wolfsden.cz> skribis: > On 2023-11-27 23:02:26 +0100, Ludovic Courtès wrote: [...] >> Now, it would also be nice if C.utf8 were built-in, shipped with the >> ‘glibc’ package we have (to me that’s the whole point of C.utf8). We >> should fi

bug#67685: ‘guix shell --export-manifest’ ignores transformations for ‘-D’ packages

Hello! ‘--export-manifest’ does not apply transformations to packages preceded by ‘-D’ (development environment): --8<---cut here---start->8--- $ guix shell -D guile-git --with-branch=libgit2=main --export-manifest ;; What follows is a "manifest" equivalent to

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

Hi, Nils Landt skribis: > I use guix home for almost everything, but I have installed glibc-locales in > my "regular" guix (just by running guix package install glibc-locales). > Now, running guix package --upgrade fails with: > guix package: error: package glibc-locales@2.37 does not support

bug#67575: guix-daemon assertion failure upon substitution failure

Ludovic Courtès skribis: > 2023-11-27 07:00:58 accepted connection from pid 14007, user root > 2023-11-27 07:01:20 guix-daemon: nix/libstore/build.cc:3322: void > nix::Worker::childTerminated(pid_t, bool): Assertion `i != children.end()' > failed. > > > The correspo

bug#66537: [bug#67366] [PATCH] doc: Recommend building in ‘guix shell -CPW’.

Ludovic Courtès skribis: > This was prompted by <https://issues.guix.gnu.org/66537>, where someone > tried to build Guix within ‘guix shell --pure’ on a foreign distro and > found that ./configure would pick software from the host system. > > Suggested by Hiep Pham . > &

bug#67629: [Cuirass] ‘remote-server’ wrecks havoc when misbehaving clients connect

The ‘cuirass remote-server’ process goes awry when misbehaved clients connect; specifically, some of its fibers crash, leaving it running but inactive: --8<---cut here---start->8--- 2023-12-04 10:13:14 periodic update: 0 resumable, 0 failed builds 2023-12-04

bug#67575: guix-daemon assertion failure upon substitution failure

On a build machine running ‘cuirass remote-server’ with /gnu/store/5g4c9kii8l50lw23s7yb2a4bvc7qzw5d-guix-1.4.0-10.4dfdd82/bin/guix-daemon (from Guix commit 2ab5e449246f98b049888dde3c310f5b4a0a64a2), I see these ‘cuirass remote-worker’ errors: --8<---cut

bug#64665: [Shepherd] Introduce a configurable respawn delay

Hi, Attila Lendvai skribis: > damn, i already had this in the queue for sending: > > https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=1d3643f2576aff1869bba084c92684c81689a0a1 D’oh, sorry about that. > to help synchronize our efforts, here are the commits i'm working on, and >

bug#67502: [Cuirass] ‘cuirass remote-worker’ gets the CPU count wrong on the OverDrive

Ludovic Courtès skribis: > ludo@dover ~$ sudo herd status cuirass-remote-worker > Status of cuirass-remote-worker: > It is started. > Running value is 21279. > It is enabled. > Provides (cuirass-remote-worker). > Requires (avahi-daemon guix-daemon networking).

bug#67502: [Cuirass] ‘cuirass remote-worker’ gets the CPU count wrong on the OverDrive

On the OverDrive (AArch64), ‘cuirass remote-worker’ (1.2.0-1.bdc1f9f) says: starting 2 workers (parallelism: 1 cores) for server at 10.0.0.1 Instead it should use two cores for each worker: --8<---cut here---start->8--- ludo@dover ~$ guile -c '(use-modules

bug#67044: C.utf8 locale cannot be built

Hi Tomas! Tomas Volf <~@wolfsden.cz> skribis: > when trying to build a system with C.utf8 locale, I end up with the following > error: > > building /gnu/store/v6jma6kmwywr509n4y0vypchnh4y5s3m-locale-2.35.drv... > building locale 'C.utf8'... > [error] LC_MONETARY: value for field

bug#67485: [Cuirass] Workers not waking up after server went away

Hello, The ‘cuirass remote-worker’ processes (1.2.0-1.bdc1f9f) didn’t wake up after ‘cuirass remote-server’ stopped responding earlier today, remaining stuck while waiting for a reply to their latest “request work” message: --8<---cut here---start->8--- Nov 27

bug#67109: ‘efi32-esp’ image support pulls in host-side code

Hi, Mathieu Othacehe skribis: >> guix system: error: #> initialize-efi32-partition root #:grub-targets #> (quote ("i386-efi" . "BOOTIA32.EFI")) gnu/system/image.scm:142:28 >> 7fef96f85390>:out> args)) gnu/system/image.scm:146:8 7fef96f85360>: >> invalid G-expression input > > Expressed that

bug#66739: Typo in manual, section "the hurd in a virtual machine"

Nathan Dehnel skribis: >The default configuration (see ‘hurd-vm-configuration’ below) spawns > a secure shell (SSH) server in your GNU/Hurd system, which QEMU (the > virtual machine emulator) redirects to port 10222 on the host. By > default, the service enables “offloading” such that the

bug#66472: Wrong ‘glibc-utf8-locales’ package used on GNU/Hurd

Hello! Janneke Nieuwenhuizen skribis: > Ludovic Courtès writes: [...] >> We could define ‘glibc-utf8-locales’ with ‘define/system-dependent’, as >> we’ve done in commencement.scm. However, I don’t think that’s feasible >> because then every place that does: >>

bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

Hi, Simon Tournier skribis: > On Mon, 13 Nov 2023 at 13:31, Loïc SIRVIN wrote: > >> It takes very long time when we install it with `yum install file.rpm` >> command. > > Using CentOS 7 in VirtualBox, I confirm that the same pack as [1] takes > a looong time with “yum install” – hum, after 10

bug#64665: [Shepherd] Introduce a configurable respawn delay

Hello, Ludovic Courtès skribis: > The conclusion of the thread at > <https://lists.gnu.org/archive/html/guix-devel/2023-07/msg5.html> > seems to be that we should introduce a configurable respawn delay > (systemd makes that 100ms). Imp

bug#63736: [Shepherd] Loss of SIGCHLD notifications

Ludovic Courtès skribis: > 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

  1   2   3   4   5   6   7   8   9   10   >