bug#21843: Generated grub.cfg does not support encrypted roots

On 01/05/16 23:07, Ludovic Courtès wrote: l...@gnu.org (Ludovic Courtès) skribis: Now, I haven’t tested this in reality and would appreciate help here. I’m in the process of implementing automated tests for the installation process. I've been looking at this bug, as I've got a new laptop wh

bug#25118: All ruby packages replaced by version 2.3.3

On master (8f35c0306192c4b62646f2aa02879c2a8c4f4a07), as ruby 2.3.1 is replaced by 2.3.3, and all ruby packages inherit from ruby 2.3.1, all versions of ruby end up being 2.3.3. For example: → guix environment --container --ad-hoc --pure -e "(begin (use-modules (gnu packages ruby)) ruby-2.1)" -- r

bug#25213: Character encoding issue causing broken symlinks for profile generation

The profile generation/union code generates broken symlinks. I've reproduced this on 2 different machines (both Debian running Guix). To reproduce, run: guix environment --pure --container --ad-hoc nss-certs findutils coreutils [env]# find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec hea

bug#25200: guix lint throws gnutls error

On 15/12/16 16:15, Ludovic Courtès wrote: > Hi Maxim! > > Maxim Cournoyer skribis: > >> I'm using an up-to-date Guix (running directly from the Git tree) and >> recently started getting the following gnutls errors when attempting to >> run "guix lint some-package". This happens for any package.

bug#25453: Inconsistent keyboard layout affecting encrypted root

I'm using a UK keyboard layout with a computer that I recently installed GuixSD on with a encrypted root parition. Immediately after installation when I attempted to boot in to the new system for the first time I had to enter the passphrase twice, and in doing this, first I had to use the keyboard

bug#27990: Offloading repeatedly prints a message of the form "process ... acquired build slot '/var/guix/offload/.../0"

Hey, I gave setting up offloading another go, I'm testing with 3 machines, two running GuixSD, and one Debian. I've tried setting up offloading from both GuixSD machines to the Debian machine, and from one GuixSD machine to the other. Running `guix offload test` works, and reports success. Howeve

bug#28144: info-dir ERROR: no code for module (guix build utils)

I've had the following issue a few times now, it seems that somehow, the info-dir builder can be incorrectly generated, without the usual module import stuff. The most recent time this occurred, I worked around this by finding the guix package in the store which I thought was being used at the tim

bug#28144: info-dir ERROR: no code for module (guix build utils)

On Tue, 22 Aug 2017 10:41:55 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Heya, > > Christopher Baines skribis: > > > I've had the following issue a few times now, it seems that somehow, > > the info-dir builder can be incorrectly generated, without the

bug#28144: info-dir ERROR: no code for module (guix build utils)

On Tue, 22 Aug 2017 12:41:26 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Christopher Baines skribis: > > > bin/guile",["--no-auto-compile","/gnu/store/9ywpf5jc12svv04gvbx96j5z1kpllwn4-info-dir-builder"] > > > > Something is indeed wron

bug#28265: guix system build fails

On Mon, 28 Aug 2017 21:52:32 +0300 Efraim Flashner wrote: > efraim@macbook42:~/workspace/guix$ time nice ./pre-inst-env guix > system build ~/lightweight-desktop.scm Backtrace: > 11 (primitive-load > "/home/efraim/workspace/guix/scripts/gu…") In guix/ui.scm: > 1331:12 10 (run-guix-com

bug#27990: Offloading is now working!

I tried again, and after one small change, things are now working! Firstly, I was getting messages like: process 1011 acquired build slot '/var/guix/offload/capella.local/0' ;;; [2017/08/31 18:16:40.455763, 0] private-key-from-file: [GSSH ERROR] The file does not exist or permission denied: "/roo

bug#28470: caff in the signing-party package can't find sendmail on GuixSD

When using caff from the signing-tools pacakge, it looks for sendmail in the wrong places [1]. It would be useful to find a way to make it work when installed. I have found a workaround, which is to specify PERL_MAILERS as sendmail:$(type -p sendmail), e.g.: PERL_MAILERS=sendmail:$(type -p se

bug#28470: caff in the signing-party package can't find sendmail on GuixSD

On Mon, 09 Oct 2017 23:37:49 +0200 Ricardo Wurmus wrote: > Hi Christopher, > > > When using caff from the signing-tools pacakge, it looks for > > sendmail in the wrong places [1]. It would be useful to find a way > > to make it work when installed. > > > > I have found a workaround, which is to

bug#28709: [PATCH 0/4] Content-addressed mirrors for VCS checkouts

On Tue, 17 Oct 2017 10:48:03 +0200 Ludovic Courtès wrote: > Hello, > > Here’s a ready-to-merge patch series. Once applied, nars > (aka. “substitutes”) are downloaded and extracted when a VCS checkout > fails. This will address cases such as the recent Guile-Git repository > renaming for people

bug#25073: Status: We have no build system for Go

I'm glad to say that there is now a build system for Go, guix-patches bug #28586 contains the details. signature.asc Description: PGP signature

bug#19144: Please provide a bootable ISO image

There is now support for generating an ISO image of the installer system, and I've successfully managed to use it to install GuixSD. I've marked this as pending, and it can probably be closed once there is a release of Guix/GuixSD which includes an ISO image installer. signature.asc Description:

bug#23201: GNOME lock screen hotkey doesn't work

Chris Marusich writes: > I'm using GuixSD v0.10.0 with GNOME. I'd like to be able to lock my > screen, but I can't seem to do so. > > My settings under GNOME settings > Keyboard > Shortcuts > System lists > the following hotkey: > > * Lock screen: Super+L > > However, when I press Super+L,

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

Hey, I think something may have broken recently with the guix publish service. I run this on a server with very basic configuration, just setting the host, but I noticed recently that there were problems using the service. The following example is guix failing to download something from that serve

bug#30184: guix publish issue: guix substitute: error: corrupt input while restoring

Ludovic Courtès writes: >> I think something may have broken recently with the guix publish >> service. I run this on a server with very basic configuration, just >> setting the host, but I noticed recently that there were problems using >> the service. The following example is guix failing to d

bug#31773: Duplicit fails to build: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

Duplicity fails to build, this might be because of the GPG version used, as it looks to me that GPG complains that the message is quite old. I'll ask on the Duplicity talk mailing list. test_remove_all_inc_of_but_n (testing.functional.test_cleanup.CleanupTest) ... ok ===

bug#31773: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

Hey, The Guix package for duplicity is failing to build, and I was wondering if there is a fix already? I've had a look on Launchpad, but didn't spot anything. Here is the error: == ERROR: test_sigchain_fileobj (testing.unit.tes

bug#31791: bootstrap phase attempts to run a directory

I've just noticed that the erlang package has started failing to build. It looks like the bootstrap phase is over eager, and attempts to run the bootstrap directory. I think I'll fix this by deleting the phase, when I get around to merging the changes in #31678, but this might be affecting other p

bug#33248: python-minimal compilation is breaking

Gábor Boskovits writes: > ezt írta (időpont: 2018. nov. 3., Szo 7:13): > >> I am watching this bug on Lenovo G50-30 (CPU 2.1 GHz, 2Gb Ram): >> >> # guix pull --substitute-urls=https://berlin.guixsd.org >> Updating channel 'guix' from Git repository at ' >> https://git.savannah.gnu.org/git/guix

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

is, as I think it would be good to track the issue. I've also written a system test that I believe reproduced the issue. From 7eee5685f95d0b6baeb97f5fdd947fe5223a61c9 Mon Sep 17 00:00:00 2001 From: Christopher Baines Date: Fri, 26 Oct 2018 18:48:32 +0100 Subject: [PATCH] WIP Btrf

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

Ludovic Courtès writes: > Hello, > > Christopher Baines skribis: > >> Unfortunately, it's not a proper solution, as it obviously breaks when >> you actually want to strip the mount point off so that grub can find the >> right files. > > Is there a way

bug#33638: ruby-sass-spec substitute hash mismatch (mirror.hydra.gnu.org)

substituting /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4... downloading from https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4... ruby-sass-spec-3.5.4 1.3MiB

bug#32548: Cuirass: Performance monitoring

Mathieu Othacehe writes: > Hello, > >> As discussed earlier today on IRC with Clément, we could add performance >> monitoring capabilities to Cuirass. Interesting metrics would be: >> >> • time of push to time of evaluation completion; >> >> • time of evaluation completion to time of build

bug#43334: Cuirass crashes

Mathieu Othacehe writes: > Hello, > > I've observed a few Cuirass crashes the past days. The log looks like: > > --8<---cut here---start->8--- > 2020-09-11T12:55:35 next evaluation in 300 seconds > GC Warning: Repeated allocation of very large block (appr. siz

bug#43850: cuirass: inconsistent SQL queries execution time.

Ludovic Courtès writes: > Hi, > > Mathieu Othacehe skribis: > >>> I have now copied the database to a tmpfs mounted directory to make sure >>> that those inconsistent duration are only caused by the I/O pressure on >>> berlin. >> >> This helps a lot. The Cuirass web service has been running smo

bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

I found this when trying to build guile3.0-gnutls: guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- build --no-grafts --check guile3.0-gnutls FAIL: status-request-revoked trying NORMAL:-VERS-ALL:+VERS-TLS1.2 received status request receiv

bug#44612: Read standard input in `guix repl'

Pierre Neidhardt writes: > Hey Tobias, > > Always good to have someone actually test the stuff :) > > Tobias Geerinckx-Rice writes: > >> So far this looks like an (SB)CL(-specific) bug, right? Does it >> happen anywhere else? I tried Guile[0]. > > Maybe there was a misunderstanding, it's not

bug#45621: guix refresh -l and deprecated-package issue

There seems to be some issues with guix refresh -l and/or deprecating packages. Take the following example, guile3.0-squee is used by the guix-data-service. guix refresh -l claims it's not though. → ./pre-inst-env guix refresh -l guile-squee No dependents other than itself: guile-squee@0-2.c1497a

bug#45663: Problem installing pidgin because it propagates gtk+@2

As reported by sss2 on IRC [1]. I can see this has changed recently, I don't know why [2]. guix package -i pidgin spice-gtk --no-substitutes The following package will be upgraded: spice-gtk (dependencies or package changed) The following package will be installed: pidgin 2.14.

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

Leo Famulari writes: > Recently, many people on the #guix IRC channel reported frequent > non-deterministic failures of any operation involving substitution, like > this: > > -- > $ ./pre-inst-env guix build --no-grafts poezio mpdris2 sonata beets-bandcamp > beets > substitute: > guix buil

bug#45909: rust@1.47.0, rust-1.48.0 and rust-1.49.0 broken

The recent llvm 11.0.0 -> 11.0.1 change seems to have broken rust on the master branch.

bug#45901: GNOME Fonts takes about 20 seconds to display fonts

after waiting for about 20 seconds. > + The fonts have no preview thumbnails (I heard Christopher Baines was > looking into this particular issue) Hey, I've just pushed the fix I worked on for thumbnails [1]. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8ccef41436a

bug#45901: GNOME Fonts takes about 20 seconds to display fonts

Luis Felipe writes: > On Saturday, January 16, 2021 11:18 AM, Christopher Baines > wrote: > >> Hey, >> >> I've just pushed the fix I worked on for thumbnails [1]. >> >> 1: >> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=540893a8cce

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

Mathieu Othacehe writes: > Hello Leo & Guillaume, > >> That's a good observation. I hadn't thought of it. >> >> I'm CC-ing Mathieu Othacehe and guix-sysadmin so that we can disable >> these builds until we can fix the bug for real. Mathieu: this might >> explain why the build farm is spending al

bug#46188: openimageio (and blender) fail to build since b965b2f004d522acea17f85780e1e44c882e24b3

Reported on IRC, it looks like the up date of pybind11 from 2.4.3 to 2.6.1 causes openimageio to fail to build, which also prevents users from installing/upgrading blender. 1: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=51418c32d95d8188d8877616829f26479f1135c6&ta

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

I noticed through the Guix Data Service that some narinfo files from ci.guix.gnu.org have an excessive NarSize. These are the three that I've found, but there could be more. /gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-flightgear-2018.3.5 NarSize: 18446744072099351584 /gnu/store/qhix6afvy2a6n7hl

bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

Christopher Baines writes: > I noticed through the Guix Data Service that some narinfo files from > ci.guix.gnu.org have an excessive NarSize. > > These are the three that I've found, but there could be more. > > > /gnu/store/qln574djfgl8h9glij9id8jips7nnrlw-fli

bug#44559:

Ludovic Courtès writes: > Perhaps we could start by testing this hypothesis on a separate build > farm. Chris, Mathieu, WDYT? I'm currently thinking about attempting these kind of things (testing building derivations under different conditions) through the agent tags in the Guix Build Coordina

bug#44559:

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Perhaps we could start by testing this hypothesis on a separate build >>> farm. Chris, Mathieu, WDYT? >> >> I'm currently thinking

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

Hey, When reconfiguring recently, I ran in to issues with the Guix Data Service and probably the Patchwork service too. Looking at the change, I think it's clear there's a problem, because some system tests were changed, and I'm guessing they were changed so that they passed [1]. 1: https://git

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

Mathieu Othacehe writes: >> One workaround, the one employed in the tests is to revert to the old >> behaviour for the PostgreSQL service by setting socket-directory to #f. > > You're right, sorry about the breakage. As you noticed we are in an > in-between situation where the patch updating Pos

bug#46829: Fresh install of 1.2.0 can't guix pull

I believe there's TLS issues with pulling for the current 1.2.0 release. root@horna ~# guix pull substitute: updating substitutes from 'https://guix.cbaines.net'... 100.0% 0.0 MB will be downloaded downloading from https://guix.cbaines.net/nar/lzip/zg72c146skpca45ijvjigqhqgx0mwiny-le-certs-0 ...

bug#46829: Fresh install of 1.2.0 can't guix pull

zimoun writes: > Hi Chris, > > On Sun, 28 Feb 2021 at 10:27, Christopher Baines wrote: >> I believe there's TLS issues with pulling for the current 1.2.0 >> release. > > Is this bug different from <http://issues.guix.gnu.org/issue/44559#8>? > >

bug#46942: ci.guix.gnu.org is slow from my system

raid5atemyhomework via Bug reports for GNU Guix writes: > Downloading substitutes from ci.guix.gnu.org is slow from my two Guix-using > computers. > > One is a pure Guix System install without any channels, the other one is a > foreign Guix install with the-channel-that-cannot-be-named. > > >

bug#46981: Severe Emacs shell mode performance regression in recent Linux-libre

Mark H Weaver writes: > Mark H Weaver writes: > >> FYI, for those who use Emacs shell mode (M-x shell), I wanted to give a >> heads-up about a severe performance regression in Linux-libre 5.10.20, >> and I suspect the same regression exists in 5.11.3. >> >> For details, see the bug report I sub

bug#47019: Rust 1.26.2 from the master branch fails to build on aarch64-linux

The failure seems to occur in the check phase, see the build logs referenced from: https://data.guix-patches.cbaines.net/gnu/store/c3f7d3ziwjfkwg3j7xz47dj44sb2l5av-rust-1.26.2.drv This looks like a relevant error: [compile-fail] compile-fail/issue-15919.rs stdout executing "

bug#47019: Rust 1.26.2 from the master branch fails to build on aarch64-linux

Efraim Flashner writes: > On Tue, Mar 09, 2021 at 08:56:54AM +0000, Christopher Baines wrote: >> The failure seems to occur in the check phase, see the build logs >> referenced from: >> >> https://data.guix-patches.cbaines.net/gnu/store/c3f7d3ziwjfkwg3j7xz47

bug#47157: “Bad Read-Header-Line header: #” while substituting

Ludovic Courtès writes: > As reported by a few people on IRC, ‘guix substitute’ sometimes fails in > a way that I just experienced (from > 8154beffd8c121e953a7c4cd75c3eebfcc073a9a): > > --8<---cut here---start->8--- > downloading from > https://ci.guix.gnu.or

bug#47157: “Bad Read-Header-Line header: #” while substituting

Christopher Baines writes: > Ludovic Courtès writes: > >> As reported by a few people on IRC, ‘guix substitute’ sometimes fails in >> a way that I just experienced (from >> 8154beffd8c121e953a7c4cd75c3eebfcc073a9a): >> >> --8<---cut

bug#47157: “Bad Read-Header-Line header: #” while substituting

Ludovic Courtès writes: > Christopher Baines skribis: > >>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits >>> may have caused this regression. In particular, in >>> 20c08a8a45d0f137ead7c05e720456b2aea44402, >>> ‘call-with-c

bug#47283: Performance regression in narinfo fetching

Ludovic Courtès writes: > As reported on guix-devel, ‘guix weather’ has become extremely slow. > Specifically, in the narinfo-fetching phase, it runs at 100% CPU, even > though that part should be network-bound (pipelined HTTP GETs). > > A profile of the ‘report-server-coverage’ call would show

bug#47283: Performance regression in narinfo fetching

Christopher Baines writes: > I haven't looked in to this yet, but maybe it would be possible to > adjust the code so that it doesn't perform so badly, but still tries to > handle possible exceptions. > > The two ideas I have is to rewrite the (let ...) bit in terms of a

bug#47283: Performance regression in narinfo fetching

Ludovic Courtès writes: > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Indeed, there’s one place on the hot path where we install exception >>> handlers: in ‘http-multiple-get’ (from commit >>> 205833b72c5517915a47a50dbe28e7024dc

bug#46829: Fresh install of 1.2.0 can't guix pull

Leo Famulari writes: > On Sun, Feb 28, 2021 at 10:27:02AM +0000, Christopher Baines wrote: >> I believe there's TLS issues with pulling for the current 1.2.0 release. > > On a fresh Debian ISO image, I installed Guix 1.2.0 based on the > instructions in the manual sect

bug#46829: Fresh install of 1.2.0 can't guix pull

Leo Famulari writes: > On Sat, Apr 10, 2021 at 04:30:42PM -0400, Leo Famulari wrote: >> Okay, I'm testing this now, in a VM. >> >> I wonder if it's the same thing as >> ? > > I followed the instructions in the manual section In

bug#46737: Services breakage from the PostgreSQL socket-directory configuration change

Christopher Baines writes: > Mathieu Othacehe writes: > >>> One workaround, the one employed in the tests is to revert to the old >>> behaviour for the PostgreSQL service by setting socket-directory to #f. >> >> You're right, sorry about the breakage.

bug#47971: Improve Guix commands for update/upgrade

bo0od writes: > Hi There, > > The current commands used to make sure everything updated are not > friendly to type nor to memorize, Current commands:(i dunno if i > missed more) > > guix pull > guix upgrade > sudo guix reconfigure /etc/config.scm > > > There is no relation can be drawn from usin

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

This is on commit 1b792e8b5275dc010c53d91062082340431204f2. → make check-system TESTS=basic Compiling Scheme modules... Selected 1 system tests... The following derivation will be built: /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-basic.drv building /gnu/store/7dyw16iakczr7qg89rb3rgbh443cvwpc-

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> This is on commit 1b792e8b5275dc010c53d91062082340431204f2. >> >> → make check-system TESTS=basic >> Compiling Scheme modules... >> Selected 1 system tests... >> The foll

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

Ludovic Courtès writes: > Hi, > > Ludovic Courtès skribis: > >> Christopher Baines skribis: >> >>> Following up on this, I've built Guile on core-updates with libgc@7 >>> rather than libgc@8 (which is what's used above), and I can't r

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

Tobias Geerinckx-Rice writes: > Chris, > > Christopher Baines 写道： >> This comes from guix.cbaines.net, so it's probably not affecting >> anyone >> else. > > The spooky happenings below reminded of this thread. Perhaps they're > useful somehow.

bug#33638: ruby-sass-spec substitute hash mismatch (mirror.hydra.gnu.org)

Leo Famulari writes: > On Wed, Dec 05, 2018 at 10:05:57PM +0000, Christopher Baines wrote: >> >> substituting >> /gnu/store/mnvng3pdri5v8497j5a6nij53z3knlk1-ruby-sass-spec-3.5.4... >> downloading from >> https://mirror.hydra.gnu.org/guix/nar/gzip/mnvng3pdr

bug#33932: [PATCH] gnu: artanis: Move to web.scm and update to 0.3.1. (was: Re: bug#33932: Artanis fails to build - 0.3.1 is out)

swedebugia writes: > On 2019-01-02 22:50, swedebugia wrote: >> On 2018-12-31 13:33, Ricardo Wurmus wrote: >>> >>> Hi swedebugia, >>> We should upgrade. >>> >>> Could you please send a patch? >>> >> >> Here it is :) I haven't looked too closely at the patch, but I think the newer version of

bug#34124: gnome-shell crash when opening the activities overview

On one system running GuixSD, Gnome Shell crashes when opening the activities overview (super key, or clicking on the activities button in the top left). (.gnome-shell-real:2471): GLib-GIO-CRITICAL **: 10:36:30.639: g_file_new_for_path: assertion 'path != NULL' failed (.gnome-shell-real:2471):

bug#31773: Duplicit fails to build: ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)

I ended up pushing a patch [1] for this as part of [2]. This has now been released by upstream, so the change doesn't exist in the Guix codebase any longer (the package was updated in [3]). 1: e61f092c877da5a9dc5dcdd82690bd3c191769e1 https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e61f092c87

bug#33470: [bug#34249] [PATCH] guix package: Avoid spinner at end of output.

Ludovic Courtès writes: > Danny Milosavljevic skribis: > >> Hi Christopher, >>> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm >>> index a633d2ee6d..4db0e72e9b 100644 >>> --- a/guix/scripts/package.scm >>> +++ b/guix/scripts/package.scm >>> @@ -159,6 +159,7 @@ hooks\" run when

bug#34567: Bogus 'upower-service' deprecation message

Mark H Weaver writes: > My OS config includes a reference to 'upower-service', which is now > deprecated, but the deprecation message is bogus: > > mhw@jojen ~$ guix system build /etc/config.scm --verbosity=1 > /etc/config.scm:149:19: warning: 'slim-service' is deprecated, use > 'slim-servi

bug#25453: Inconsistent keyboard layout affecting encrypted root

Ludovic Courtès writes: > Hi Chris! > > l...@gnu.org (Ludovic Courtès) skribis: > >> Christopher Baines skribis: >> >>> I'm using a UK keyboard layout with a computer that I recently installed >>> GuixSD on with a encrypted root parition. Immedia

bug#35243: ungoogled-chromium build stops and freezes the system

zna...@disroot.org writes: > My bug report is this https://github.com/Eloston/ungoogled-chromium/issues/730 > > During update with `guix pull && guix package -u` ungoogled-chromium build > process stops on build derivation on 84% three times in a row. What does your system memory and swap look

bug#35387: unpack phase in the gnu-build-system is sometimes non-deterministic

I believe that the direnv package has encountered an issue with the gnu-build-system [1]. 1: https://issues.guix.info/issue/35386 Due to the combination of the 'setup-go-environment phase from the go-build-system, and the 'unpack phase of the gnu-build-system, there are two directories to be cons

bug#34124: gnome-shell crash when opening the activities overview

Ricardo Wurmus writes: > Christopher Baines writes: > >> On one system running GuixSD, Gnome Shell crashes when opening the >> activities overview (super key, or clicking on the activities button in >> the top left). >> >> >> (.gnome-shell-real

bug#34124: gnome-shell crash when opening the activities overview

Ben Sturmfels writes: > On Tue, 2019-04-23 at 21:33 +0100, Christopher Baines wrote: >> Ricardo Wurmus writes: >> >> > Christopher Baines writes: >> > >> > > On one system running GuixSD, Gnome Shell crashes when opening >> > > the

bug#35387: unpack phase in the gnu-build-system is sometimes non-deterministic

Ludovic Courtès writes: > Hi Chris, > > Christopher Baines skribis: > >> I believe that the direnv package has encountered an issue with the >> gnu-build-system [1]. >> >> 1: https://issues.guix.info/issue/35386 >> >> Due to the combination o

bug#36634: Virtual Machine Manager (virt-manager)

Raghav Gururajan writes: > libvirt.libvirtError: Unable to read from > '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or > directory So, I've experienced this too. Even though this is a cgroup thing, I'm pretty sure this isn't an issue with Linux. I've tried reverting the ch

bug#36634: Virtual Machine Manager (virt-manager)

As version 5.7.0 has been released, I tried updating to that. There seems to be some issue with the configuration for the socket file, but even avoiding that, it doesn't seem to resolve the issue with the cgroups. For now, I've switched more permanently back to 5.4.0. signature.asc Description:

bug#37348: Force https redirect missing from ci, workflow and workflows guix.info sub-domains

Collin J. Doering writes: > Not sure where the best place to report this, however today I noticed > that ci.guix.info, workflow.guix.info and workflows.guix.info do not > redirect http to https, though its also served over https. I'm unsure if this is intentional, or something to change. There

bug#37388: can lead to syntactically invalid configs

Ludovic Courtès writes: > It’s nice that we have but I noticed that, unlike > most or all other configuration records that we have, it’s possible to > create an record that leads to a syntactically > invalid nginx config file. > > For example, if you have a location block like this: > >

bug#37388: can lead to syntactically invalid configs

Ludovic Courtès writes: >> I wonder if some errors could be caught at build time, before attempting >> to start the service. >> >> If in the derivation to build the configuration file, nginx is run >> against the built config file with -t, that might spot errors at >> derivation build time. > >

bug#37804: getmail service documentation error?

pelzflorian (Florian Pelz) writes: > The documentation of the getmail service’s delete_after setting is > confusing and appears to contradict upstream documentation at > . > > I am not sure, but the code in the getmail file in the getmail so

bug#37822: guile-fibers build failure

The guile-fibers package seems to fail to build on some machines. starting phase `check' make check-am make[1]: Entering directory '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0' make check-TESTS make[2]: Entering directory '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0' assert

bug#37822: guile-fibers build failure

Christopher Baines writes: > The guile-fibers package seems to fail to build on some machines. > > starting phase `check' > make check-am > make[1]: Entering directory > '/tmp/guix-build-guile-fibers-1.0.0.drv-0/fibers-1.0.0' > make check-TESTS > ma

bug#37846: @acronym not handled correctly in synopsis or descriptions

When rendering synopsis or descriptions as plain text, acronyms are not handled correctly, they're just omitted entirely. Flexible objects for representing @acronym{UFO, unified font object} data -> Flexible objects for representing data @acronym{FIFE, Flexible Isometric Free Engine}

bug#37822: guile-fibers build failure

Ludovic Courtès writes: > Christopher Baines skribis: > >> I've now tried running the tests using Guix immediately prior to the >> recent core-updates merge (d57660c54907cc6fba8b0adf6295fd2311ada6cf), >> and immediately after the merge >> (cf3d1763ede1a3

bug#38167: guix pull takes over 8 GiB of memory to finish if there are no substitutes

Danny Milosavljevic writes: > Hi, > > guix pull takes over 8 GiB of memory to finish if there are no substitutes. > > My laptop only takes max 8 GiB of RAM. I've set up swap, but that kind of > memory usage still seems ridiculous. Do you know if the derivations got built in parallel? So, does

bug#54407: Issues building grub for powerpc64le, could not force big-endian

Maxime Devos writes: > Christopher Baines schreef op di 15-03-2022 om 21:11 [+]: >> grub can't be built for powerpc64le, I believe the same failure >> occurs >> with native builds or cross compilation from x86_64. I think this >> might >> have always

bug#55066: guix pull: error: You found a bug: the program '/gnu/store/mpfp9nrzifhp3r5s3bv05b8xal5aa44f-compute-guix-derivation'

calcium via Bug reports for GNU Guix writes: > 14.2 MB will be downloaded: > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 > /gnu/store/4jdghmc65q7i7ib89zmvq66l0ghf7jc4-glibc-2.33-static > /gnu/store/jwwvdgb3bgvbvbrd7k7zx2ircxhhrvd8-git-minimal-2.35.1 > substituting /gnu/store/jww

bug#55335: openssh-service no longer listens on IPv6

This looks to be a recent regression, probably connected with the shepherd now doing the listening, rather than sshd itself. Previously, you could use both IPv4 and IPv6. netstat -tlnp | grep sshd tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 26683/sshd: /gn

bug#55335: openssh-service no longer listens on IPv6

Christopher Baines writes: > This looks to be a recent regression, probably connected with the > shepherd now doing the listening, rather than sshd itself. > > Previously, you could use both IPv4 and IPv6. > > netstat -tlnp | grep sshd > tcp0 0 0.0.0.0:22

bug#55335: [PATCH] services: Allow shepherd to listen for IPv6 connections to openssh.

Prior to the switch to the openssh service using inetd, you could connect over IPv4 or IPv6. With inetd, you can only connect over IPv4, meaning for machines with just IPv6 connectivity, you can't connect. Switching to listing via IPv6 should support IPv4 connections, as Linux is capable of transl

bug#55335: openssh-service no longer listens on IPv6

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> Switching to listing via IPv6 should support IPv4 connections, as Linux is >> capable of translating IPv4 connections to IPv6. I think there's a risk that >> switching to this approach w

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

Ludovic Courtès writes: > For now, I’m going to go with the solution below, which is to use an > older revision of Guix (one where ‘open-inferior’ was using > ‘open-pipe*’) as the dependency of the ‘cuirass’ package. > > I’m running “cuirass evaluate” manually on berlin to make sure it > actuall

bug#56353: sbcl-2.2.6 build fail

Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > On 2 July 2022 09:29:22 UTC, Wensheng Xie wrote: >>Das Erstellungsprotokoll kann unter >>„/var/log/guix/drvs/6l/q7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv.bz2“ >>eingesehen werden. > > > This log file is always a good idea to inc

bug#56353: sbcl-2.2.6 build fail

Guillaume Le Vaillant writes: > [[PGP Signed Part:Undecided]] > Christopher Baines skribis: > >> Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: >> >>> On 2 July 2022 09:29:22 UTC, Wensheng Xie wrote: >>>>Das Erstellungsprotok

bug#57215: ci: Fail to evaluate Guix specification

Mathieu Othacehe writes: > Now there are multiple unclear points to me: > > 1. Why do we need an available machine with the foreign architecture to > compute the corresponding "guix" derivation? Note that the evaluation of > package derivations for foreign systems works even though a > correspon

bug#57215: ci: Fail to evaluate Guix specification

Mathieu Othacehe writes: > Hey, > >> So, I think there's some involvement of grafts that mean you end up >> building things when just trying to compute the derivation. But that's >> as far as I got, I don't really understand why this is the case, or what >> can be done about it. > > Thanks for s

bug#57596: guix lint --checkers=derivation doesn't complete, Too many heap sections

When running the derivation checker on all packages for recent guix revisions, it dones't seem to complete. Instead, you get an error which I think comes from the garbage collection implementation that Guile uses: → guix lint --checkers=derivation Too many heap sections: Increase MAXHINCR or M

  1   2   3   >