bug#69394: cross-gcc-toolchain for riscv64 doesn't search crt1.o properly

Hello Jean-Pierre, Today I ran into the issue reported in this bug with a custom toolchain package for aarch64-linux-gnu. I applied your patch from issue 68058 and that solved the problem! Thank you very much for your insights and proposed solutions. A couple of comments below: Jean-Pierre De

bug#22020: [PATCH] gnu: guile-sdl: Update to 0.6.1

Hello Efraim, Efraim Flashner writes: > [[PGP Signed Part:Undecided]] > It's been a while since you submitted this patch, but it's applied now. > Thanks! I had forgotten about this patch. Thank you! -- Thanks Thiago

bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.

Hello Marcel, Marcel van der Boom writes: > The freecad package fails to build. The following error is the > relevant part from the log. > > I'm on powerpc64le, which is usually somewhat problematic in > building. Not sure if that is relevant for this issue though. > > CMake Error at

bug#56005: [bug#56867] [PATCH] download: Do not wrap TLS port on GnuTLS >= 3.7.7.

Hello Ludo, I don't have any comment/insight on what you're doing in general, except about one of your points below: Ludovic Courtès writes: > First, I noticed that GnuTLS doesn’t implement ‘write_wait_fd’, only > ‘read_wait_fd’ (not sure how problematic that is): > > scheme@(guile-user)>

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

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: --8<---cut here---start->8--- Starting

bug#56005: during substitution: write_wait_fd: unimplemented

Hello, This bug was closed, but I couldn't find what was the resolution of the problem. Could someone please clarify, for my own education and also so that it gets documented in the bug report? -- Thanks Thiago

bug#51466: bug#53355: bug#51466: bug#53355: guix shell --check: confusing error message

Hello, Bengt Richter writes: > Lots could be prettier if bash could be extended with scheme. Today is your lucky day. :-) $ guix show guile-bash | recsel -p name,synopsis name: guile-bash synopsis: Extend Bash using Guile -- Thanks Thiago

bug#22020: [PATCH] gnu: guile-sdl: Update to 0.6.1

This version's testsuite passes on i686-linux. Fixes . * gnu/packages/sdl.scm (guile-sdl): Update to 0.6.1. --- Hello, I was looking at bug 22020 (guile-sdl-0.5.2 fails to install on i686) and noticed that upgrading guile-sdl to the latest version fixes the

bug#56005: exception while downloading substitutes

Hello, I just ran “guix pull && guix package -u” and after downloading many substitutes, guix package aborted with the following error: --8<---cut here---start->8--- ⋮ substitute: atualizando substitutos de "https://ci.guix.gnu.org;... 0.0%Backtrace:

bug#55136: keepassxc segfaults when merging databases

Hello, Maxim Cournoyer writes: > Hello, > > Aurora writes: > >> raingloom writes: >> >>> Sorry, can't really send the database files, obviously. >>> >>> Here is the error message instead. >>> >>> ``` >>> failed to register FdoSecrets::Item(0x5596b3d47a20) at >>>

bug#53752: guix home symlink permissions

Em quinta-feira, 3 de fevereiro de 2022, às 18:22:49 -03, Zacchaeus Scheffer escreveu: > It seems the permissions on the symlink don't matter. The problem is > that the file linked to in the store is readable by everyone (which I am > ok with because it's just public keys). > > There is a

bug#53752: guix home symlink permissions

Hello Zacchaeus, Em quinta-feira, 3 de fevereiro de 2022, às 15:08:12 -03, Zacchaeus Scheffer escreveu: > I finally migrated my home configuration to guix home. However, it seems > guix home creates all symlinks with 777 permissions. This causes > problems with openssh as it will not recognize

bug#53214: Release 1.4.0 progress

Hello, Em sábado, 29 de janeiro de 2022, às 21:22:21 -03, Vagrant Cascadian escreveu: > On 2022-01-29, Leo Famulari wrote: > > The build farm is having trouble building Guix for i686-linux. In fact, > > it hasn't successfully completed the 'guix' job in weeks: > > > >

bug#52585: lualatex: Unexpected non-option argument(s): lualatex.fmt

Hello, Em segunda-feira, 24 de janeiro de 2022, às 11:11:25 -03, Pāladhammika escreveu: > Hello, > > Yes! I also noticed. Can now upgrade to texlive2021 with no issues > building my documents. Thanks for your effort and support. Awesome! Ricardo Wurmus has been fixing some issues with TeX Live

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

Hello, Em quinta-feira, 20 de janeiro de 2022, às 08:27:38 -03, Jorge P. de Morais Neto via Bug reports for GNU Guix escreveu: > Hello. So the solution to the bug is for the user to manually write the > file ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf ? > > I would like to

bug#48903: bug#42902: texlive substitute TLS error: decoding the received packet

Hello, [ Sending again to 48903 (and excluding everyone else from the recipients) because this bug was archived and thus the original message bounced. ] I’m sending this email to two bugs because they are both about the same problem. Bug 48903 (which is currently closed) has fairly intense

bug#42902: texlive substitute TLS error: decoding the received packet

Hello, I’m sending this email to two bugs because they are both about the same problem. Bug 48903 (which is currently closed) has fairly intense attempts at debugging what is going on, but unfortunately without arriving at an answer. This problem is also affecting Cuirass builds. This

bug#52585: lualatex: Unexpected non-option argument(s): lualatex.fmt

Hello Sergiu, Hello Pāladhammika, Em terça-feira, 28 de dezembro de 2021, às 09:16:32 -03, Sergiu Ivanov escreveu: > Hello, > > I am chiming in to say that I have the same issue. In my case this > doesn't seem related to https://issues.guix.gnu.org/51252 , because > I install the entire

bug#51787: Disk performance on ci.guix.gnu.org

Hello, Ricardo Wurmus writes: > Today we discovered a few more things and discussed them on IRC. Here’s > a summary. > > /var/cache sits on the same storage as /gnu. We mounted the 5TB ext4 > file system that’s hosted by the SAN at /mnt_test and started copying > over /var/cache to

bug#52694: time-machine error when leaping from version-1.2.0 to version-1.4.0

Hello, zimoun writes: > Hi Carl, > > On Mon, 20 Dec 2021 at 17:28, Carl Dong wrote: > >> $ guix time-machine --branch=version-1.2.0 -- time-machine >> --commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe > > This works for me: > > $ guix time-machine --branch=version-1.2.0 --

bug#52411: [core-updates-frozen] kmod-29 build fails, cross-compiled for i586-pc-gnu

Hello, Em sábado, 18 de dezembro de 2021, às 01:11:48 -03, Maxim Cournoyer escreveu: > > I think I might have found the issue. The following commit made the > > existence/absence 'kmod' input of pciutils depend on %current- > > system/%current-target-system: > > > >

bug#51252: bug#52268: [PATCH core-updates-frozen] gnu: Add texlive-latex-luatex.

Hello Ludo, Em domingo, 5 de dezembro de 2021, às 12:40:33 -03, Ludovic Courtès escreveu: > Thiago Jung Bauermann skribis: > > Ricardo Wurmus suggested creating a new package to provide > > ‘lualatex.fmt’ for LuaTeX as a workaround. This is what this package > > does.

bug#51252: [PATCH core-updates-frozen] gnu: Add texlive-latex-luatex.

When TeX Live was updated to version 2021 the ‘lualatex’ format started being generated with the LuaHBTeX engine, but the ‘lualatex’ command still uses the LuaTeX engine. This causes the command to fail: user@popigai:~$ lualatex hello.tex This is LuaTeX, Version 1.13.0 (TeX Live 2021/GNU

bug#49600: [core-updates] gcc-11 fails to cross-compile from x86_64-linux

Hello Sam, Sorry, I missed your message when you sent it originally and just found it now. Em terça-feira, 31 de agosto de 2021, às 23:02:04 -03, Sam James escreveu: > Seem to have hit the same thing in Gentoo (reported as > https://bugs.gentoo.org/811294). > > Has Guix found a workaround

bug#51252: [core-updates-frozen] lualatex needs additional setup

Hello, I did some investigation about this problem today. Sorry for the trouble. Em quarta-feira, 20 de outubro de 2021, às 18:45:35 -03, Ricardo Wurmus escreveu: > “texlive-latex-base” provides that file. We disable a whole bunch > of formats that we cannot build that early in the process,

bug#51452: Numpy fails test suite with illegal instruction error on Core 2 Duo

Hello Maxim, Em quinta-feira, 28 de outubro de 2021, às 01:32:02 -03, Maxim Cournoyer escreveu: > I'm not sure what's at cause; I have the same problem when testing > against the current 1.17.3. Just a shot in the dark, but could this be related to the compiler version in the master branch?

bug#50031: gcc-core-mesboot1 may not be deterministic

Hello Ludo, Em segunda-feira, 20 de setembro de 2021, às 04:11:13 -03, Ludovic Courtès escreveu: > Hi Thiago, > > Thiago Jung Bauermann skribis: > > Using Guix from both the ‘master’ branch¹ and from the > > ‘core-updates-frozen’ branch², the following command fails:

bug#49921: go-1.16 build failing on aarch64: "fatal error: runtime.newosproc"

Hello Sarah, Em sexta-feira, 10 de setembro de 2021, às 19:14:06 -03, iskar...@mgsn.dev escreveu: > Hi Thiago, > > (Re-sent due to missing Cc.) > > September 10, 2021 3:06 PM, "Thiago Jung Bauermann" wrote: > > Hello Sarah, > > > > Em quinta-fe

bug#49921: go-1.16 build failing on aarch64: "fatal error: runtime.newosproc"

Hello Sarah, Em quinta-feira, 2 de setembro de 2021, às 15:47:08 -03, Sarah Morgensen escreveu: > I think this might be related to [0], although if it's true that CI uses > native builders for aarch64 now, I have no idea. The CI has two native aarch64 builders (which also do armhf, despite bugs

bug#50031: gcc-core-mesboot1 may not be deterministic

Hello, Using Guix from both the ‘master’ branch¹ and from the ‘core-updates-frozen’ branch², the following command fails: --8<---cut here---start->8--- $ guix build --check \ -e '(@@ (gnu packages commencement) gcc-core-mesboot1)’ ⋮ guix build: erro:

bug#49935: [PATCH] gnu: gcc-4.8: Fix build with GCC 6 and later

Versions of GCC earlier than 6 need this change in order to be built by GCC 6 and later. At the time, the fix was backported to GCC 4.9 and GCC 5 but not GCC 4.8. Therefore, backport the fix from GCC 4.9 to GCC 4.8. * gnu/packages/gcc.scm (gcc-4.8)[source]: Apply

bug#49935: gcc-4.8 fails to build with recent GCC versions

Hello, According to the CI results, gcc-4.8 hasn’t built successfuly in a while: https://ci.guix.gnu.org/search?query=gcc-4.8 I was able to fix the current build failure: --8<---cut here---start->8--- In file included from

bug#49815: Upcoming timekeeping failure in gpsd

Hi Sarah, Em sábado, 7 de agosto de 2021, às 00:13:16 -03, Sarah Morgensen escreveu: > > @@ -259,6 +261,7 @@ such as elevation, speed, heart rate, power, > > temperature, and gear shifts.")> > > (modify-phases %standard-phases > > > > (add-after 'unpack 'fix-build > >

bug#49815: [PATCH] build-system/scons: Set $CPPPATH

Hi, Em sexta-feira, 6 de agosto de 2021, às 19:55:17 -03, Thiago Jung Bauermann escreveu: > I was able to build your patch using this one. Actually no. Sorry, I spoke too soon. It still fails. Back to the drawing board. -- Thanks, Thiago

bug#49815: [PATCH] build-system/scons: Set $CPPPATH

The SCons build system sets the compiler include path from the $CPPPATH environment variable while GCC and Guix use $C_INCLUDE_PATH, so set the former with the value of the latter. * guix/build/scons-build-system.scm (build): Set $CPPPATH from $C_INCLUDE_PATH. --- Hi Leo, I was able to build

bug#49752: [coreu-updates] coreutils-final test failures on powerpc64le-linux

Both in the CI and on my laptop this problem happened under emulation. I just tested on real hardware (a POWER8 VM on the Unicamp/IBM Minicloud) and couldn’t reproduce the problem. I tested with: $ ./pre-inst-env guix build --check --rounds=5 \ -e '(@@ (gnu packages commencement)

bug#49847: OpenGL applications may fail to run on foreign distributions

Hi, Em terça-feira, 3 de agosto de 2021, às 14:33:06 -03, Maxim Cournoyer escreveu: > It appears this issue may have a solution in enabling libglvnd [0] > support in our Mesa so that the GPU hardware vendor provided libGL.so > could be loaded from the system instead. As some additional

bug#49752: [coreu-updates] coreutils-final test failures on powerpc64le-linux

Hi, On core-updates, as of the following commit from July 26th: e2690a8eb2df gnu: mes-rb5: Remove. Guix fails to build ‘(@@ (gnu packages commencement) coreutils-final)’ on powerpc64le-linux. E.g.: https://ci.guix.gnu.org/build/692547/details The problem happens during the ‘check’ phase,

bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs

Hello, Em quarta-feira, 21 de julho de 2021, às 11:31:25 -03, Kaelyn escreveu: > Hi, > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, July 21st, 2021 at 1:08 AM, Chris Marusich wrote: > > Now run it: > > > > --8<---cut here---start->8--- > > > >

bug#49600: [core-updates] gcc-11 fails to cross-compile from x86_64-linux

Hi, There were several commits added to GCC’s ‘releases/gcc-11’ branch since the 11.1.0 release, so I wanted to check whether this problem was fixed by any of them. I applied the patch containing those commits to the gcc-11 package, obtained by running the following on a git checkout of the

bug#49600: [core-updates] gcc-11 fails to cross-compile from x86_64-linux

Hello, On core-updates (at least as of commit 8456581375cf), the gcc package fails to cross-compile. This can be seen in the following CI jobs: • https://ci.guix.gnu.org/build/667365/details gcc-11.1.0, arm-linux-gnueabihf.gcc.x86_64-linux • https://ci.guix.gnu.org/build/667394/details

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

bug#49337: Guix pull fails on my Talos II

Hello, Em sexta-feira, 2 de julho de 2021, às 22:36:26 -03, Chris Marusich escreveu: > FYI, I was able to successfully "guix pull" from 83f8b6d (Apr 09) to > c33e200 (Jul 02) just now on my own POWER9 machine (a Blackbird). This could be bug 48064. If it is, then it’s an intermitent problem and

bug#48064: [PATCH core-updates] build-system/texlive: Change default format to pdftex

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 consequently also the engine) to pdftex to

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

Em quinta-feira, 1 de julho de 2021, às 10:07:27 -03, Ludovic Courtès escreveu: > Yes, you need debug info for (@@ (gnu packages commencement) > glibc-final), which is not what you get when you type “glibc:debug”. > > HTH! It did, thanks for the tip! For the record, this is the command line

bug#48064: [Dev-luatex] bug#48064: texlive-* packages fail to build non-deterministically

Em quarta-feira, 30 de junho de 2021, às 08:53:41 -03, luigi scarso escreveu: > On Wed, Jun 30, 2021 at 8:20 AM Ludovic Courtès wrote: > > Hi, > > > > Ludovic Courtès skribis: > > > While investigating luatex crashes in the TeX Live 2020 package of > > > GNU Guix¹, we identified the following

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

Hello Ludo, Em 30 de junho de 2021 07:05:03 BRT, "Ludovic Courtès" escreveu: >Hi Thiago, > >FWIW I managed to get a Valgrind report for TeX Live on core-updates, >using ‘--extra-debuginfo-path’ to help it a bit: > > https://issues.guix.gnu.org/48064#6 > >Not that it helps a whole lot yet! I

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

Em quarta-feira, 30 de junho de 2021, às 09:46:01 -03, Thiago Jung Bauermann escreveu: > I will use your command line to get a Valgrind report for TeX Live 2021 > and post it to the dev-luatex mailing list as well. Unfortunately I’m still having problems with glibc debug info and thus Va

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

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 repo). The good news is that I found a simple

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

Hello, I was able to do a build of texlive-amscls with `export MALLOC_CHECK_=2`, and a core dump was generated. I managed to get a guix environment with debuginfo for texlive-bin, but for some reason it still doesn’t have debug info for glibc available. FYI, this was the command line I used: