bug#47144: security patching of 'patch' package

Hi Maxim, Maxim Cournoyer skribis: > Ludovic Courtès writes: [...] >> Unless I’m mistaken, this will have practically no effect because Patch >> is a build-time-only dependency. >> >> My recommendation would be to not add a ‘replacement’ field at all. >> In

bug#63413: Stop and restart builds in cuirass

Hi Andreas, Andreas Enge skribis: > Stopping and starting builds in cuirass is not very comfortable. > > When working on core-updates, I stopped builds for some old evaluations > on aarch64, where our build power would not be enough, assuming that many > of the old builds were made obsolete by

bug#47144: [PATCH 3/3] gnu: patch: Graft to latest commit [security fixes].

Hi Maxim, Maxim Cournoyer skribis: > (define-public patch >(package > +(replacement patch/fixed) Unless I’m mistaken, this will have practically no effect because Patch is a build-time-only dependency. My recommendation would be to not add a ‘replacement’ field at all. Instead, you

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

Ludovic Courtès skribis: > 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: On closer inspection, the theory of the message being

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

Ludovic Courtès skribis: > 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: Seen again: --8<---cut here

bug#70062: issue with openldap managed users on HPC

Hi Davide, Sorry for the delay; it looks like your bug report fell through the cracks. Davide Corrado skribis: > hello, I installed guix in a HPC environment and everything works as expected > if I use guix as a local user. I got this issue when I try to run it as an > openldap/sssd-managed

bug#71226: ‘guix shell -C’ doesn’t work on Ubuntu 24.04

On Ubuntu 24.04, ‘guix shell -C’ has its child process (in a separate mount namespace) fail to mount a tmpfs: --8<---cut here---start->8--- 294642 clone(child_stack=NULL,

bug#71144: Interactive prompt opened upon shepherd config file error

Christopher Baines skribis: > That looks good to me, the "Arrange to spawn a REPL if something goes > wrong" comment needs removing/updating, but that's the only thing I > spotted. Cool. I updated the comment and pushed it as cca25a67693bb68a1884a081b415a43fad1e8641. Thanks! Ludo’.

bug#70932: FAIL tests/guix-shell.sh

Christopher Baines skribis: >> “make check TESTS=tests/guix-shell.sh” passes for me though with >> 9c3a8a380bcfebdb77af61532e7bfec523d7bde8. > > I can just about see what's happening on this line now, I'm still not > sure why the exit status means the test fails. > > I think I knew when I

bug#70932: FAIL tests/guix-shell.sh

Hi, Christopher Baines skribis: > ++ guile -c '(use-modules (guix utils)) > (display (%current-system))' > + this_system=x86_64-linux > ++ guile -c '(use-modules (guix utils)) > (display (if (string=? "riscv64-linux" (%current-system)) > "x86_64-linux" >

bug#70826: luks-device-mapping-with-options breaks bootloader

Hi, Tadhg McDonald-Jensen skribis: > using the `luks-device-mapping-with-options` mapped device type defined in > (gnu system mapped-devices) causes grub or other bootloaders to not > properly attempt to mount the encrypted drive. This is caused by the > commit 39a9404 which identifies luks

bug#70999: Meson-build system fails to install license files

Hi Dariqq, Dariqq skribis: > The install-license-files function has an argument for specifying > out-of-source builds and calling it with that set to #t seems to be > able to find license files in the source directory in my limited > testing. Yes, ‘meson-build-system’ should pass

bug#70243: The substitute authorization warning is displayed when it shouldn't be

Hi Leo, Leo Famulari skribis: > I just saw this on Debian: > > -- > $ guix shell -D guix -- ./pre-inst-env guix weather linux-libre > computing 1 package derivations for x86_64-linux... > looking for 1 store items on https://ci.guix.gnu.org... > guix weather: warning: substitutes from

bug#70349: Clang fails to communicate RUNPATH?

Hi Liliana, Liliana Marie Prikler skribis: > I've noticed a strange error when attempting to build my software > against clang-toolchain. I've attached a minimally breaking example, > but the gist of it is that RUNPATH validation fails as shown below. > > starting phase `validate-runpath' >

bug#71144: Interactive prompt opened upon shepherd config file error

Ludovic Courtès skribis: > I think we should change the above to log and gracefully handle failure > to load an individual service file. With the change below, every service except the offending one is loaded and started as expected: --8<---cut here---

bug#71138: packages.guix.gnu.org down: error 502

Ludovic Courtès skribis: > https://codeberg.org/luis-felipe/guix-packages-website/issues/6 Fixed! https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=bd086003361773ed1b8aba2287562c102f10347b Ludo’.

bug#71173: ‘static-networking’ service can remain in ‘starting’ state forever

The ‘static-networking’ service can remain in ‘starting’ state forever when it specifies a nonexistent NIC. This can be reproduced by running a system such as hydra/bayfront.scm (in maintenance.git) in ‘guix system vm’: shepherd will wait for ‘networking’ to start forever, preventing the machine

bug#71144: Interactive prompt opened upon shepherd config file error

Hello, One problem we noticed in the analysis of the boot problem of bayfront after the recent downtime¹ is that an interactive REPL would be opened after an unbound variable was found in the shepherd config file: --8<---cut here---start->8--- [ 13.098907]

bug#71139: herd unresponsive on new 1.4.0 install

Hi, Antero Mejr skribis: > On a new Guix 1.4.0 install, I logged in and ran `herd status` to check > if sshd was running. However, the command blocked indefinitely with no > output. When I cancelled that and tried to shut the machine down with > `halt`, it also blocked and did nothing. The

bug#71138: packages.guix.gnu.org down: error 502

Hi, Antero Mejr skribis: > When I try to access https://packages.guix.gnu.org/, nginx returns a 502 > Bad Gateway error. We weren’t able to restart the service following the recent downtime: https://lists.gnu.org/archive/html/info-guix/2024-05/msg0.html I’ve reported it here:

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

Liliana Marie Prikler skribis: > Am Freitag, dem 05.04.2024 um 09:53 +0800 schrieb Hilton Chain: [...] >>    0 (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/test") >> >> ERROR: In procedure rename-file: >> In procedure rename-file: Invalid cross-device link >> --8<---cut

bug#70897: Guix system hangs on boot with LUKS root partition

Hi, Kaelyn skribis: > I wanted to let you know that I have figured out what the failure is, > and it turned out to be a customization buried within some shared > operating-system configuration that I had forgotten about (and wasn't > finding because it was due to a missing import, and simply

bug#70877: guix-daemon fails to copy 4+GB file to store

BTW, the newly updated ‘guix’ package is 8% smaller, as a result of : --8<---cut here---start->8--- $ guix describe Generation 302 May 12 2024 23:29:11(current) guix 89cd778 repository URL:

bug#40316: nss not reproducible

Hi, Christina O'Donnell skribis: > On 06/05/2024 11:12, Ludovic Courtès wrote: [...] >> For sure I’d be happy if the test suite could run faster, but does >> upstream offer such an option? When you say “a single pass”, is that >> something upstream supports? > Yes, y

bug#70877: guix-daemon fails to copy 4+GB file to store

Ludovic Courtès skribis: > Pushed as 7757fdd491862fa5c33f1f894503346b89898a01. > > I’ll update the ‘guix’ package to make the fix available. Done in 58be9a79e2862d5fa9842d73f498ce2e5442b9ce. Ludo'.

bug#70877: guix-daemon fails to copy 4+GB file to store

Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Could you confirm that it works for you? > > I've applied this locally, started the new daemon, and used it to build > the 4+GB source code derivation of a big package that used to fail > before. It works

bug#70910: xdot has stopped working after update to 1.3

Hi Ada, (Cc: Artyom, who updated xdot in a47fe0fdc4b13c850da29c0e11ab63d2041534c1.) Ada Stevenson skribis: > I was trying to use `xdot` to view to output of `guix graph` (`guix > graph bash | xdot -`). However, it crashed instantly with the > following stack trace: > >> dot: No such file or

bug#70897: Guix system hangs on boot with LUKS root partition

Hi Kaelyn, Kaelyn skribis: > I recently updated my systems after finally finding > https://issues.guix.gnu.org/70051 and seeing the issue I was having with > booting with a non-root LUKS partition configured had been fixed. After > updating to a commit past these two: > > 49f82fca41

bug#70877: guix-daemon fails to copy 4+GB file to store

Hi, Thanks for the bug report and nice reproducer! Ricardo Wurmus skribis: > The guix-daemon's libutil/util.cc uses copy_file_range to copy a > downloaded file into the store. copy_file_range fails on files larger > than 4GB with an error like this: > > guix build: error: short write in

bug#40316: nss not reproducible

Hi, Christina O'Donnell skribis: > Tangentially, given how long nss takes to build, do you think that > it'd be worth shaving it down to a single test pass? Currently it runs > each test up to 3 times, which takes ~1h on my machine with no other > build running. Running only the standard pass

bug#70726: guix-bug report

Hi, PJ Reid skribis: > Authenticating channel 'guix', commits 9edb3f6 to d6a6e83 (29,432 new > commits)... This particular commit, d6a6e832e6e318eec0c4866fdde62ae47f29defa, would trigger the bug you experienced when using a relatively old version of guix-daemon:

bug#40316: nss not reproducible

Hi Christina, Nice work! Christina O'Donnell skribis: > I've got as far as making nss 3.98 reproducible, however updating it to 3.99 > results in 51 test failures. These are regressions, and worked correctly for > 3.98. I'm not entirely sure what the issue is, but I've run out of time to >

bug#70456: Request for merging "core-updates" branch

Hi Chris and all, Christopher Baines skribis: > I think keeping the Git commit history clean and representative is > really important, so to me at least this means core-updates can't be > merged to master in it's current form, even if the changes overall from > these 6351 commits are

bug#66866: Grafting breaks cross-compilation

Hi, dan skribis: > I spent some time digging into the rabbit hole. After changing > the lower function of the copy-build-system to look more like the > lower function of the gnu-build-system, I'm able to cross compile > alsa-lib without the --no-grafts flag. The changes I made are > like:

bug#70588: hash mismatch error and stop fallback

Hi, Simon Tournier skribis: > Other said, hash mismatch should be raised and obviously the content > must be discarded; then the hash mismatch should be considered as “not > found” so let try the next strategy for downloading the content. Agreed. I merged it with

bug#70659: Too many heap sections on guix pull

Hi, Peacememories skribis: > `guix pull` on a fresh install on WSL Ubuntu 24.04 fails with the > following log. > > The same happened to me when trying GUIX on NixOS 23.11 via the > `services.guix` option. > > ``` > > hint: Consider installing the `glibc-locales' package and defining >

bug#70164: [bug#70205] [PATCH] home: services: bash: Move default PS1 prompt to bashrc

Hi Richard, Richard Sent skribis: > Reported in . > > * home/services/shells.scm (add-bash-configuration): Move default PS1 prompt > from .bash_profile to .bashrc. > > Change-Id: Ic437458ee362cc4aa803a71c9962af866749f59a Sounds reasonable to me; thanks for

bug#70652: Download fallback fails to consider bordeaux.guix and to download nar

Hi! Minutes ago, after someone reported the issue on IRC, I got this: --8<---cut here---start->8--- $ guix build /gnu/store/cq4j0mkbni4arlw9b7d1d8jcllbdb3yf-linux-libre-5.10.35-gnu.tar.xz.drv --no-substitutes The following derivation will be built:

bug#69596: ‘guix publish’ memory leak

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

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]

  1   2   3   4   5   6   7   8   9   10   >