bug#73193: /var/lib/certbot/renew-certificates may exist but not be up to date

/var/lib/certbot/renew-certificates was previosuly kept up to date, but as of is no longer kept up to date. The script still exists though and may "work" if run, potentially renewing the certificates but based on a older system configuration. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?

bug#71494: data.guix.gnu.org statistics page broken

Antero Mejr writes: > The page at: > https://data.guix.gnu.org/statistics > > appears broken, it is displaying placeholder text relating to the > count-guix-revisions procedure instead of the results themselves. Thanks for reporting this, even when the page was working there were some performanc

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

Christopher Baines writes: > Christopher Baines writes: > >> I've spent a bunch of time in the last few days trying to see if I can >> get the bordeaux build farm moving on core-updates and I think things >> are moving at pace now. ... > Some good progress was

bug#72239: libfaketime (still) broken on i686-linux

Ludovic Courtès writes: > Hi! > > Christopher Baines skribis: > >> When running without datefudge, the tests work and the cd in gtests.sh >> seems to fail: >> >> Running tests for gtests >> TIMESTAMP gtests BEGIN: Mon Jul 22 10:09:27 UTC 2024 >>

bug#72239: libfaketime (still) broken on i686-linux

Ludovic Courtès writes: > Ludovic Courtès skribis: > >> So the easiest short-term solution seems to be using datefudge to run >> the ‘nss’ tests on 32-bit platforms, as Chris already suggested before >> (patch below; it’s being built right now, I’ll see tomorrow if it >> worked…). > > It failed:

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

Christopher Baines writes: > I've spent a bunch of time in the last few days trying to see if I can > get the bordeaux build farm moving on core-updates and I think things > are moving at pace now. Following on from this, builds have mostly paused for the last few days as man

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

Hey, I've spent a bunch of time in the last few days trying to see if I can get the bordeaux build farm moving on core-updates and I think things are moving at pace now. Builds are happening for 6 systems, with the only major omission being i586-gnu, I think there are existing issues with the gui

bug#70456: Request for merging core-updates branch

Maxim Cournoyer writes: > Guillaume Le Vaillant writes: > >> Lars-Dominik Braun skribis: >> >>> Hi, >>> >>> it seems the core-updates branch is first in the merge-queue. haskell-team >>> was successfully built by the CI and is ready to be merged. Since there >>> does not seem to be an ETA for c

bug#71214: bordeaux linux-libre-6.8.10-guix.tar.gz corrupt nar

Richard Sent writes: > Hi Guix! > > The nar for > /gnu/store/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz > on Bordeaux seems to have been corrupted by some mechanism. The URL in > question is > >> URL: nar/none/y813phs2n9xnb7zbcr07g0j9509bzbsb-linux-libre-6.8.10-guix.tar.xz >

bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)

Christopher Baines writes: > Efraim Flashner writes: > >> On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >>> guix-comm...@gnu.org writes: >>> >>> > efraim pushed a change to branch core-updates >>> > in repositor

bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)

Efraim Flashner writes: > On Sun, Jun 09, 2024 at 10:46:10AM +0100, Christopher Baines wrote: >> guix-comm...@gnu.org writes: >> >> > efraim pushed a change to branch core-updates >> > in repository guix. >> > >> > from c8c6883398

bug#70456: branch core-updates updated (c8c6883398 -> 0e06c9697a)

guix-comm...@gnu.org writes: > efraim pushed a change to branch core-updates > in repository guix. > > from c8c6883398 gnu: dico: Add libxcrypt dependency. > new 9804f8c149 gnu: coeurl: Update to 0.3.1. > new 51c7b6d76f gnu: font-gnu-freefont: Build with newer fontforge. > new 0

bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux

Richard Sent writes: > Christopher Baines writes: > >> This derivation seems to have been built fine by the bordeaux build >> farm: >> >> >> https://data.guix.gnu.org/gnu/store/ny56fdcig9cd9bd3pssmlraz2c1q10q8-linux-libre-6.8.10-guix.tar.xz.drv > >

bug#71133: linux-libre-guix.tar.xz CI times out on aarch64-linux

y released > Linux-libre tarballs instead of computing them ourselves [3]. > > [1]: https://ci.guix.gnu.org/build/4711550/log/raw > [2]: https://mail.gnu.org/archive/html/guix-devel/2021-08/msg00077.html > [3]: http://linux-libre.fsfla.org/pub/linux-libre/releases/ > > CC&#

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

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

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

Ludovic Courtès writes: > Christopher Baines skribis: > >> ++ guile -c '(use-modules (guix utils)) >> (display (%current-system))' >> + this_system=x86_64-linux >> ++ guile -c '(use-modules (guix utils)) >> (display (if (string=? "

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

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

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 th

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 a

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 G

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 https://guix.g

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 gn

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 bu

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 G

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: https://data.guix.gnu.org/revision/72308f262c910977e4

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: https://data.guix.gnu.org/revision/9593750698394b6fecd73e7fca00409ea1ffa2e3/package/nss/3.98.0?locale=en_US.UTF

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 re

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 b

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 followi

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

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 fro

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 d

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

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 > none7.8

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 n

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. >> >> https://ci.guix.gnu.org/build/26

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]) 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 top

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

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' https://ci.g

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. > --- > guix/git.sc

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%

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 comp

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

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 f

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 n

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 deri

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 /gnu/store/g9xf

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 t

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 d

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 f

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! > > https://not

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

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

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 > - > https://bordeaux.guix.gnu.org/nar/zstd/26q8viimh3r7354

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 somet

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

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. &message: > "https://bordeaux.guix.gnu.org/nar/zstd/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz: > HTTP download failed: 404 (\"Not Found\")" > > Look: > > $ wget -qO- > https://bordeaux.guix.gnu.org/sx6sr6cs1x8sf5jhgb65r

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

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 co

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 guile-gnutls-v-2.so.0.0.0[7f1e2e79

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 bu

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

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 f

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 l

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 /mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs

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 environm

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

best to apply this patch, or 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 +++

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 timeou

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

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 repo

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 de

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 /gnu/store/2a67f3c5lv14

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,

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 i

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 specifica

bug#60207: ci build of latest guix for armhf

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

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 Soft

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 signa

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

  1   2   3   >