bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

Maxim Cournoyer writes: > Hello, > > Liliana Marie Prikler writes: > >> Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines: >>> I've seen this when updating systems, but it seems like something is >>> wrong with the handling of nss-ce

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Simon Tournier writes: > On Wed, 22 Nov 2023 at 11:19, Ludovic Courtès wrote: > >> As in: >> >> (open-connection >> #:assume-available-builtin-builders '("download")) > > Instead, why not check in ’git-fetch’? Currently, the test is done > against the local daemon, right? > >

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Christopher Baines writes: > Ludovic Courtès writes: > >> Hi, >> >> Christopher Baines skribis: >> >>> The bordeaux build farm depends on computing the derivations on one >>> machine, then potentially building them on a different machine. >

bug#70663: nss@3.99 is really hard to build

"pelzflorian (Florian Pelz)" writes: > Hello Christopher. > > Christopher Baines writes: >> Had the changes waited for longer, then these failures should have been >> spotted by QA, I would guess that the revision might have failed to be >> processed,

bug#70663: nss@3.99 is really hard to build

Maxim Cournoyer writes: >> Before closing this bug, it would be good to understand more about how >> this happened and from that try to think if anything can be done to >> prevent similar issues in the future? >> >> At least from what I can see on the issues, the problem was introduced >> with

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

When attempting to update the guix package, I got this failure. The test log makes no sense though, as it's trying to test for errors, so I have no idea where to start in working out what is wrong. I thought maybe the issue was here: guix shell: error: package intelmetool@4.7 does not support

bug#70663: nss@3.99 is really hard to build

Christopher Baines writes: > nss@3.99 is really hard to build, it's so hard and so important that > data.guix.gnu.org is still after two days trying to process [1]. I say > so important because you have to build nss@3.99 to compute the channel > instance derivations for Guix.

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

I've seen this when updating systems, but it seems like something is wrong with the handling of nss-certs. I'm on a guix revision with nss-certs by default, and when I add nss-certs to my system packages (to simulate not removing it when upgrading), it breaks certificates (e.g. wget

bug#70838: guix pull fails

Simon Tournier writes: > I think ’nss’ is substitutable, so I guess you are rebuilding from > source, right? > > Well, the build of ’nss’ works for me. > > --8<---cut here---start->8--- > $ guix build /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv

bug#70456: Process gnome-team before core-updates

block 70456 by 70766 thanks I think being able to merge core-updates is still a few weeks away, so I think there's time to build and merge gnome-team without delaying core-updates. If it does become a problem, we can always switch approach and wait until after core-updates is merged to look at

bug#70663: nss@3.99 is really hard to build

Maxim Cournoyer writes: > Hi Chris, > > Christopher Baines writes: > >> nss@3.99 is really hard to build, it's so hard and so important that >> data.guix.gnu.org is still after two days trying to process [1]. I say >> so important because you have to build n

bug#70663: nss@3.99 is really hard to build

Christopher Baines writes: > nss@3.99 is really hard to build, it's so hard and so important that > data.guix.gnu.org is still after two days trying to process [1]. I say > so important because you have to build nss@3.99 to compute the channel > instance derivations for Guix.

bug#70663: nss@3.99 is really hard to build

nss@3.99 is really hard to build, it's so hard and so important that data.guix.gnu.org is still after two days trying to process [1]. I say so important because you have to build nss@3.99 to compute the channel instance derivations for Guix. 1:

bug#70662: Problems building nss@3.98.0

nss@3.98.0 seems really difficult to build, currently on the bordeaux build farm it's failed all attempts to build it on all architectures except riscv64-linux and aarch64-linux [1]. 1:

bug#69466: Wrong colours for QA

Andreas Enge writes: > Am Mon, Apr 22, 2024 at 05:27:58PM +0100 schrieb Christopher Baines: >> When implementing this I chose to have the review trump any other status >> since hopefully any failing builds will have been taken in to account by >> the reviewer. > > My

bug#69466: Wrong colours for QA

Andreas Enge writes: > it looks like the dark green colour is wrongly chosen in QA, > for instance here: >https://qa.guix.gnu.org/issue/69441 > The issue has been reviewed, but "Comparison unavailable > Yet to process revision". > > I think dark green should only appear when the package is

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

Maxim Cournoyer writes: > Hi, > > Christopher Baines writes: > >> Christopher Baines writes: >> >>> I'm also really confused by what commits appear to be on the branch, >>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be

bug#70456: Status of ‘core-updates’

Ludovic Courtès writes: > What’s the status of ‘core-updates’? What are the areas where help is > needed? > > I know a lot has happened since the last update¹, which is roughly when > I dropped the ball due to other commitments, but I’m not sure where we > are now. I haven't really been

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

Christopher Baines writes: > I'm also really confused by what commits appear to be on the branch, > take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one > core-updates, but it's a duplicate of > e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed to &g

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

Hey, Thanks for raising this issue Steve, given the branch has been going for around 9 months (since [1]) now, I think it's well overdue to start looking at building and merging it. 1: https://lists.gnu.org/archive/html/guix-commits/2023-07/msg00332.html I pushed a single commit plus a merge

bug#70284: @ancronym not recognized as valid Texinfo in description

Maxim Cournoyer writes: > Hi, > > Using an acrynym such as @acronym(SNES, Super Nintendo Entertainment > System) currently throws an "invalid Texinfo markup" error at build > time. I think I've used acronyms in descriptions, seems like diffr in rust-apps uses one for example. The brackets are

bug#68439: [bug#69793] [PATCH] gnu: icewm: Update to 3.4.6

Andy Tai writes: > * gnu/packages/wm.scm (icewm): Update to 3.4.6 > > Change-Id: Ieff1fc5417cfe164fa7886774e8855fd95248c8f > --- > gnu/packages/wm.scm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks both, I've pushed this to master as

bug#68561: Guix wrongfully claims there is no space left

Lars Rustand writes: > Guix is claiming that there is no space left on the device when none of > my devices are in fact full. As you can see from the output of df -h > there is more than enough space on all filesystems: > > > Filesystem Size Used Avail Use% Mounted on > none

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> The bordeaux build farm depends on computing the derivations on one >> machine, then potentially building them on a different machine. >> >> Some of the build machines don't have a new en

bug#67305: Build bffe.x86_64-linux on master is broken.

Maxim Cournoyer writes: > Hi, > > cuir...@gnu.org (Cuirass) writes: > >> The build bffe.x86_64-linux for specification master is >> broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/2664791/details;>here. >> >>

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Simon Tournier writes: > Hi Chris, > > On Fri, 17 Nov 2023 at 21:39, Christopher Baines wrote: > >> The bordeaux build farm depends on computing the derivations on one >> machine, then potentially building them on a different machine. >> >> Some of the bu

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

The bordeaux build farm depends on computing the derivations on one machine, then potentially building them on a different machine. Some of the build machines don't have a new enough guix-daemon that understands builtin:git-download, so derivations that use this are sometimes failing (e.g. [1])

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#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#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#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#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#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#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#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#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#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Hello, > > Sorry for the late reply! > > I removed > http_proxy=http://127.0.0.1:9080 https_proxy=http://127.0.0.1:9080 > from my "Environment" variable in "guix-daemon.service" and after I restarted > the Guix daemon "guix pull" and "guix upgrade" went flawlessly. >

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Besides, I run GNU Guix on Ubuntu 22.04.2 LTS. > Please find my SystemD Guix service attached. > > As you can see, I'm using a substitution service through Yggdrasil > network: http://ci.guix.ygg.trop.in > Also there's a proxy server configured. The downloading of the

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Hello Christopher, > > I tried to build "texlive-hyphen-complete" using a local Guix clone > with the following commands: > > $ cd guix > $ guix shell -D guix > $ ./bootstrap > $ make -j$(nproc) > $ guix build -K texlive-hyphen-complete > > Also I tried to build the

bug#64872: guix pull: po4a: build failed

Artyom Poptsov writes: > Huh, it seems that the problem not in "po4a" itself but in > "texlive-hyphen-complete". > > When I try to access > > https://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen > I get 404 error. Ok, well maybe try building

bug#64872: guix pull: po4a: build failed

Artyom Poptsov writes: > Hello, Guixers. > > Recently I started to see this error on "guix pull" -- please see > the logs attached. Are you able to share the end of the build log for /gnu/store/qcjl6wfiy662s9knwvkb24vkrviw3jdn-po4a-0.68.drv ? It has been built at least, so you should be able

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

Christopher Baines writes: > To confirm that this is an issue with the supported systems as reported > by Guix, I had the data service print out the transitive supported > systems for the guix package: > > debug: Starting getting derivations for (i686-linux . #f) > looki

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

Hey, I spotted this issue a few days ago, but I'm still pretty confused by it. Both instances of the data service have sometimes been reporting only a small number of package derivations for i686-linux and armhf-linux. I think the first revisions to exhibit this on the master branch for the two

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#64297: [Cuirass] Remote server not picking up job, losing workers

Ludovic Courtès writes: > Ludovic Courtès skribis: > >> The problem is most likely with the connection-to-port caching in >> squee’s ‘connection-socket-port’, as can be seen in this other trace >> where I added ‘pk’ calls in ‘connection-socket-port’: > > Confirmed, with a fix! > >

bug#64197: Segmentation fault while building ‘guix-cli-core.drv’

Ludovic Courtès writes: > I’ve seen this “failure to process the revision” on qa.guix due to a > segfault while building Guix (from > , commit > f3ec19edf3c3bb902a06ac597e5954b35ee41bce): > > loading... 89.7% of 39 files[ 36/ 78] loading... 92.3% of

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

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Hi, >>> >>> Christopher Baines skribis: >>> >>>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Ludovic Courtès writes: > Christopher Baines skribis: > >> I've seen this happen with the build coordinator agent now (on >> milano-guix-1): >> >> 2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG): >> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the avail

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Christopher Baines writes: > Ludovic Courtès writes: > >> Christopher Baines skribis: >> >>> Since the recent core-updates merge, I've seen the build coordinator >>> using less memory, but it's also been crashing in a new way, up to 10 >>> times

bug#63794: Acknowledgement (Bad error reporting in case of 404 during downloading)

Maxime Devos writes: > From: Christopher Baines >> I think the key bits here might be a duplicate of #63634 > > Looks like I need to upgrade my Guix system to fix substitution > ... but "guix system build" is currently failing, which needs > [cycle!]. > > Th

bug#63794: Bad error reporting in case of 404 during downloading

Maxime Devos writes: > Problems: > * The server not having a file is not an exceptional situation; > it should just skip this server or just report that there > is no available location for this resource instead of > a backtrace. > > * It claims ‘corrupt input while restoring

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

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#63368: Build coordiantor "Signals delivery fails constantly" crashes

Ludovic Courtès writes: > Christopher Baines skribis: > >> Since the recent core-updates merge, I've seen the build coordinator >> using less memory, but it's also been crashing in a new way, up to 10 >> times a day. >> >> In the log, you see something like:

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

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't >> reboot or halt. >> >> root@hamal ~# halt >> Service root is not running. > > Hey, why halt it if it’

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

Hey! On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't reboot or halt. root@hamal ~# halt Service root is not running. 1: /gnu/store/y6w0xix15cq08qasmq75f04yzgbl98jx-shepherd-0.9.3 signature.asc Description: PGP signature

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

Ludovic Courtès writes: > Simon Tournier skribis: > >> 2. : > "https://bordeaux.guix.gnu.org/nar/zstd/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz: > HTTP download failed: 404 (\"Not Found\")" > > Look: > > $ wget -qO- >

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

Ludovic Courtès writes: > So it seems ‘guix substitute’ picked /nar/zstd, even though > bordeaux.guix is not advertising that. > > Or is it? > > $ sudo cat > /var/guix/substitute/cache/kzwjeblndsbkjzmjailrt4bnhguil7tqjmewzcyw22hgajbhfy3q/apw1y9nf8rqgxvjnlr1isbhpd502bcs5 > (narinfo (version 2)

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

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? >> >> May 11 14:31:39 localhost vmunix: [15795370.287670] >&g

bug#63414: Evaluation comparison on cuirass

Josselin Poiret via Bug reports for GNU Guix writes: > Hi Andreas, > > Andreas Enge writes: > >> 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

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

I've seen the build coordinator on bayfront crash a couple of times, and it seems to be segfaulting, maybe in gnutls? May 11 14:31:39 localhost vmunix: [15795370.287670] build-submitted[6013]: segfault at 0 ip 7f1e2e796415 sp 7f1b86ffd640 error 4 in

bug#63331: Guile-GnuTLS/Git circular dependency

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> It seems to build for me, but I'm having problems cross building. There >> were warnings before about protocol/ssl3 being undefined, but now this >> seems to result in an error when buildin

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Christopher Baines writes: > Since the recent core-updates merge, I've seen the build coordinator > using less memory, but it's also been crashing in a new way, up to 10 > times a day. > > In the log, you see something like: > > 2023-05-07 09:15:42 Signals delivery f

bug#63331: Guile-GnuTLS/Git circular dependency

Simon Josefsson via Bug reports for GNU Guix writes: > [[PGP Signed Part:Undecided]] > Ludovic Courtès writes: > >> We need to solve that. For now, the only fix I can think of is having >> ‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently >> we can add assets at

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Since the recent core-updates merge, I've seen the build coordinator using less memory, but it's also been crashing in a new way, up to 10 times a day. In the log, you see something like: 2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051 2023-05-07 09:15:42 Signals delivery

bug#56625: [core-updates] libaio test fails on powerpc64le-linux due to kernel bug

Thiago Jung Bauermann via Bug reports for GNU Guix writes: > On the core-updates branch, libaio has been updated to version 0.3.113. > This version contains a new test which fails on guixp9 (one of the > powerpc64le-linux builders) due to a bug present in the kernel it is > running: ... > So

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

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

  1   2   3   >