bug#65510: Errors trying to use home-dicod-service-type and home-syncthing-service-type

Hello guix! Thank you Ludovic for adding a way to map system services to home services! This is very exciting. However, I can't seem to use some of those services. Take a look at this minimal example home configuration: --8<---cut here---start->8---

bug#65508: Displaying qt applications on wayland using qtwayland is complicated

Hello guix! Before I get into the actual bug I'm trying to report, I have to bring up 2 other complications. 1. qtwayland@6 currently doesn't build due a test failure. So in this bug I'm either using "--without-tests=qtwayland" on the command line or "((options->transformation '((without-tests

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Maxime Devos writes: > [[PGP Signed Part:Undecided]] > Op 23-08-2023 om 01:45 schreef Csepp: >> I tried signing up to the CI mailing list and it immediately became >> overwhelming. > > If the CI list was split in ‘broken’ and ‘fixed’, such that you have > the option to only subscribe to

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Maxime Devos writes: > [[PGP Signed Part:Undecided]] > > > Op 23-08-2023 om 01:45 schreef Csepp: >> Also the CI UI could use some improvements. I'm pretty sure I've >> mentioned this before, but there is no easy way to find out which inputs >> I need to fix to make a dependency failure

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Simon Tournier writes: > Hi, > > On Wed, 23 Aug 2023 at 01:45, Csepp wrote: > >> One possible improvement I have been thinking about is making it easy >> for users to filter CI output to the packages in their profile closure, >> so for example they would get advance notice of any broken

bug#65506: Anki: Preferences Dialog Broken

Hello, The Anki program works well except that if I select Tools >> Preferences menu, I do not get a preferences menu, and instead I get this error: ``` Error An error occurred. Please use Tools > Check Database to see if that fixes the problem. If problems persist, please report the problem

bug#65378: time-machine v1.0.0

Hi Théo, On Thu, 24 Aug 2023 at 14:04, Théo Tyburn wrote: > Thank you for your explaination. We can close this. I am closing. Thanks, simon

bug#65505: [cuirass] Not all dependencies are built as dependencies

For example, consider: https://ci.guix.gnu.org/build/1865837/details . This is a (failed) build of the gwl@0.5.1 package, with dependency guix@1.4.0- It looks like the test tests/publish.scm is functioning, i.e., it succeeded at detecting a bug: make[4]: *** [Makefile:6303:

bug#64317: [Cuirass] Download products can disappear, leading to HTTP 500

Ludovic Courtès skribis: > The /download endpoint refers directly to store items. However, they > can be GC’d in the meantime, in which case the HTTP handler fails > gracelessly (HTTP 500 or so) as shown here: > > 2023-06-27 16:02:24 GET /download/718 > 2023-06-27 16:02:24 Uncaught exception in

bug#65503: Test suite logs aren't printed on failure during package build

From : make[4]: *** [Makefile:6303: tests/publish.log] Error 134 make[4]: Leaving directory '/tmp/guix-build-guix-1.4.0-8.0e6215a.drv-0/source' make[3]: *** [Makefile:6285: check-TESTS] Error 2 make[3]: Leaving directory

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Op 23-08-2023 om 01:45 schreef Csepp: I tried signing up to the CI mailing list and it immediately became overwhelming. If the CI list was split in ‘broken’ and ‘fixed’, such that you have the option to only subscribe to ‘broken’, would that help? A large fraction of messages is for fixed

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Op 23-08-2023 om 01:45 schreef Csepp: Also the CI UI could use some improvements. I'm pretty sure I've mentioned this before, but there is no easy way to find out which inputs I need to fix to make a dependency failure disappear. I think everyone has better things to do than perform a linear

bug#65456: [PATCH 0/2] Split guix build into more steps for 32bit hosts.

Hi! Janneke Nieuwenhuizen skribis: >>From ad94f06620e53fcc1495a2e2479dfc627177047c Mon Sep 17 00:00:00 2001 > Message-ID: > > From: Janneke Nieuwenhuizen > Date: Thu, 22 Jun 2023 08:30:25 +0200 > Subject: [PATCH v4] self: Build directories in chunks of max 25 files at a > time. > > Similar

bug#65474: Reproducing a texlive bug

Hello, Andreas Enge writes: > I can confirm that the same problem presents itself on > guix 9896b37 > Repository-URL: https://git.savannah.gnu.org/git/guix.git > Branch: master > Commit: 9896b37ac53e9b0504de55dd5ba4bfa2c241a7ed > of August 17. > > A likely culprit is > commit

bug#41394: java-testng: again nondeterministic test-failures?

During today's regular "guix pull", I ran into this problem: java-testng failed to build twice (the failures comes from the test suite), but built correctly the third time. That's for commit: 39fa1ef033fda82cb1d122e0d1675b51acb1db34 Cheers, Konrad.

bug#65378: time-machine v1.0.0

Hi, Thanks for the report. On Sat, 19 Aug 2023 at 10:59, Théo Maxime Tyburn wrote: > 4 tests failed: > test_ftplib test_httplib test_ssl test_urllib2_localnet [...] > srfi/srfi-1.scm:592:17: In procedure map1: > Throw to key `srfi-34' with args `(# [message: "build of >

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

Hi, On Wed, 23 Aug 2023 at 01:45, Csepp wrote: > One possible improvement I have been thinking about is making it easy > for users to filter CI output to the packages in their profile closure, > so for example they would get advance notice of any broken packages > *before* attempting to install

bug#65345: guix-pull --list-generations is slow

Hi, On Wed, 16 Aug 2023 at 15:29, Olivier Dion wrote: > $ time guix pull --list-generations > /dev/null > real0m58.702s > user1m8.418s > sys 0m1.527s On my poor laptop, it’s the same (14 Generations): $ time guix pull --list-generations >/dev/null real1m2.201s

bug#65219: OpenFOAM is not reproducible

> Are these files required at run-time? I mean, why are they retain? And > I was guessing they should be removed, no? No they are not required and should be removed > Similar question, no? Why log files and testing files are part of the > output? this is a quirks of the wmake build system

bug#65472: texlive split packages are missing isodate.sty, wallpaper.sty, and dashrule.sty

Hello, "Dr. Arne Babenhauserheide" writes: > after switching to split texlive packages (via texlive-scheme-medium), > my documents fail to compile. > > I cannot find split packages for isodate.sty, wallpaper.sty, and dashrule.sty > > > Minimal reproduction: > > --- file: test.tex --- >

bug#65472: texlive split packages are missing isodate.sty, wallpaper.sty, and dashrule.sty

Hi, "Dr. Arne Babenhauserheide" writes: > guix shell --pure texlive-scheme-medium test > > ! LaTeX Error: File `isodate.sty' not found. > ! LaTeX Error: File `wallpaper.sty' not found. > ! LaTeX Error: File `dashrule.sty' not found. The medium texlive scheme does not contain these packages

bug#65419: [Shepherd] Non-reponding service control fiber

Hi, Giovanni Biscuolo skribis: > I've had a look at /var/log/messages but nothing seems wrong except > messages like this one: > > > Aug 21 14:48:42 localhost shepherd[1]: 6 connections still in use after > sshd-13752 termination. > Aug 21 14:48:42 localhost shepherd[1]: Service sshd-13752

bug#65460: ghc/ghci are broken

Jonas writes: > Thanks! Adding gcc-toolchain to the profile fixed it, but shouldn't this > be automatically brought in by `guix install ghc`? This does still feels > like a bug to me, shouldn't gcc-toolchain be a part of ghcs native-inputs? If this is to happen, it should be a regular input,

bug#65456: [PATCH v3] self: Build guix/ and gnu/packages/ directories in 26 steps.

Janneke Nieuwenhuizen writes: > So, some good news at last; I can confirm that using v4 of this patch we > now have "guix pull", pulling from a local git directory, now fully > working on the Hurd! That’s awesome! Thank you for your work! Best wishes, Arne -- Unpolitisch sein heißt politisch