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

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

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

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

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

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#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#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#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#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#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#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#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=? "riscv64-linux&q

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

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

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

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)

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

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

<    1   2   3