bug#24841: Cross-building bootstrap binaries fail in current master

zimoun writes: > What is the status of this bug#24841 report [1]? > > 1: I agree we can close this old bug report. As you mentioned, it is now possible to build bootstrap binaries for various architectures. If someone needs to build bootstrap binaries

bug#49355: [guix-jupyter] timeout issue running the kernel

After a very painful bisect with various issues appearing in jupyter (unrelated to this one), I've identified the first good commit and the first bad commit. The commit range which caused the problem is between 95f25c9b13e22603c35f3acd9048fbd1c8671925 and

bug#48974: A possible shepherd bug (it's very minor)

Leo Prikler writes: > Hi, > > Am Freitag, den 02.07.2021, 18:57 -0400 schrieb Joshua Branson: >> Leo Prikler writes: >> >> > Am Freitag, den 25.06.2021, 14:06 -0400 schrieb Joshua Branson: >> > > Leo Prikler writes: >> > > >> > > > Hi, >> > > > >> > > > Am Freitag, den 25.06.2021, 05:31

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

Hi, I found [1] which lists which versions of OpenEXR are vulnerable to which CVE. All the CVEs mentioned here were fixed in version 2.5.4 [2], while we are currently tracking version 2.5.5, for which there are no known CVEs. I will close this issue. Feel free to reopen if I missed anything.

bug#49355: [guix-jupyter] timeout issue running the kernel

Having done some time-machining, I can confirm that 68c9e0a56e008f19427bd213cf5b24bdd8fe5922 is a good commit. The guix kernel works fine on it. I don't however yet know which commit caused the regression, but if nobody finds it until I have more time to bisect, I'll report back. -- Domagoj

bug#48064: texlive-* packages fail to build non-deterministically

Hi Ludo, Em segunda-feira, 5 de julho de 2021, às 06:20:20 -03, Ludovic Courtès escreveu: > Thiago Jung Bauermann skribis: > > LuaTeX has a bug where sometimes it corrupts the heap and aborts. This > > causes the build of texlive packages to fail at random. The problem is > > being tracked at

bug#49171: OCaml packages not building (due to updated python-pyyaml)

On Sun, Jul 04 2021, pukkamustard wrote: > Xinglu Chen writes: > >> I think this was fixed in commit >> 91b29aa37394b660117e1d79927621db1344b7fe (gnu: ocaml-dose3: Fix >> tests.), >> do you think we can close the issue? > > Yup, was fixed and already closed by Julien (see >

bug#42760: Elixir build fails

Hi Yes. This was fixed in commit a3e26863146ffc100ced3600bfc49814d04ae643: https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a3e26863146ffc100ced3600bfc49814d04ae643 Oskar On Mon, 5 Jul 2021, at 12:51, zimoun wrote: > Hi, > > Thanks for the report and sorry for the

bug#48756: guix offload: error: corrupt input while restoring archive from #

Many thanks for your time and effort in debugging this. I can confirm this issue is resolved. Regards -- Madhavan Krishnan

bug#48903: guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet.

Maxim Cournoyer skribis: > Ludovic Courtès writes: > >> Hi, >> >> Maxim Cournoyer skribis: >> >>> I've tried with the following modified version which runs multiple >>> threads in parallel (to mimic --max-jobs=4 on the daemon), and I've yet >>> to trigger it, although the hard drive is

bug#42760: Elixir build fails

Hi, On Mon, 5 Jul 2021 at 17:50, Oskar Köök wrote: > Yes. This was fixed in commit a3e26863146ffc100ced3600bfc49814d04ae643: > https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/elixir.scm?id=a3e26863146ffc100ced3600bfc49814d04ae643 Thanks. So closing. :-) Cheers, simon

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

I've run into the same problem, seems like fetching the revised cabal file would be the best bet. (In the meantime I've modified package definitions to make the metadata changes, but that is manual and certainly should be automated by import.)

bug#47018: core-updates: make check fails when guix-daemon is running

Hi, Lars-Dominik Braun skribis: > In guix/packages.scm: >1638:7 3 (_ _) > 619:2 2 (patch-and-repack # /gnu/store/l9nzv7lmznp2y22i2n3j7mccz5jjhlv1-tar-1.34.tar.xz.drv => > /gnu/store/4y8yhyxhvh725bp3bk7wzr3jn8r5hjm0-tar-1.34.tar.xz 7fa2f699d280> >

bug#42301: Build of GNU Solfege fails

It works for me now. I will close if nobody beats me to it. OpenPGP_signature Description: OpenPGP digital signature

bug#42979: Some kde games are outdated

I agree that this can be closed. lskat does not render properly, but that's a different issue. On 7/5/21 3:28 AM, zimoun wrote: Hi, On Fri, 21 Aug 2020 at 15:33, Jesse Gibbons wrote: The following KDE games fail to build: kblocks kdiamond kigo klines kollision lskat The upstream git

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

The hackage store of haskell packages allows maintainers to update package metadata directly on hackage without updating the associated archive of a package. For instance, the cabal file of the integer-logarithms package version 1.0.3 [0] has been updated since 1.0.3 was published, relaxing the

bug#42301: Build of GNU Solfege fails

Hi, On Mon, 5 Jul 2021 at 15:46, Tim Magee wrote: > It works for me now. I will close if nobody beats me to it. Thanks. So closing. (-: All the best, simon

bug#49417: glibc uses "objcopy", but seems to need "TARGET-objcopy" [core-updates]

User: guix-de...@gnu.org Usertags: powerpc64le-linux Here is an extract from the build log () /gnu/store/ar373sjda7fz0m4mav6rdfmv49vv6r87-bash-minimal-5.1.8/bin/sh ../scripts/move-if-change

bug#30122: python-pygobject with gtk+ broken.

Hi, Thiss old bug [1] is about python-pygobject. 1: On Mon, 15 Jan 2018 at 13:15, Fis Trivial wrote: > * Steps to reproduce: > Install python-pygobject with guix: `guix package -i python-pygobject` > Install gtk+ with guix: `guix package -i gtk+` > > $

bug#30518: teeworlds fails on core-updates due to freetype-update (and contains files to be snipped)

Hi, On Sun, 18 Feb 2018 at 21:46, Björn Höfling wrote: > I thought of looking closer at some core-updates failures and looked at > this evaluation: > > https://hydra.gnu.org/eval/109914?full=1=109912 > > Randomly I stumbled over a failing teeworlds: > >

bug#42301: Build of GNU Solfege fails

Nicolas Goaziou writes: > Fine by me, but I'm not the OP. dito. -- Thus spake the master programmer: "Without the wind, the grass does not move. Without software, hardware is useless." -- Geoffrey James, "The Tao of Programming" signature.asc Description: PGP signature

bug#29655: Elixir build has an undeterministic build error

Hi, This old bug [1] is about a failure of elixir. 1: On Sun, 17 Dec 2017 at 08:54, Pjotr Prins wrote: > The epipe error suggests a new external process is invoked (git) > which does not terminate properly and does not close the pipe. Maybe > it tries

bug#28602: Unpack fails with no error message when using a .zip source

Hi, Thanks for the patch and sorry for the delay. On Mon, 09 Oct 2017 at 23:00, nee wrote: > Hello here is a patch to fix this bug. It changes the gnu-build-system, > so the hashes of almost all packages will also change. I guess > core-updates is the right branch for this. > >>From

bug#28554: teeworlds not starting

Hi, This bug [1] is related to the game 'teeworlds' using non-standard hardware. 1: On Fri, 22 Sep 2017 at 15:19, mray wrote: > Running guix on ubuntu 17.04 teeworlds does not start. > > $ teeworlds > [59c505a6][engine]: running on unix-linux-amd64

bug#29021: gnu: biber@2.7: "check" phase fails at "dateformats.t" tests

Hi, This old bug [1] is about a failure of the package 'biber'. 1: On Thu, 26 Oct 2017 at 21:51, Adonay Felipe Nogueira wrote: > $ guix package --fallback -i biber > starting phase `configure' > running `perl' with arguments ("Build.PL" >

bug#42301: Build of GNU Solfege fails

Hello, zimoun writes: > Using Guix 3694c0d, the package ’solfege’ builds and the substitute is > available. The package ’lilypond’ too. > > Something probably changed in the dependency chain since commit > 145484e8f5d89911f5f905c9fe604e3cbfd1e434 (fail). > > Closing? Fine by me, but I'm not

bug#49415: ‘Internal compiler error: Segmentation fault’ when building aarch64-linux-gnu cross-compiler [core-updates]

Hi guix, While testing a patch re-introducing %build-inputs when cross-compiling (probably irrelevant to the build failure though), I encountered an ICE (internal compiler error). I checked 'dmesg'; it is not an OOM. I believe I encountered similar errors in the past, though they disappeared

bug#42091: mesa-20.0.8 fails during testing: preprocessor error: syntax error, unexpected end of file

Hi, Thanks for the report and sorry for the delay. The package ’mesa’ is now at 20.2.4 using Guix 3694c0d. The package builds and the substitute is available. How is it going for you? All the best, simon

bug#41943: kigo package fails to build

Hi Leo, Using Guix 3694c0d, the package ’kigo’ builds fine. Closing? Cheers, simon

bug#25952: offloading: empty machines file leads to error

Hi, For reference: . On Mon, 14 Sep 2020 at 19:26, zimoun wrote: > On Tue, 26 May 2020 at 00:43, zimoun wrote: >> On Mon, 25 May 2020 at 22:32, Tobias Geerinckx-Rice wrote: >> >>> The issue is that files such as /etc/guix/machines.scm (but this >>>

bug#42301: Build of GNU Solfege fails

Hi, Using Guix 3694c0d, the package ’solfege’ builds and the substitute is available. The package ’lilypond’ too. Something probably changed in the dependency chain since commit 145484e8f5d89911f5f905c9fe604e3cbfd1e434 (fail). Closing? All the best, simon

bug#42760: Elixir build fails

Hi, Thanks for the report and sorry for the delay. On Sat, 08 Aug 2020 at 13:04, Oskar Köök wrote: > Elixir build is failing for me. Don't have time to debug right now. This is > the log: > > phase `unpack' succeeded after 0.2 seconds > starting phase `make-git-checkout-writable' > phase

bug#42810: Guix doesn't follow all symlinks

Hi, Thanks for your report. On Tue, 11 Aug 2020 at 15:54, Steffen Rytter Postas wrote: > Some background first, to better understand the issue: > I've been running Guix on a foreign distribution > with my own channel in ~/.config/guix/channels.scm for some time now. > However this means

bug#42604: Manual section on building Guix from Git is incomplete

Hi, Thanks for the report. On Wed, 29 Jul 2020 at 15:03, Tirifto wrote: > The manual describes how to fetch Guix from Git in section ‘14.1 > Building from Git’, including how to verify the authenticity of the > copy. Quoting the part in question: > >> If you want to hack Guix itself, it is

bug#42819: problem running xtensa-esp32-elf-g++

Hi, On Wed, 12 Aug 2020 at 11:55, Wensheng Xie wrote: > I have installed https://github.com/sudomesh/disaster-radio under guix > 1.1.0 How did you install this package? > ``` > wxie@guix ~/work/disaster-radio/firmware$ pip install -U platformio This way is not related Guix, IMHO. :-) >

bug#47636: building for foreign arches produces native code on core-updates

Efraim Flashner skribis: > $ ./pre-inst-env guix build hello --system=i686-linux > /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10 > $ file /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello > /gnu/store/j8kszh3mgi2f9k3vy8kl5mk0lgsp9qdf-hello-2.10/bin/hello: ELF 64-bit >

bug#48216: [CORE-UPDATES] host-inputs for wrong architecture when building for i686 on x86_64

Hello! Efraim Flashner skribis: > I'm trying to see if the rust bootstrap process works on core-updates > and I was unable to build for i686-linux on x86_64 linux. I failed to > build xz, due to some assembly optimizations. It turns out that instead > of using i686 binaries it was using x86_64

bug#43130: mailutils-3.10 test phase

Hi Vladimir, On Sun, 13 Dec 2020 at 15:37, Leo Famulari wrote: > On Mon, Aug 31, 2020 at 01:18:32PM +0600, Vladimir K wrote: >> ## - ## >> ## Test results. ## >> ## - ## >> >> 2 tests were successful. >> 1 test was skipped. >> >> command "make" "check" failed with status

bug#42979: Some kde games are outdated

Hi, On Fri, 21 Aug 2020 at 15:33, Jesse Gibbons wrote: > The following KDE games fail to build: > > kblocks > kdiamond > kigo > klines > kollision > lskat > > The upstream git repositories all have tags for version 20.8.0, but there are > no source tarballs in the mirrors. Using Guix 3694c0d,

bug#48064: texlive-* packages fail to build non-deterministically

Thiago Jung Bauermann skribis: > LuaTeX has a bug where sometimes it corrupts the heap and aborts. This > causes the build of texlive packages to fail at random. The problem is > being tracked at https://issues.guix.gnu.org/48064. > > While a fix isn't found, switch the default TeX format (and

bug#41625: Sporadic guix-offload crashes due to EOF errors

Hi, Maxim Cournoyer skribis: > Now that I have root access to overdrive1, I could strace the sshd > process (I just did 'strace -p340', noting the process of sshd displayed > with 'herd status sshd'): > > pselect6(87, [3 4], NULL, NULL, NULL, NULL) = 1 (in [3]) > accept(3, {sa_family=AF_INET,

bug#48064: texlive-* packages fail to build non-deterministically

Hello! Thiago Jung Bauermann skribis: > I have bad news and good news. :-) > > Unfortunately, TeX Live 2021 still has this bug. I tested version 20210325 > (which is the latest on the historic TeX Live FTP site), with subversion > tag texlive-2021.3 (which is the latest tag in the TeX Live

bug#48111: tilde in Go package names (eg. sourcehut hosted packages)

Hello, Am Sonntag, den 04.07.2021, 15:51 -0700 schrieb Sarah Morgensen: > It might be slightly uglier, but I think it's better to keep a > consistent policy of "replace any invalid characters with a hyphen", > as it is less likely to generate collisions and it provides a hint to > the reader that

bug#49372: lagrange: illegal instruction

It sounds like everything's working now so I'm going to close the bug. On Sun, Jul 04, 2021 at 05:40:41PM -0800, Christopher Howard wrote: > I rebuilt from source and challenge now seems to be okay: > > christopher@nightshade ~/Repos/guix-working$ guix challenge lagrange > > 1 store items were