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. Since I've scanned all the narinfos for a recent revision, I thought I'd update this issue with the broken narinfos that ci.guix.gnu.org is cur

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. Probably

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 reproduce &

bug#48468: substitute server connection timeout

Mathieu Othacehe writes: > Hello, > > We recently have a lot of those errors on Cuirass: > > --8<---cut here---start->8--- > guix substitute: warning: while fetching >

bug#48473: Long stack plus exception may cause inferior/client to hang

This seems to have been the cause of the Guix Data Service getting stuck when the profile-collisions linter crashed, from strace, the inferior process wrote this [1]. But then both the inferior and the client process just sit there doing nothing. I've worked around this by switching map to

bug#49088: grub-hybrid fails to build on aarch64-linux: error: --enable-stack-protector is not supported

Christopher Baines writes: > This is the relevant derivation [1], this change was probably introduced > here [2]. > > 1: /gnu/store/vmpn3xk6mzns9zvq7dvlpj67ld3fv48p-grub-hybrid-2.06.drv > 2: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=018f95094153660e3041ec

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

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

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#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 >>> 205833b72c5517915a47a50d

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#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 fold, >

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 >

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-w

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#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

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

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 abou

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:

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>? > > And

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#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

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

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 section B

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. As yo

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

bug#50353: Excessive temproots size when running guix build

I spotted a problem with data.guix.gnu.org trying to process this old revision [1] 1: https://data.guix.gnu.org/revision/75dabac633bb9a33efbebf859f8aa4bb3b9582b2 The machine ran out of disk space, as a ~30GiB file had been created in /var/guix/temproots. I think I can reproduce the situation by

bug#52103: guix pull: guix-manual.drv' failed with exit code 1, In procedure copy-file: Permission denied

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> Ludovic Courtès writes: > > [...] > >>> Ah yes, that looks like a problem: “doc”, which is taken straight from >>> the checkout, normally does not contain *.LANG.texi; thos

bug#51787: GC takes more than 9 hours on berlin

Ludovic Courtès writes: > • When discussing together with Chris Baines yesterday on IRC, we > found that the sqlite WAL file was 8 GiB. I later ran: > > PRAGMA wal_checkpoint(TRUNCATE); > > which emptied it immediately. However, GC time wasn’t particularly > different

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

Ludovic Courtès writes: > Hi, > > Ludovic Courtès skribis: > >> This is what I get for the last one: >> >> sqlite> select * from validpaths where path = >> '/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5'; >>

bug#52103: guix pull: guix-manual.drv' failed with exit code 1, In procedure copy-file: Permission denied

Hey, I'm having trouble pulling on a aarch64-linux machine, both from master and core-updates-frozen, and they fail with similar output. I'm having trouble debugging this, as the Guile exception is missing some information, and make as-derivation from a checkout works. Chris cbaines@hatysa

bug#52452: Guix related downloads from ftp.gnu.org are slow over IPv6

900 times slower by my measurements. I noticed this when downloading the release .tar.xz: → wget -4 https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz --2021-12-12 14:07:29-- https://ftp.gnu.org/gnu/guix/guix-binary-1.3.0.x86_64-linux.tar.xz Resolving ftp.gnu.org

bug#52103: guix pull: guix-manual.drv' failed with exit code 1, In procedure copy-file: Permission denied

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> I've had a go at debugging this further, I'm not confident I've found >> the relevant part of the strace output, but I think it could be this bit: >> >> 14403 newfstatat(AT_FDCWD, >> &q

bug#52103: guix pull: guix-manual.drv' failed with exit code 1, In procedure copy-file: Permission denied

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> I'm having trouble pulling on a aarch64-linux machine, both from master >> and core-updates-frozen, and they fail with similar output. > > FWIW I’ve successfully upgraded on aarch64-linux

bug#53903: aarch64: failed to compute the derivation for Guix

Ricardo Wurmus writes: > View build log at > '/var/log/guix/drvs/2j/5348zpz32qmb7x4v5ipg26d269hgxf-coreutils-8.32.drv.bz2'. Would you be able to share this log, or at least the last bit of it? >>> >>> There’s one failing test: >>> >>> ==> foo <== >>> + fail=1 >>> + break >>>

bug#54370: network problem or intentional blocking?

Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > I didn't address guix.gnu.org beyond ci.guix.gnu.org. > > Everyone: should we ask SJTUG to mirror the Web site as well? > > I'm generally weary of that. I believe bayfront was being setup to serve the website (see [1]), but I'm not

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

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 been the case. This is the error from the build log: checking for options to get big-endian compilation... no configure: error: could not

bug#54055: texlive-bin fails to build on armhf-linux, breaking guix pull

Something I've noticed from data.guix.gnu.org, it fails to compute the guix derivation for armhf-linux because texlive-bin fails to build [1] 1: https://data.guix.gnu.org/job/28674 phase `check' failed after 820.9 seconds command "make" "check" "-j" "8" failed with status 2 builder for

bug#54055: texlive-bin fails to build on armhf-linux, breaking guix pull

Christopher Baines writes: > Something I've noticed from data.guix.gnu.org, it fails to compute the > guix derivation for armhf-linux because texlive-bin fails to build [1] > > 1: https://data.guix.gnu.org/job/28674 > phase `check' failed after 820.9 seconds > command &quo

bug#54056: guix-data-service build failure, segfault probably related to guile@3.0.8

The recent derivation for the guix-data-service built with Guile 3.0.8 seems to often segfault when running the tests (see the failed builds here [1]). 1: https://data.guix.gnu.org/gnu/store/qzxq38kpd2vrpj1xwgd5i3gjdkmmxmn1-guix-data-service-0.0.1-29.4a1088c.drv With some help from IRC, I

bug#54056: guix-data-service build failure, segfault probably related to guile@3.0.8

Ludovic Courtès writes: > The real cause of the error though seems to be a ‘match-error’ in > application code: > >> #17 0x77f3bc8d in scm_throw (key=match-error, args=("match" "no >> matching pattern" x86_64-linux)) at throw.c:262 >> #18 0x77edb239 in throw_ (key=, args=) >>

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 been

bug#53415: binutils-mesboot1-2.14 configure phase fails, In procedure stat: No such file or directory: "config.status"

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> I've seen this failure consistently on one of the machines behind >> bordeaux.guix.gnu.org, you can see the full logs via following the "View >> build" links here [1]. >>

bug#53903: aarch64: failed to compute the derivation for Guix

Ricardo Wurmus writes: > \ 'check' phaseBacktrace: > 13 (primitive-load > "/gnu/store/l7rhvfaziri0znvs3jc6khrkxaq9shna-compute-guix-derivation") > \ 'check' phaseIn ice-9/eval.scm: > 155:9 12 (_ _) > 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) > ?) ?) ?) ?) ?) ?) ?)

bug#53903: aarch64: failed to compute the derivation for Guix

Ricardo Wurmus writes: > Christopher Baines writes: > >> [[PGP Signed Part:Undecided]] >> >> Ricardo Wurmus writes: >> >>> \ 'check' phaseBacktrace: >>> 13 (primitive-load >>> "/gnu/store/l7rhvfaziri0znvs3jc6khrk

bug#53416: mesboot derivations, build phase errors, No targets specified and no makefile found

I'm looking at the failed builds for the following derivations: http://data.guix.gnu.org/gnu/store/2ygj1zfybdnb1v40ik46l37inj6jjkwr-make-mesboot-3.82.drv http://data.guix.gnu.org/gnu/store/4azilx11f0mg8kyh761yqgrrzlhh6ddh-grep-mesboot-2.0.drv

bug#53415: binutils-mesboot1-2.14 configure phase fails, In procedure stat: No such file or directory: "config.status"

I've seen this failure consistently on one of the machines behind bordeaux.guix.gnu.org, you can see the full logs via following the "View build" links here [1]. 1: http://data.guix.gnu.org/gnu/store/xd8rnmr0k3fhfhilzi66hnggsnx67d5i-binutils-mesboot1-2.14.drv I've tried building multiple times

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

Christopher Baines writes: > Christopher Baines writes: > >> Christopher Baines writes: >> >>> I'm seeing this in the build coordinator agent, but it can be reproduced >>> by tweaking the guix build script as below. The build coordinator uses >>>

bug#63445: guix-build-coordinator guile-gnutls segfault

Christopher Baines writes: > Ludovic Courtès writes: > >> Hi, >> >> Christopher Baines skribis: >> >>> I've seen the build coordinator on bayfront crash a couple of times, and >>> it seems to be segfaulting, maybe in gnutls? >>&g

bug#39310: MariaDB reproducibility issue

Ludovic Courtès writes: > Hi! > > Marius Bakke skribis: > >> Josh writes: >> >>> Hi Guix, >>> >>> I ran into this issue when building mariadb 10.1.38. I've attached the >>> last 300 lines of the log. Thanks >> >> I can reproduce this failure by checking out Guix 1.0.1 in a "time >> machine"

bug#22304: Julia

Just checking this, looks like 1.8.3 is still not reproducible, just one file differs though: → guix challenge --diff=simple julia /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3 contents differ: no local build for '/gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3'

bug#63414: Evaluation comparison on cuirass

Ludovic Courtès writes: > Hello, > > Andreas Enge skribis: > >> When working on a branch and deciding whether to merge it, we need a way >> of comparing its status with that of the master branch. As far as I can see, >> there is currently no way in cuirass to compare arbitrary evaluations and

bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary.

Ludovic Courtès writes: > Fixes . > > This fixes a bug whereby libgit2-managed checkouts would keep growing as > we fetch. > > * guix/git.scm (packs-in-git-repository, maybe-run-git-gc): New > procedures. > (update-cached-checkout): Use it. > --- >

bug#65858: mumi crashes

Maxim Cournoyer writes: > Hi, > > Maxim Cournoyer writes: > >> Hi Arun, >> >> Arun Isaac writes: >> >>> Hi Maxim, >>> >>> I have made a number of changes to mumi and reconfigured berlin with the >>> latest mumi. Here is a quick summary of the main changes to mumi. >>> >>> - We now log the

bug#65858: mumi crashes

Maxim Cournoyer writes: > Hi Christopher, > > Christopher Baines writes: > > [...] > >>> Here's a fresh crash (on berlin): >>> >>> 2023-10-24 06:22:58 GET >>> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065806%29%20%7B%0A%20%20%2

bug#65434: https://data.guix.gnu.org/statistics is bogus

Maxime Devos writes: > That page contains: > > Guix revisions > # > Derivations > # > > I think some code forgot to actually call these procedures. Haha, that's a werid issue. I haven't looked at that page for a long while as I don't think it was performing well when you have any more than a

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

bug#66997: nar-herder uses 10 GiB of resident memory, 100% CPU on hydra-guix-129

Maxim Cournoyer writes: > I was looking at top on the hydra-guix-129 node, which runs nar-herder, > and saw this: > > 4772 nar-her+ 20 0 28.9g 11.5g 100.0 6.1 55,55 S .nar-herder-rea > > 11.5 GiB of memory seems a bit excessive, no? Its cumulated processing > time is also at the

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 will a

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 >

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

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#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#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

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:

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

Christopher Baines writes: > 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 --c

bug#58770: guix pull: error: You found a bug: the program '/gnu/store/9kyha1l1a1ynh9nni8428bqdanajck1b-compute-guix-derivation'

Mark Felt writes: > building /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv... > | 'build' phasebuilder for > `/gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv' failed with > exit code 1 > build of /gnu/store/5s1lrwxd17hp97lxh9if6qni39qma5z1-gnutls-3.7.7.drv failed >

bug#57965: Problem with freecad substitute

Aleksandr Vityazev writes: > I want to install freecad, substitute available but the package starts > building locally. This is probably due to you ACL, see https://guix.gnu.org/en/manual/devel/en/html_node/Substitute-Server-Authorization.html#Substitute-Server-Authorization signature.asc

bug#57965: Problem with freecad substitute

Aleksandr Vityazev writes: > Hi, > > On 2022-09-21, 08:25 +0100, Christopher Baines wrote: > >> Aleksandr Vityazev writes: >> >>> I want to install freecad, substitute available but the package starts >>> building locally. >> >> This is p

bug#57965: Problem with freecad substitute

Aleksandr Vityazev writes: > On 2022-09-21, 09:26 +0100, Christopher Baines wrote: > >> Assuming you're using a recent revision of Guix, boreaux.guix.gnu.org >> should be in the default substitute URLs and default authorized-keys. >> >> If you're still having

bug#57827: Shepherd 0.9.2 possible regressions

Mathieu Othacehe writes: > Since Shepherd 0.9.2 the following tests are failing: > > * cgit: https://ci.guix.gnu.org/build/1427375/details > * gitile https://ci.guix.gnu.org/build/1427377/details > > It seems that an unexpected # object is received on the marionette > socket. I had a look at

bug#58508: gtg package (Getting Things GNOME) doesn't run

Pkill9 writes: > This is the error I get when running: > > guix environment --ad-hoc gtg -- gtg > > ``` > Traceback (most recent call last): > File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", > line 76, in > gi.require_version('GtkSource', '4') > File >

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

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

Leo Famulari writes: > On Wed, Jan 19, 2022 at 11:28:28AM -0800, Vagrant Cascadian wrote: >> I tried building a newer version, but there were new test suite failures >> on both aarch64 and x86_64 :/ > > Since the 'guix' package still does not build on aarch64, I'm reopening > this bug. It

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 >

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

bug#60207: ci build of latest guix for armhf

eve but do not know that Bordeaux does not actually build the > latest guix, just the packages. bordeaux.guix.gnu.org builds and provides substitutes for the guix pull (channel instance) derivations, for at least some systems. > I don’t know if offering the latest guix would even be feasible.

bug#58586:

Sharlatan Hellseher writes: > Hi Chris, > > This issue is resolved now with listed patches applied. Great :) For future reference, anyone can mark issues as done by emailing x-d...@debbugs.gnu.org, where X is the issue number. I've done that now for this issue. Thanks, Chris

bug#60202: tests/cpio failure

This test seems to fail, maybe because of high inode numbers, maybe something to with btrfs. I saw this with the failed builds here https://data.guix.gnu.org/gnu/store/kg93i3bmvpdfkiqyx6g9r7ywh0xpvm8w-guix-1.4.0 cbaines@milano-guix-1 ~$ guix repl GNU Guile 3.0.8 Copyright (C) 1995-2021 Free

bug#59363: Fw: [PATCH] flatpak: Adjustments to make --with-commit work

Jacob Hrbek writes: > CC mentors -- please review and merge if appropriate I think patches are best sent to guix-patches, even if they relate to a bug filed against the guix package. Also, for some reason, I'm missing the original mail for this bug. Anyway, --with-commit doesn't work because

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

Ludovic Courtès writes: > Agreed! I don’t use GNOME and I don’t even know what KgxNautilus is, > but here’s a patch that may fix this by ensuring Nautilus doesn’t load > the same extension twice. > > Could you give it a spin and lemme know if it solves this issue?\ > > That’ll get us closer to

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

Liliana Marie Prikler writes: > Am Samstag, dem 01.10.2022 um 13:29 +0200 schrieb Tobias Kortkamp: >> Hi, >> >> The problem seems to be that NAUTILUS_EXTENSION_PATH contains the >> same path twice and that it tries to load KgxNautilus from each of >> the paths: >> >> $ echo

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

Tobias Kortkamp writes: > I updated from c8112f3bd95269ce4aca12dedbfe61bb6b37acae to > 0dec41f329c37a4293a2a8326f1fe7d9318ec455 and now Nautilus crashes > with: > > (org.gnome.Nautilus:3664): GLib-GObject-WARNING **: 13:25:09.877: Two > different plugins tried to register 'KgxNautilus'. > >

bug#62051: Early detection of derivations with unreadable builder scripts

Currently it's quite easy to end up with packages that have builder scripts that can't be read by Guile. This is part of the following builder script: (cons "--enable-mpi-java" #) from: /gnu/store/yngxnpcs4s6y8acxf4nwx5pcpj0j6q6i-java-openmpi-4.1.4-builder And when attempting to build that

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

Christopher Baines writes: > I'm seeing this in the build coordinator agent, but it can be reproduced > by tweaking the guix build script as below. The build coordinator uses > suspendable ports as this is required to set timeouts for some I/O > operations. > > I'm guessing t

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

I'm seeing this in the build coordinator agent, but it can be reproduced by tweaking the guix build script as below. The build coordinator uses suspendable ports as this is required to set timeouts for some I/O operations. I'm guessing this is maybe a bug within Guile, but I thought I'd start

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

Christopher Baines writes: > Christopher Baines writes: > >> I'm seeing this in the build coordinator agent, but it can be reproduced >> by tweaking the guix build script as below. The build coordinator uses >> suspendable ports as this is required to set timeouts fo

bug#61642: intermittent write_wait_fd error when updating

Simon Tournier writes: > Hi, > > On dim., 19 févr. 2023 at 17:50, Nathan Dehnel wrote: > >> 'https://substitutes.nonguix.org'... 0.0%Backtrace: > > [...] > >> "https://substitutes.nonguix.org; _ # _ …) > > The issue appears to be on the nonguix side, please report to them. It's not, since

bug#61642: intermittent write_wait_fd error when updating

Simon Tournier writes: > Hi, > > On Mon, 20 Feb 2023 at 11:46, Christopher Baines wrote: > >> It's not, since it relates to code in the (guix substitutes) module. > > Do you mean that if "https://substitutes.nonguix.org; is incorrectly > configured, then the c

bug#61742: icecat.desktop show ??????????

Maxim Cournoyer writes: > Interestingly, this older icecat in my store, at version 102.7.0 didn't > have that problem: You can bisect this by using https://data.guix.gnu.org/repository/1/branch/master/package/icecat/output-history I see this problem start to happen with

bug#62943: Locale issue when rebooting from installation system

root@gnu ~# reboot warning: failed to delete /mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny.pem: No such file or directory warning: failed to delete

bug#61879: Patch

Andreas Enge writes: > Am Thu, Apr 13, 2023 at 06:57:41PM +0200 schrieb Andreas Enge: >> attached is a new commit in old syntax, mixing both our commits. >> I have confirmed that it does not change the gcc-11 build on x86_64 and i686. >> But do we need "--force" for patching? >> Could you maybe

bug#61879: Patch

Andreas Enge writes: > Am Fri, Apr 14, 2023 at 09:20:03AM +0100 schrieb Christopher Baines: >> I haven't tried this yet, but I've had a quick look. I'm not sure >> search-patches will work where it is, since that'll be running in the >> build environment, without any

bug#61879: Powerpc on core-updates

how describe it, but at least this is a step forward. From 382862fc06085ba80380977caf2a1f9c3203a12d Mon Sep 17 00:00:00 2001 From: Christopher Baines Date: Thu, 13 Apr 2023 14:45:14 +0100 Subject: [PATCH] WIP --- gnu/packages/gcc.scm | 108 ++--- gnu/packages/pa

bug#54370: network problem or intentional blocking?

poiNt_3D writes: > Hello. I would like to request a clarification on the issue of > inaccessibility of guix.gnu org from the Russian Federation. Is the > blocking intentional or is there some kind of networking problem? Now that the website is hosted on bayfront, which wasn't changed

bug#64609: Failure to "guix pull" at ddbfef2 on aarch64-linux

Michael Ford writes: > This morning when attempting to guix pull, on arch64-linux machines: > > guix pull > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > Authenticating channel 'guix', commits 9edb3f6 to ddbfef2 (32 new commits)... > Building

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

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and >> (defined? (quote transient?)) (map (# ?) ?)). >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression &g

bug#63794:

"N. Y." writes: > Are there any workarounds, for an inexperienced user who does not know much > about guix? I am getting 404's for > > - > https://bordeaux.guix.gnu.org/nar/zstd/arnx6fnjq85wscmr894d64cj3529r3h1-wxPython-4.2.0.tar.xz > - >

<    1   2   3   >