bug#64794: Guile 3.0.9 in guix shell container with emulated FHS throws ldconfig error @ a050897

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello,

Rostislav Svoboda  writes:

> The warning appears also for guile@2.0 and later. guile@1.8 works fine:
>
> ```
> $ guix shell --emulate-fhs --container guile@1.8
> [env]$ exit
> $ guix shell --emulate-fhs --container guile@2.0
> ldconfig: /lib/libguile-2.0.so.22.8.1-gdb.scm is not an ELF file - it
> has the wrong magic bytes at the start.
>
> [env]$
> ```

The error is harmless. AFAIU ldconfig ignores the non-ELF file and
compiles the ld cache with the ELF shared libraries.

libguile-…-gdb.scm is a GDB extension file¹ that GDB auto-loads when
debugging programs using libguile.so². From the beginning of said .scm
file:

;;; Commentary:
;;;
;;; This file defines GDB extensions to pretty-print 'SCM' objects, and
;;; to walk Guile's virtual machine stack.
;;;
;;; This file is installed under a name that follows the convention that
;;; allows GDB to auto-load it anytime the user is debugging libguile
;;; (info "(gdb) objfile-gdbdotext file").

In distros using the Filesystem Hierarchy Standard, this file is
installed in GDB's data directory instead of /lib, so ldconfig doesn't
run into it. For example, in Debian/Ubuntu:

$ dpkg -L guile-3.0-dev | grep gdb.scm
/usr/share/gdb/auto-load/libguile-3.0.so.1.6.0-gdb.scm

Unfortunately, in the case of Guix the auto-load directory is in GDB's
own immutable installation directory so Guile can't put it there:

$ gdb -q
(gdb) show auto-load scripts-directory 
List of directories from which to load auto-loaded scripts is 
$debugdir:$datadir/auto-load.
(gdb) show data-directory 
GDB's data directory is 
"/gnu/store/i6x19fvlb1ladc3hcg70hnkcq6i6x232-gdb-14.2/share/gdb".

One way to improve that would be to propose a patch to upstream GDB so
that additional auto-load scripts directories could be specified via an
environment variable. Then Guile and other packages that provided GDB
extentions (such as libstdc++) could install them in their respective
/gnu/store/…-package/share/gdb/auto-load directories, and the Guix
profile could set the GDB environment variable to point to them.

-- 
Thiago

¹ https://sourceware.org/gdb/current/onlinedocs/gdb.html/Guile.html
² 
https://sourceware.org/gdb/current/onlinedocs/gdb.html/objfile_002dgdbdotext-file.html

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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.

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 cMake/FreeCAD_Helpers/SetupQt.cmake:28 
> (find_package):
>   By not providing "FindQt5WebKitWidgets.cmake" in 
>   CMAKE_MODULE_PATH this
>   project has asked CMake to find a package configuration file 
>   provided by
>   "Qt5WebKitWidgets", but CMake did not find one.
>
>   Could not find a package configuration file provided by 
>   "Qt5WebKitWidgets"
>   with any of the following names:
>
> Qt5WebKitWidgetsConfig.cmake
> qt5webkitwidgets-config.cmake
>
>   Add the installation prefix of "Qt5WebKitWidgets" to 
>   CMAKE_PREFIX_PATH or
>   set "Qt5WebKitWidgets_DIR" to a directory containing one of the 
>   above
>   files.  If "Qt5WebKitWidgets" provides a separate development 
>   package or
>   SDK, be sure it has been installed.
> Call Stack (most recent call first):
>   CMakeLists.txt:69 (include)
>
>
> -- Configuring incomplete, errors occurred!

Is this on master, or core-updates? On master, freecad-0.20.1 builds
fine on x86_64-linux, but on powerpc64le-linux it doesn't get built
because of a dependency failure:

--8<---cut here---start->8---
*** HDF-SD test fails ***
make[5]: *** [Makefile:1202: hdftest.chkexe_] Error 1
make[5]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[4]: *** [Makefile:1188: build-check-s] Error 2
make[4]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[3]: *** [Makefile:1183: test] Error 2
make[3]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[2]: *** [Makefile:999: check-am] Error 2
make[2]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[1]: *** [Makefile:428: check-recursive] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf'
make: *** [Makefile:515: check-recursive] Error 1

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("check") exit-status: 2 
term-signal: #f stop-signal: #f>
phase `check' failed after 8.3 seconds
command "make" "check" failed with status 2
builder for `/gnu/store/1szzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv' 
failed with exit code 1
build of /gnu/store/1szzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv failed
View build log at 
'/var/log/guix/drvs/1s/zzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv.gz'.
cannot build derivation 
`/gnu/store/a8df1igdk1b15x06bkk7rvyq1maqkf8v-netcdf-4.7.4.drv': 1 dependencies 
couldn't be built
applying 2 grafts for postgresql-13.7 ...
cannot build derivation 
`/gnu/store/35bapv6z5fsalaxapmhymj7m8z8yrjph-freecad-0.20.1.drv': 1 
dependencies couldn't be built
guix build: error: build of 
`/gnu/store/35bapv6z5fsalaxapmhymj7m8z8yrjph-freecad-0.20.1.drv' failed
--8<---cut here---end--->8---

Unfortunately I can't test on core-updates because of a kernel issue on
guixp9 which triggers a libaio testsuite failure, and thus most of
core-updates is unbuildable there...

-- 
Thanks
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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)> ,use(web client)
> scheme@(guile-user)> (define p (open-socket-for-uri "https://guix.gnu.org;))
> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-writable) p)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure write_wait_fd: unimplemented
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,q
> scheme@(guile-user)> ,use(gnutls)
> scheme@(guile-user)> (gnutls-version)
> $1 = "3.7.7"
> scheme@(guile-user)> ((@@ (ice-9 suspendable-ports) wait-for-readable) p)
> $2 = 1

This occasionally causes problems when fetching substitutes, as can be
seen in bug #56005 (during substitution: write_wait_fd: unimplemented).

-- 
Thanks
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 cases/23.p
FAIL: poll missed an event!
FAIL: poll missed an event!
FAIL: poll missed an event!
test cases/23.t completed FAILED.
Completed cases/23.p with 1 -- FAILED.
Pass: 18  Fail: 1  Skip: 0
Test run complete at Sun Jul 17 10:39:33 AM UTC 2022
make[1]: *** [Makefile:53: partcheck] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-libaio-0.3.113.drv-0/libaio-0.3.113/harness'
make: *** [Makefile:23: partcheck] Error 2

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("partcheck" "-j" "8" 
"prefix=/gnu/store/igbnjwlfr0mim89if6z46cqba0ny5lww-libaio-0.3.113" "CC=gcc") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 97.9 seconds
command "make" "partcheck" "-j" "8" 
"prefix=/gnu/store/igbnjwlfr0mim89if6z46cqba0ny5lww-libaio-0.3.113" "CC=gcc" 
failed with status 2
--8<---cut here---end--->8---

The header of libaio/harness/cases/23.t says:

 * Verify that aio poll doesn't miss any events.  This is a regression test for
 * kernel commit 363bee27e258 ("aio: keep poll requests on waitqueue until
 * completed")¹.

guixp9 is running kernel linux-image-5.10.0-0.bpo.8-powerpc64le version
5.10.46-4~bpo10+1. The kernel commit mentioned above was backported to
upstream stable kernel 5.10.85, which was included in Debian's
linux-image version 5.10.92-1, available in the buster-backports kernel.

So long story short, we need to update guixp9's kernel so that we can
build core-update's libaio. I suggest we take the opportunity to update
all of the Debian packages as well.

I don't have access to guixp9's console, so unfortunately I can't
perform the update. Or rather, I can if someone else reboots the machine
afterwards and fixes any boot issues that could come up (hopefully not
but it's always a possibility).

-- 
Thanks
Thiago

bug#56005: during substitution: write_wait_fd: unimplemented

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 problem so
this is what this patch does.

Note that the diff between 0.5.3 and 0.6.1 has almost 24k lines so I didn't
even try skimming it.

I did verify the tarball's signature using the maintainer's (expired) public
key that I downloaded from Savannah¹:

$ gpg --verify guile-sdl-0.6.1.tar.lz.sig 
gpg: assuming signed data in 'guile-sdl-0.6.1.tar.lz'
gpg: Signature made Sun Feb 20 21:16:09 2022 -03
gpg:using DSA key 748EA0E81CB8A7489BFA6CE4670322244C807502
gpg: Good signature from "Thien-Thi Nguyen (software signing) 
" [expired]
gpg: aka "Thien-Thi Nguyen " [expired]
gpg: aka "Thien-Thi Nguyen " [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 748E A0E8 1CB8 A748 9BFA  6CE4 6703 2224 4C80 7502

I'll send a message to the guile-sdl mailing list suggesting them to publish
a new key.

Thanks,
Thiago

¹ https://savannah.gnu.org/users/ttn

 gnu/packages/sdl.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/sdl.scm b/gnu/packages/sdl.scm
index 4c38e2f05507..49bc09312a13 100644
--- a/gnu/packages/sdl.scm
+++ b/gnu/packages/sdl.scm
@@ -541,7 +541,7 @@ (define-public sdl2-ttf
 (define-public guile-sdl
   (package
 (name "guile-sdl")
-(version "0.5.3")
+(version "0.6.1")
 (source (origin
   (method url-fetch)
   (uri
@@ -549,7 +549,7 @@ (define-public guile-sdl
   version ".tar.lz"))
   (sha256
(base32
-"040gyk3n3yp8i30ngdg97n3083g8b6laky2nlh10jqcyjdd550d6"
+"1q985nd3birr5pny74915x098fisa6llas3ijgf1b4gdz5717nzz"
 (build-system gnu-build-system)
 (native-inputs
  `(("lzip" ,lzip)

base-commit: 73761d8049f483e6685c2c736872d0366e03238a

bug#56005: exception while downloading substitutes

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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:
substitute:   14 (primitive-load 
"/gnu/store/yxh9kr0150494jf8phrf1x28mhw…")
substitute: In guix/ui.scm:
substitute:2230:7 13 (run-guix . _)
substitute:   2193:10 12 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:757:18  9 (_)
substitute:348:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:365:27  7 (lookup-narinfos/diverse _ _ # …)
substitute:322:31  6 (lookup-narinfos "https://ci.guix.gnu.org; _ # _ # _)
substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1685:16  4 (raise-exception _ #:continuable? _)
substitute:   1685:16  3 (raise-exception _ #:continuable? _)
substitute:   1780:13  2 (_ #< components: (#<> 
#<…>)
substitute:   1685:16  1 (raise-exception _ #:continuable? _)
substitute:   1685:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
substitute: In procedure write_wait_fd: unimplemented
guix package: erro: `/gnu/store/yxh9kr0150494jf8phrf1x28mhwnnv7f-guix-command 
substitute' died unexpectedly
popigai: (1) guix describe
Geração 144 15 jun 2022 22:55:58(atual)
  guix 128697d
URL do repositório: https://git.savannah.gnu.org/git/guix.git
ramo: master
commit: 128697d43c21eb229ff5413f1c4cf79ae1a9dcd4
--8<---cut here---end--->8---

I immediately ran “guix package -u” again, and this time the command
completed successfully.

I had a quick look at ‘fetch-narinfos’ but I couldn't figure out what
could be calling into this unimplemented function ‘write_wait_fd’…

-- 
Thanks
Thiago

bug#55136: keepassxc segfaults when merging databases

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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
>>> "/org/freedesktop/secrets/collection/passes/c417f89606a5463fa0746d0a5f5625ba"
>>> "Failed to register item on DBus at path
>>> '/org/freedesktop/secrets/collection/passes/c417f89606a5463fa0746d0a5f5625ba'"
>>> QObject::connect(Group, Unknown): invalid nullptr parameter
>>> QObject::connect(FdoSecrets::Item, FdoSecrets::Collection): invalid
>>> nullptr parameter QObject::connect(FdoSecrets::Item,
>>> FdoSecrets::Collection): invalid nullptr parameter [1]1425
>>> segmentation fault  keepassxc
>>> ```
>>
>> It might be advisable to try a synthetic test using two new databases
>> with some dummy entries in them, to see if it's a general problem with
>> database merging or if there's something specifically about the
>> databases you're trying to merge that's not being accepted.
>
> Keepassxc seems crashy; I tried creating a new database and it was
> crashing randomly, without any error output.

Strange, I use keepassxc regularly for a long time now and I've never
seen it crash. Though I don't do complex stuff such as merging
databases, just retrieval of users and passwords and creation of new
entries.

-- 
Thanks
Thiago

bug#53752: guix home symlink permissions

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 solution with guix system by configuring openssh directly (see
> openssh-configuration -> authorized-keys), but there really should be a
> way to do this with guix home.  (anyone that can call guix home for my
> user can see/modify my authorized_keys anyway)
> 
> Maybe this bug should be renamed to something like "guix home cannot
> configure authorized_keys"?

Good idea. I just made that change.

I don’t use Guix Home and I don’t know much about its internals, so 
unfortunately I can’t help much with this problem.

-- 
Thanks,
Thiago

bug#53752: guix home symlink permissions

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 my
> ~/.ssh/authorized_keys.  It seems the directories have reasonable
> permissions (maybe because they already existed?), but it seems like
> someone could in theory edit the symlinks in-place (though I wasn't able
> to figure that out).

In Linux, symlink permissions are meaningless. From the chmod(1) man page:

“chmod never changes the permissions of symbolic links; the chmod system 
call cannot change their permissions.  This is not a problem since the 
permissions of symbolic links are never used.  However,  for  each symbolic 
link listed on the command line, chmod changes the permissions of the 
pointed-to file.  In contrast, chmod ignores symbolic links encountered 
during recursive directory traversals.”

So AFAIK there’s nothing that guix home can do about that.
I don’t know what that implies for OpenSSH and authorized_keys, though.

-- 
Thanks,
Thiago

bug#53214: Release 1.4.0 progress

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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:
> > 
> > https://issues.guix.gnu.org/53463
> > 
> > And building the guix package does not work on aarch64, also for weeks:
> > 
> > https://issues.guix.gnu.org/52943
> 
> It does work on my aarch64 machine as of
> 1ef7a03a148cf5f83ab1820444f6bd50d8e732d1 and more recently
> f8bfb2d85682dcabe56a4b1b0f25d566a0abbd2b, but not sure why it's not
> building on the build farm...

A couple of weeks ago guixp9 wasn’t doing powerpc64le builds either.
I did a “guix pull && guix upgrade” (which upgraded the version of Cuirass 
installed) and restarted the Cuirass worker then things got back on track 
again. I don’t know why...

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 in Guix 
lately. One of his patches must have fixed your problem.

I’m closing the bug now.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU 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 know a little more about that.  What is the advantage of
> specifying the environment variables on that file instead of ~/.profile?

I don’t know if this applies to all distributions, but at least in Ubuntu, 
the GNOME on Wayland and KDE on Wayland desktop sessions are started 
without a shell being invoked at any point, so ~/.profile and related files 
don’t get evaluated.

In KDE, the way to define environment variables that will be set in the 
Wayland session is to put a shell script in ~/.config/plasma-workspace/env/.

I hadn’t figured out how to do it in GNOME when I briefly searched for it. 
This systemd override file seems to be the solution.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 attempts
at debugging what is going on, but unfortunately without arriving at an
answer.

This problem is also affecting Cuirass builds. This powerpc64le-linux build:

https://ci.guix.gnu.org/build/70/details

failed because of the intermitent TLS error:

--8<---cut here---start->8---
guix substitute: error: TLS error in procedure 'read_from_session_record_port': 
Error decoding the received TLS packet.
fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
@ substituter-failed 
/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9  fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
--8<---cut here---end--->8---

The daemon in this case is:

/gnu/store/ny30pxjzv866m3w0v1vfbzdbqi17k8wn-guix-daemon-1.3.0-21.e427593/bin/guix-daemon

From this Guix version

--8<---cut here---start->8---
guixp9: sudo -i guix describe
Generation 11   Jan 11 2022 02:07:42(current)
  guix 83abdc8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 83abdc8371d90b6d4591a69fae5585a2a99c1627
--8<---cut here---end--->8---

Not sure if this is related, but during that build Guix noticed that the 
substitute server is slow:

--8<---cut here---start->8---
Downloading 
https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9...
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9:
 server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
--8<---cut here---end--->8---

There’s bug 46942 which is specifically about ci.guix.gnu.org being slow,
and the bug reporter there also hits this same TLS error, so there’s
probably at least some correlation between this problem and the network
being slow.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 powerpc64le-linux build:

https://ci.guix.gnu.org/build/70/details

failed because of the intermitent TLS error:

--8<---cut here---start->8---
guix substitute: error: TLS error in procedure 'read_from_session_record_port': 
Error decoding the received TLS packet.
fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
@ substituter-failed 
/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9  fetching path 
`/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty 
status: '')
--8<---cut here---end--->8---

The daemon in this case is:

/gnu/store/ny30pxjzv866m3w0v1vfbzdbqi17k8wn-guix-daemon-1.3.0-21.e427593/bin/guix-daemon

From this Guix version

--8<---cut here---start->8---
guixp9: sudo -i guix describe
Generation 11   Jan 11 2022 02:07:42(current)
  guix 83abdc8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 83abdc8371d90b6d4591a69fae5585a2a99c1627
--8<---cut here---end--->8---

Not sure if this is related, but during that build Guix noticed that the 
substitute server is slow:

--8<---cut here---start->8---
Downloading 
https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9...
guix substitute: warning: while fetching 
https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9:
 server is somewhat slow
guix substitute: warning: try `--no-substitutes' if the problem persists
--8<---cut here---end--->8---

There’s bug 46942 which is specifically about ci.guix.gnu.org being slow,
and the bug reporter there also hits this same TLS error, so there’s
probably at least some correlation between this problem and the network
being slow.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 texlive package.

I was able to reproduce the problem with the texlive package installed.
Installing the package texlive-latex-luatex doesn’t help.

I can work on this issue some days after the holidays.

Pāladhammika,

Just for clarification, do you also use entire texlive package?

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 /mnt_test/var/cache.  Transfer speed was considerably
> faster (not *great*, but reasonably fast) than the copy of
> /gnu/store/trash to the same target.
>
> This confirmed our suspicions that the problem is not with the storage
> array but due to the fact that /gnu/store/trash (and also /gnu/store)
> is an extremely large, flat directory.  /var/cache is not.

There was an interesting thread in the Linux kernel mailing lists about this
very issue earlier this year:

https://lore.kernel.org/linux-fsdevel/206078.1621264...@warthog.procyon.org.uk/

I’m not sure I completely understood all of the concerns discussed there, but
my understanding of it is that for workloads which don’t concurrently modify
the huge directory, it’s size isn’t a problem for btrfs and XFS and in fact
it’s even more efficient to have one big directory rather than
subdirectories¹. It’s should also be well handled even by ext4, IIUC².

The problem for all filesystems is concurrently modifying the directory
(e.g., adding or removing files), because the kernel serializes directory
operations at the VFS layer.

Also in that case XFS can also have allocation issues when adding new files
if one isn’t careful.³

-- 
Thanks
Thiago

¹ 
https://lore.kernel.org/linux-fsdevel/20210517232237.ge2...@dread.disaster.area/
² 
https://lore.kernel.org/linux-fsdevel/6e4de257-4220-4b5b-b3d0-b67c7bc69...@dilger.ca/
³ 
https://lore.kernel.org/linux-fsdevel/20210519125743.gp2...@dread.disaster.area/

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 -- time-machine 
> --commit=6dffced09ecda024e0884e352778c221ad066fd6 -- describe
> Mise à jour du canal « guix » depuis le dépôt Git « 
> https://git.savannah.gnu.org/git/guix.git »...
>   guix 6dffced
> URL du dépôt : https://git.savannah.gnu.org/git/guix.git
> commit : 6dffced09ecda024e0884e352778c221ad066fd6
>
>
> But another commit does not work:
>
> $ guix time-machine --branch=version-1.2.0 -- time-machine --commit=6786336 
> -- describe
> Mise à jour du canal « guix » depuis le dépôt Git « 
> https://git.savannah.gnu.org/git/guix.git »...
> Backtrace:

I don’t think this is a problem specific to time-machine. I ran into what
I belive to be the same issue a couple of days ago on Ubuntu, when I was
using its Guix 1.2.0 package to pull to the current version in master:

--8<---cut here---start->8---
popigai: /usr/bin/guix --version
guix (GNU Guix) 1.2.0
Copyright (C) 2020 os autores do Guix
Licença GPLv3+: GNU GPLv3 ou posterior 
Esse é um software livre: você é livre para modificar ou redistribuí-lo.
NÃO HÁ GARANTIA, na máxima extensão permitida pela lei.
popigai: guix pull
Atualizando canal "guix" a partir do repositório Git 
"https://git.savannah.gnu.org/git/guix.git;...
Authenticating channel 'guix', commits 9edb3f6 to d627fba (28.728 new 
commits)...
Compilando a partir deste canal:
  guix  https://git.savannah.gnu.org/git/guix.git   d627fba
Backtrace:
   6 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  5 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  4 (_ #(#(#)))
In guix/ui.scm:
  2117:12  3 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9  2 (catch _ _ # …)
829:9  1 (catch _ _ # …)
829:9  0 (catch _ _ # …)

ice-9/boot-9.scm:829:9: In procedure catch:
Throw to key `match-error' with args `("match" "no matching pattern" 
(#:re-export-and-replace (delete) #:replace ((define-public* . define-public)) 
#:export (content-hash content-hash? content-hash-algorithm content-hash-value 
origin origin? this-origin origin-uri origin-method origin-hash origin-sha256 
origin-file-name origin-actual-file-name origin-patches origin-patch-flags 
origin-patch-inputs origin-patch-guile origin-snippet origin-modules base32 
base64 package package? this-package package-name package-upstream-name 
package-version package-full-name package-source package-build-system 
package-arguments package-inputs package-native-inputs 
package-propagated-inputs package-outputs package-native-search-paths 
package-search-paths package-replacement package-synopsis package-description 
package-license package-home-page package-supported-systems package-properties 
package-location package-definition-location hidden-package hidden-package? 
package-superseded deprecated-package package-field-location this-package-input 
this-package-native-input lookup-package-input lookup-package-native-input 
lookup-package-propagated-input lookup-package-direct-input prepend replace 
modify-inputs package-direct-sources package-transitive-sources 
package-direct-inputs package-transitive-inputs 
package-transitive-target-inputs package-transitive-native-inputs 
package-transitive-propagated-inputs package-transitive-native-search-paths 
package-transitive-supported-systems package-mapping package-input-rewriting 
package-input-rewriting/spec package-source-derivation package-derivation 
package-cross-derivation package-output package-grafts 
package-patched-vulnerabilities package-with-patches package-with-extra-patches 
package-with-c-toolchain package/inherit transitive-input-references 
%supported-systems %hurd-systems %cuirass-supported-systems supported-package? 
 package-error? package-error-package  
package-input-error? package-error-invalid-input 
 package-cross-build-system-error? 
package->bag bag->derivation bag-direct-inputs bag-transitive-inputs 
bag-transitive-host-inputs bag-transitive-build-inputs 
bag-transitive-target-inputs package-development-inputs package-closure 
default-guile default-guile-derivation set-guile-for-build package-file 
package->derivation package->cross-derivation origin->derivation)))'.
popigai: (1) 
--8<---cut here---end--->8---

My workaround was to first pull to the commit corresponding to v1.3.0 and
then using that version to pull to current master, which worked.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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:
> > 
> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b9
> > 5e22ced156df62cbff90184
> > 
> > but it forgot to keep in mind that nix systems != triplets.
> > Instead of %current-target-system, the 'current-target-nix-system'
> > from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
> > (or the hurd-target? procedure).
> 
> Looking more closely, I don't see an issue with the current conditional
> seleciting kmod?  nix systems != triplets, but in this case, the
> conditional is seldom dealing with nix systems, it seems.  Am I missing
> something?
> 
> *** time passes ... reads sources ***
> 
> Ah!  per (guix utils), it seems like %current-system is a nix system,
> while %current-target-system is a GNU triplet.  Confusing!

Guix’s usage of GNU triplets in some places and nix systems in others is a 
footgun. IMHO we should choose one format and use it everywhere we can, 
converting to the other if necessary...

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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.
> > 
> > Fixes https://issues.guix.gnu.org/51252.
> > 
> > * gnu/packages/tex.scm (texlive-latex-luatex): New variable.
> 
> Applied, thanks!
> 
> I don’t fully understand the issue but it looks like a reasonable and
> non-intrusive fix.

Thank you!

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 Guix)
  restricted system commands enabled.

  ---! lualatex.fmt was written by luahbtex
  (Fatal format file error; I'm stymied)user@popigai:~$

The correct way to fix this problem would be either to change texlive-bin
to make ‘lualatex’ use the LuaHBTeX engine, or to change texlive-latex-base
to generate ‘lualatex.fmt’ with LuaTeX. Both options would rebuild large
parts of the world.

Ricardo Wurmus suggested creating a new package to provide ‘lualatex.fmt’
for LuaTeX as a workaround. This is what this package does.

Fixes https://issues.guix.gnu.org/51252.

* gnu/packages/tex.scm (texlive-latex-luatex): New variable.
---

Hello,

Strictly speaking, this patch solves the problem reported in issue 51252, but
I still cannot use ‘lualatex’ because of a problem with fonts:

--8<---cut here---start->8---
user@popigai:~$ lualatex hello.tex
This is LuaTeX, Version 1.13.0 (TeX Live 2021/GNU Guix)
 restricted system commands enabled.
(./hello.tex
LaTeX2e <2020-10-01> patch level 4
 L3 programming layer <2021-02-18> 
(/home/user/.guix-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/home/user/.guix-profile/share/texmf-dist/tex/latex/base/size10.clo
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: File not 
found: "lmroman10-regular".
! Font \TU/lmr/m/n/10=[lmroman10-regular]:+tlig; at 10pt not loadable: metric 
data not found or bad.

relax
l.54 \normalsize

?
! Emergency stop.

relax
l.54 \normalsize

 307 words of node memory still in use:
   1 hlist, 1 dir, 3 kern, 1 glyph, 1 attribute, 39 glue_spec, 1 
attribute_list, 3 if_stack nodes
   avail lists: 2:7,3:3,4:1,5:1
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on hello.log.
--8<---cut here---end--->8---

This happens even though I have the packages texlive-base, texlive-lm and
texlive-fonts-latex installed in the profile. I suspect this is a problem with
luaotfload. I’ll poke at it a bit to see if I can find something out.

The reporter of 51252 doesn’t seem to hit this font issue, so perhaps this patch
will be enough for them.

In the (hopefuly) near future, I’ll submit a patch for core-updates changing
‘lualatex’ to use the LuaHBTeX engine and deprecating this package.

Thanks,
Thiago


 gnu/packages/tex.scm | 65 
 1 file changed, 65 insertions(+)

diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index 910be212ac17..256fe7da90bc 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -3746,6 +3746,71 @@ (define-public texlive-luaotfload
 
 (define-deprecated-package texlive-luatex-luaotfload texlive-luaotfload)
 
+;; FIXME: This package is a temporary workaround to provide ‘lualatex.fmt’ for
+;; the LuaTeX engine. It is needed because it was discovered too late in the
+;; core-updates-frozen cycle that texlive-latex-base only provides it for
+;; LuaHBTeX. See https://issues.guix.gnu.org/51252.
+(define-public texlive-latex-luatex
+  (package
+(name "texlive-latex-luatex")
+(version (number->string %texlive-revision))
+(source #f)
+(build-system gnu-build-system)
+(arguments
+ `(#:modules ((guix build gnu-build-system)
+  (guix build utils)
+  (ice-9 rdelim)
+  (ice-9 string-fun))
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'unpack)
+ (delete 'bootstrap)
+ (delete 'configure)
+ (delete 'check)
+ (replace 'build
+   (lambda* (#:key inputs #:allow-other-keys)
+ (mkdir "web2c")
+ (let ((fmtutil.cnf-in (open-file
+(string-append
+ (assoc-ref inputs "texlive-kpathsea")
+ "/share/texmf-dist/web2c/fmtutil.cnf")
+"r"))
+   (fmtutil.cnf-out (open-file "web2c/fmtutil.cnf" "w")))
+
+   ;; Copy ‘lualatex’ format lines to the new fmtutil.cnf, changing
+   ;; the engine from ‘luahbtex’ to ‘luatex’.
+   (do ((line "" (read-line fmtutil.cnf-in 'concat)))
+   ((eof-object? line))
+ (when (string-prefix? "lualatex" line)
+   (display (string-replace-substring line "luahbtex" "luatex")
+fmtutil.cnf-out)))
+   (close-port fmtutil.cnf-out)
+   

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

No, our cross gcc-11 builds are still hitting this issue. E.g.:

aarch64-linux-gnu.gcc.x86_64-linux:
https://ci.guix.gnu.org/build/1750690/details 

powerpc64le-linux-gnu.gcc.x86_64-linux:
https://ci.guix.gnu.org/build/1750748/details

riscv64-linux-gnu.gcc.x86_64-linux:
https://ci.guix.gnu.org/build/1750777/details

Though I haven’t worked on this issue since I last reported on it.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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, and
> then we run fmtutil-sys on the patched file.
> The cause for trouble lies in texlive-kpathsea, which provides
> share/texmf-dist/web2c/fmtutil.cnf
> .  That file states how to build the various fmt files.
> 
> The file in the earlier version of Tex Live contains this line for the
> lualatex format:
> 
> lualatex luatex language.dat,language.dat.lua lualatex.ini
> 
> the new file (on core-updates-frozen) says this:
> 
> lualatex luahbtex language.dat,language.dat.lua lualatex.ini
> 
> i.e. it will try to build the lualatex fmt file with luahbtex
> instead of luatex.

Thank you for this analysis!

> I suppose at this point in the build we don’t
> actually have a working luahbtex, so fmtutil-sys doesn’t generate
> the correct lualatex.fmt.

Looking at the build log of ‘texlive-latex-base’ from the core-updates-
frozen branch, LuaHBTeX seems to be functional at the time it is used to 
generate ‘lualatex.fmt’. Comparing it to the build log of the same package 
on master, there are some differences though:

• core-updates-frozen shows the following messages:
  • “No file TS1lmr.fd.”
  • “No file latex2e-first-aid-for-external-files.ltx.”
• core-updates-frozen lists some fonts with strange names and sizes:
  • \font\c__fp_exp_intarray=cmr10 at 0.2pt
  • \font\c__fp_trig_intarray=cmr10 at 0.3pt
  • \font\g__regex_state_active_intarray=cmr10 at 0.5pt
  • \font\g__regex_thread_info_intarray=cmr10 at 0.6pt
  • \font\g__regex_submatch_prev_intarray=cmr10 at 0.8pt
  • \font\g__regex_submatch_begin_intarray=cmr10 at 0.9pt
  • \font\g__regex_submatch_end_intarray=cmr10 at 0.0001pt
  • \font\g__regex_balance_intarray=cmr10 at 0.00012pt
• master instals file at web2c/luatex/lualatex.fmt, while
  core-updates-frozen installs it at web2c/luahbtex/lualatex.fmt.

This last difference coupled with the following excerpt from the TexLive 
news section¹:

  “LuaTeX: Integration with HarfBuzz library, available as new engines 
   luahbtex (used for lualatex) and luajithbtex.”

suggests that the command ‘lualatex’ is supposed to invoke the LuaHBTeX
engine rather than the LuaTeX engine. Indeed, when using LuaHBTeX
explicitly, there’s no error about the format file. Unfortunately, there’s an
error about font loading:

--8<---cut here---start->8---
popigai ⸤env⸥: luahbtex '' hello.tex
This is LuaHBTeX, Version 1.13.0 (TeX Live 2021/GNU Guix) 
 restricted system commands enabled.
(./hello.tex
LaTeX2e <2020-10-01> patch level 4
 L3 programming layer <2021-02-18> 
(/gnu/store/nx4jih5xnm6hzfgvi04w4wkp4pbma8bm-profile/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/nx4jih5xnm6hzfgvi04w4wkp4pbma8bm-profile/share/texmf-dist/tex/latex/base/size10.clo
luaotfload | db : Font names database not found, generating new one.
luaotfload | db : This can take several minutes; please be patient.
luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: File not 
found: "lmroman10-regular".
! Font \TU/lmr/m/n/10=[lmroman10-regular]:+tlig; at 10pt not loadable: metric 
data not found or bad.
 
relax 
l.54 \normalsize
  
? 
--8<---cut here---end--->8---

I tried running `luaotfload-tool --update` as suggested on the interwebs
for a similar problem, but I ran into a separate issue with that tool:

--8<---cut here---start->8---
popigai ⸤env⸥: luaotfload-tool --update
...ih5xnm6hzfgvi04w4wkp4pbma8bm-profile/bin/luaotfload-tool:183: module 
'alt_getopt' not found:
no field package.preload['alt_getopt']
[kpse lua searcher] file not found: 'alt_getopt'
[kpse C searcher] file not found: 'alt_getopt'
popigai ⸤env⸥: 
--8<---cut here---end--->8---

-- 
Thanks,
Thiago

¹ https://tug.org/texlive/doc/texlive-en/texlive-en.html#news

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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? Does the problem still happen on core-updates-frozen?

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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:
> > 
> > $ guix build --check \
> > 
> > -e '(@@ (gnu packages commencement) gcc-core-mesboot1)’
> > ⋮
> > 
> > guix build: erro: derivation
> > `/gnu/store/qbnxfv7v7288iisl44kccz68k0pv9qdi-gcc-core-mesboot1-4.6.4.d
> > rv' may not be deterministic: output
> > `/gnu/store/rn3qvn67nraicabvlrx1rhw6nsjrpgpx-gcc-core-mesboot1-4.6.4'
> > differs
> 
> This was discussed in .  There’s the
> beginning of a patch there that needs to be adapted to avoid depending
> on xz at this early stage, I think.

Thank you for mentioning that discussion. I should have found that before 
filing this issue. Sorry for the duplicate  report.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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-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 43513 and 43591): dover and overdrive1.
> > 
> > It also uses half of the x86_64 builders (hydra-guix-*) for emulated
> > builds of aarch64 and armhf, as can be seen here:
> > 
> > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berli
> > n-nodes.scm#n143
> Thanks for the explanation.  Is there a way to tell CI (or Guix itself)
> that certain packages shouldn't be built under emulation?

I don’t know. That would certainly be useful, though.

To be honest, my experience in the past couple of months with emulated 
builds for powerpc64le-linux wasn’t good, so I asked for it to be turned 
off.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 
43513 and 43591): dover and overdrive1.

It also uses half of the x86_64 builders (hydra-guix-*) for emulated builds 
of aarch64 and armhf, as can be seen here:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin-nodes.scm#n143

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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: derivation 
`/gnu/store/qbnxfv7v7288iisl44kccz68k0pv9qdi-gcc-core-mesboot1-4.6.4.drv' may 
not be deterministic: output 
`/gnu/store/rn3qvn67nraicabvlrx1rhw6nsjrpgpx-gcc-core-mesboot1-4.6.4' differs
--8<---cut here---end--->8---

During the stripping phase, there are many of these warnings, which may be
related:

--8<---cut here---start->8---
starting phase `strip'
stripping binaries in 
"/gnu/store/rn3qvn67nraicabvlrx1rhw6nsjrpgpx-gcc-core-mesboot1-4.6.4/lib" with 
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
strip: unrecognized option `--enable-deterministic-archives'
Usage: strip  in-file(s)
 Removes symbols and sections from files
 The options are:
  -I --input-target=  Assume input file is in format 
  -O --output-target= Create an output file in format 
  -F --target=Set both input and output format to 
  -p --preserve-dates  Copy modified/access timestamps to the output
  -R --remove-section=   Remove section  from the output
  -s --strip-all   Remove all symbol and relocation information
  -g -S -d --strip-debug   Remove all debugging symbols
 --strip-unneeded  Remove all symbols not needed by relocations
  -N --strip-symbol= Do not copy symbol 
  -K --keep-symbol=  Only copy symbol 
  -x --discard-all Remove all non-global symbols
  -X --discard-locals  Remove any compiler-generated symbols
  -v --verbose List all object files modified
  -V --version Display this program's version number
  -h --helpDisplay this output
 --infoList object formats & architectures supported
  -o Place stripped output into 
strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little 
elf32-big srec symbolsrec tekhex binary ihex trad-core
--8<---cut here---end--->8---

-- 
Thanks,
Thiago


¹ commit eb0abba3877c0caeac24d0f9c71f31420dba8d6b
² commit a3fc64e4f159b601c18d091713f9c76c01b010aa

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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
gcc-4.8-fix-build-with-newer-gcc.patch.
* gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add new file.
---

Hi,

This is the patch I mentioned in my previous email. Despite the subject
and the name of the patch file, this change is necessary but unfortunately
not sufficient to make GCC 4.8 build with GCC 6 or later.

This patch solves the same problem as gcc-4-compile-with-gcc-5.patch and
gcc-4.6-gnu-inline.patch (which are actually the exact same patch).

Regards,
Thiago

 gnu/local.mk  |   1 +
 gnu/packages/gcc.scm  |   4 +-
 .../gcc-4.8-fix-build-with-newer-gcc.patch| 181 ++
 3 files changed, 185 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 61ac39618a73..663f48f1833c 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1059,6 +1059,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/gcc-cross-environment-variables.patch   \
   %D%/packages/patches/gcc-fix-texi2pod.patch  \
   %D%/packages/patches/gcc-4.8-libsanitizer-fix.patch  \
+  %D%/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch  \
   %D%/packages/patches/gcc-4.9-libsanitizer-fix.patch  \
   %D%/packages/patches/gcc-4.9-libsanitizer-ustat.patch\
   %D%/packages/patches/gcc-libsanitizer-ustat.patch\
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 2fe30b13210e..586673042a1c 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -383,7 +383,9 @@ Go.  It also includes runtime support libraries for these 
languages.")
   (patches (search-patches "gcc-arm-link-spec-fix.patch"
"gcc-4.8-libsanitizer-fix.patch"
"gcc-asan-missing-include.patch"
-   "gcc-fix-texi2pod.patch"))
+   "gcc-fix-texi2pod.patch"
+   ;; See 
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-02/msg01409.html
+   
"gcc-4.8-fix-build-with-newer-gcc.patch"))
   (modules '((guix build utils)))
   ;; This is required for building with glibc-2.26.
   ;; https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712
diff --git a/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch 
b/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch
new file mode 100644
index ..e2fe2af03d08
--- /dev/null
+++ b/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch
@@ -0,0 +1,181 @@
+From 4c212bc2507fc8ab8caba7c5afc1257707572c45 Mon Sep 17 00:00:00 2001
+From: Bernd Edlinger 
+Date: Thu, 25 Feb 2016 15:36:41 +
+Subject: [PATCH] backport: Make-lang.in: Invoke gperf with -L C++.
+
+2016-02-25  Bernd Edlinger  
+
+Backported from mainline
+2016-02-19  Jakub Jelinek  
+Bernd Edlinger  
+
+* Make-lang.in: Invoke gperf with -L C++.
+* cfns.gperf: Remove prototypes for hash and libc_name_p
+inlines.
+* cfns.h: Regenerated.
+* except.c (nothrow_libfn_p): Adjust.
+
+From-SVN: r233721
+---
+
+Obtained from:
+
+https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=4c212bc2507fc8ab8caba7c5afc1257707572c45
+
+The gcc/cp/ChangeLog hunk was modified to apply on top of gcc-4.8's 
gcc/cp/ChangeLog.
+
+ gcc/cp/ChangeLog| 12 
+ gcc/cp/Make-lang.in |  2 +-
+ gcc/cp/cfns.gperf   | 10 ++
+ gcc/cp/cfns.h   | 41 ++---
+ gcc/cp/except.c |  3 ++-
+ 5 files changed, 31 insertions(+), 37 deletions(-)
+
+diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
+index 02776465da7..8d014bef83c 100644
+--- a/gcc/cp/ChangeLog
 b/gcc/cp/ChangeLog
+@@ -1,3 +1,15 @@
++2016-02-25  Bernd Edlinger  
++
++  Backported from mainline
++  2016-02-19  Jakub Jelinek  
++  Bernd Edlinger  
++
++  * Make-lang.in: Invoke gperf with -L C++.
++  * cfns.gperf: Remove prototypes for hash and libc_name_p
++  inlines.
++  * cfns.h: Regenerated.
++  * except.c (nothrow_libfn_p): Adjust.
++
+ 2015-06-23  Release Manager
+ 
+   * GCC 4.8.5 released.
+diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
+index bd1c1d78f88..a0ea0d48359 100644
+--- a/gcc/cp/Make-lang.in
 b/gcc/cp/Make-lang.in
+@@ -111,7 +111,7 @@ else
+ # deleting the $(srcdir)/cp/cfns.h file.
+ $(srcdir)/cp/cfns.h:
+ endif
+-  gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
++  

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 ../../gcc-4.8.5/gcc/cp/except.c:1008:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ 
redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ 
previously declared here
--8<---cut here---end--->8---

by backporting a patch from GCC 4.9 (which I will send in the next email),
but then I hit another failure:

--8<---cut here---start->8---
In file included from 
/tmp/guix-build-gcc-4.8.5.drv-0/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:72:0,
 from ../../../../gcc-4.8.5/libstdc++-v3/libsupc++/del_op.cc:38:
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:38:12:
 error: ‘std::abort’ has not been declared
 using std::abort;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:39:12:
 error: ‘std::atexit’ has not been declared
 using std::atexit;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:40:12:
 error: ‘std::exit’ has not been declared
 using std::exit;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:51:12:
 error: ‘std::div_t’ has not been declared
 using std::div_t;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:52:12:
 error: ‘std::ldiv_t’ has not been declared
 using std::ldiv_t;
^
⋮
--8<---cut here---end--->8---

and so on, for several `std::` functions. Unlike the other old GCC build
failures I’ve investigated recently, I couldn’t find anyone else hitting
this specific problem. So we would have to create our own patch to fix it.

This message from Jakub Jelinek about a similar error in some unspecified
package:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Q2U4JFUB5RL7DU2XJZ4BDTRE4PVULOMG/

makes me think that there’s something in GCC 4.8’s libstdc++ (probably
in libsupc++) doing something wrong with  which trips GCC 6
and later.

However, I don’t think it’s worth making GCC 4.8 build again. It’s not
supported upstream anymore and if it’s needed in some bootstrap path,
it’s better to move it to ‘(gnu packages commencement)’ instead. In that
case, instead of fixing this build issue it’s likely better to just build
it with a GCC older than version 6.

Is it needed for bootstrap though? The definition of ‘%bootstrap-gcc’
suggests that it’s needed at least for armhf-linux but since aarch64-linux,
powerpc64le-linux and even i586-hurd use GCC 5.5, I suspect it would also
work for armhf-linux as well.

Therefore, my suggestion is to simply remove gcc-4.8.

-- 
Thanks,
Thiago

bug#49815: Upcoming timekeeping failure in gpsd

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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
> >   
> > (lambda* (#:key outputs #:allow-other-keys)
> > 
> > + (setenv "TAR" "noop")
> > 
> >   (substitute* "SConstruct"
> 
>   ^ Should be "SConscript"
> 
> This fixes the build.

Nice!

> > (("envs = \\{\\}")
> >  "envs = os.environ"))

IIUC this takes care of propagating $C_INCLUDE_PATH to gcc. I should have 
noticed it before. :facepalm:

> Hope that helps!

Thank you!

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 your patch using this one.

Thanks,
Thiago


 guix/build/scons-build-system.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/guix/build/scons-build-system.scm 
b/guix/build/scons-build-system.scm
index 17a0b7b877e6..fa422c41a172 100644
--- a/guix/build/scons-build-system.scm
+++ b/guix/build/scons-build-system.scm
@@ -20,6 +20,7 @@
 (define-module (guix build scons-build-system)
   #:use-module ((guix build gnu-build-system) #:prefix gnu:)
   #:use-module (guix build utils)
+  #:use-module (srfi srfi-26)
   #:export (%standard-phases
 scons-build))
 
@@ -32,6 +33,10 @@
 (define* (build #:key outputs (build-targets '()) (scons-flags '()) 
(parallel-build? #t) #:allow-other-keys)
   (let ((out (assoc-ref outputs "out")))
 (mkdir-p out)
+;; SCons expects the include path in $CPPPATH, so copy from
+;; $C_INCLUDE_PATH.
+(let ((c-include-path (getenv "C_INCLUDE_PATH")))
+  (and=> c-include-path (cut setenv "CPPPATH" <>)))
 (apply invoke "scons"
(append (if parallel-build?
(list "-j" (number->string

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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) coreutils-final)'

On the core-updates-frozen branch at the following commit:

1685128e6e11 gnu: mesa-opencl, mesa-opencl-icd: Build all the LLVM targets 
again.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 information, the first version of the patch to update 
Mesa provided in issue 49339 enabled libglvnd, and there’s some discussion 
about it in the ensuing messages.

The Mesa updat patch that was committed doesn’t enable libglvnd, and it was 
decided to address that change separately.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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, because of two testsuite 
failures:


   GNU coreutils 8.32: ./tests/test-suite.log


# TOTAL: 620
# PASS:  408
# SKIP:  210
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

The failures are:

FAIL: tests/misc/env-signal-handler
FAIL: tests/misc/timeout

In both of them, the problem is the same: the test expects the ‘timeout’ 
utility to print the name of the signal that is being sent, but for some 
reason it only prints the first letter of the name. E.g.:

+ diff -u exp-err6 err6
--- exp-err62021-07-26 19:00:08.159279146 +
+++ err62021-07-26 19:00:08.475277881 +
@@ -1,2 +1,2 @@
-timeout: sending signal INT to command 'env'
-timeout: sending signal KILL to command 'env'
+timeout: sending signal I to command 'env'
+timeout: sending signal K to command 'env'

It’s interesting that this works as expected with the ‘coreutils-boot0’ 
package.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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---
> > 
> > (gdb) run
> > 
> > Starting program:
> > /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest
> > 
> > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not
> > found (required by ../src/libfaketime.so.1) /bin/sh:
> > /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found
> > (required by
> > /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.
> > so.0)
> Are you using Guix on a foreign distro? This line looks like your
> distro's normal libc.so was being used and it was from glibc-2.31 or
> older.

GDB uses the shell to launch the debugged program. That is probably where
‘/bin/sh’ is entering the picture here. I don’t know whether that has any 
relation to your foreign distro’s libc being used.

The output of `help run` in GDB mentions that the shell is specified by the 
‘$SHELL’ environment variable. Perhaps you have that set?

One way to see if this is the problem is to use the GDB command
`set startup-with-shell off` to make it launch the debugged program without 
the shell.

> The x86-64 systems I have that run pure Guix don't have any
> /lib*/ directories. You might try running gdb with
> LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/l
> ib to have the Guix libc.so picked up before the other one. HTH

Another alternative worth trying is the ‘--container’ option to ‘guix 
environment’, to completely isolate GDB from the foreign distro. You might 
want to add the coreutils package to the ‘--ad-hoc’ list so that you can 
get amenities such as an ls command. :-)

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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

```
$ git diff releases/gcc-11.1.0..origin/releases/gcc-11 \
> gcc-11-branch-update.patch
```

At the time, origin/releases/gcc-11 was:

419201f566bb libstdc++: Use function object for __decay_copy helper

Unfortunately it didn’t make a difference.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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
  gcc-11.1.0, aarch64-linux-gnu.gcc.x86_64-linux
• https://ci.guix.gnu.org/build/667452/details
  gcc-11.1.0, powerpc64le-linux-gnu.gcc.x86_64-linux
• https://ci.guix.gnu.org/build/667481/details
  gcc-11.1.0, riscv64-linux-gnu.gcc.x86_64-linux
• https://ci.guix.gnu.org/build/667336/details
  gcc-11.1.0, mips64el-linux-gnu.gcc.x86_64-linux
• https://ci.guix.gnu.org/build/667423/details
  gcc-11.1.0, powerpc-linux-gnu.gcc.x86_64-linux

They all fail with a similar error:

--8<---cut here---start->8---
⋮
In file included from 
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/bits/move.h:57,
 from 
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/bits/nested_exception.h:40,
 from 
../../../../gcc-11.1.0/libstdc++-v3/libsupc++/exception:148,
 from 
../../../../gcc-11.1.0/libstdc++-v3/libsupc++/eh_exception.cc:26:
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/type_traits:971:25:
 error: there are no arguments to ?__is_nothrow_constructible? that depend on a 
template parameter, so a declaration of ?__is_nothrow_constructible? must be 
available [-fpermissive]
  971 |   = __bool_constant<__is_nothrow_constructible(_Tp, _Args...)>;
  | ^~
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/type_traits:971:25:
 note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the 
use of an undeclared name is deprecated)
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/type_traits:971:66:
 error: template argument 1 is invalid
  971 |   = __bool_constant<__is_nothrow_constructible(_Tp, _Args...)>;
  |  ^
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/type_traits:976:45:
 error: expected template-name before ?::type
  | ^
/tmp/guix-build-gcc-11.1.0.drv-0/build/arm-linux-gnueabihf/libstdc++-v3/include/type_traits:976:45:
 error: expected ?{? before ?8---

In addition to that, arm-linux-gnueabihf.gcc.x86_64-linux has the following
error which doesn’t appear on the other arches:

no include path in which to search for stdc-predef.h

As a side note, gcc-11.1.0 also fails to build on
i586-pc-gnu.gcc.x86_64-linux¹, but with a very different error message,
so it appears to be an unrelated problem.

gcc-8.5.0 also fails to cross-compile on several arches, but with a
different error message as well, so it also appears to be a separate
problem.

-- 
Thanks,
Thiago

¹ https://ci.guix.gnu.org/build/667510/details

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 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 avoid the issue.
> > 
> > * guix/build-system/texlive.scm (texlive-build): Change default value
> > of
> > the ‘tex-format’ key parameter to “pdftex”.
> 
> Pushed as 04f9f9158da348e8299e9ab90ec389ba81be46b0 with the text above
> inlined as a FIXME comment.

Thank you!

> On IRC there were concerns about Unicode support, which LuaTeX provides
> but pdftex doesn’t (IIUC), but it would seem that the worst that can
> happen is that documentation of the packages themselves would be
> mangled, which is okay.

I chose pdfTeX for the workaround because it’s the direct “predecessor” to 
LuaTeX, so I thought it would behave most similarly to it. But it’s just an 
uneducated guess.

Searching around a bit¹²³, XeTeX also has native Unicode support, so we 
could also switch to it. Either as the default, or for specific packages 
that need it.

NB: I last used TeX more than 15 years ago, and even then just lightly and 
sporadically. Don’t trust my judgement on TeX-related issues. :-)

> Anyway, it’d be ideal to get feedback from the LuaTeX folks!

Agreed!

-- 
Thanks,
Thiago

¹ 
https://tex.stackexchange.com/questions/13593/the-differences-between-tex-engines
² 
https://tex.stackexchange.com/questions/36/differences-between-luatex-context-and-xetex
³ https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#x1-120002.4

bug#49337: Guix pull fails on my Talos II

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 
running `guix pull` again has a good chance of succeeding.

Similarly, if `guix pull` succeeds then running `guix build --check 
texlive-latex-amsmath` a few times will eventually fail.

There’s a patch to work around the problem at the end of that bug report.
-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 avoid the issue.

* guix/build-system/texlive.scm (texlive-build): Change default value of
the ‘tex-format’ key parameter to “pdftex”.
---
 guix/build-system/texlive.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hello,

Originally I had a bigger patch which changed packages individually to
build with pdfTeX, because I thought the bug in LuaTeX was triggered only
by specific packages. As I changed more and more packages though, I
realized that any package can trigger the problem and the heap corruption
happens at random.

Therefore, to work around the LuaTeX bug we need to build all packages with
pdfTeX. I tested the patch with this script:

--8<---cut here---start->8---
#!/bin/bash

set -e

LOG_FILE="$1"
ROUNDS=$2

function verify_package() {
local package="$1"
local log_file="$2"

if ! guix build "$package"; then
echo "failure while building $package" >> "$log_file"
return
fi

echo "success while building $package" >> "$log_file"

if ! guix build --check --rounds=$ROUNDS "$package"; then
echo "failure while checking $package" >> "$log_file"
return
fi

echo "success while checking $package" >> "$log_file"

return
}

guix describe >> "$LOG_FILE"
echo rounds = "$ROUNDS" >> "$LOG_FILE"
echo >> "$LOG_FILE"

for package in $(guix package --list-available='^texlive' | cut -f1)
do
verify_package $package "$LOG_FILE"
done
--8<---cut here---end--->8---

and called it with `./verify-texlive-packages.sh verify-packages.log 5`.

I see some packages fail during `guix build --check` because they don't
build deterministically for some reason (which is a separate problem), but
I don't see any package failing to build anymore.

diff --git a/guix/build-system/texlive.scm b/guix/build-system/texlive.scm
index 0efa139fc124..00a36d5862d4 100644
--- a/guix/build-system/texlive.scm
+++ b/guix/build-system/texlive.scm
@@ -128,7 +128,7 @@ level package ID."
 (tests? #f)
 tex-directory
 (build-targets #f)
-(tex-format "luatex")
+(tex-format "pdftex")
 (phases '(@ (guix build texlive-build-system)
 %standard-phases))
 (outputs '("out"))

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 that 
worked for me:

$ guix environment texlive-amscls --pure\
--with-debug-info=texlive-bin   \
--ad-hoc\
-e '(list (@@ (gnu packages commencement) glibc-final) “debug”)’  \
valgrind gdb

Then I pointed valgrind at the /lib/debug directory in the environment’s 
profile, as seen in my previous message.

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 heap corruption reported by
> > 
> > > Valgrind (this is on GNU/Linux, with glibc 2.33):
> > This time with debug info for luatex:
> Thank you for the report, I will check asap.

Thanks! I was able to run Valgrind on LuaTeX 1.13.0, which is the latest 
one in TeX Live 2021.

The invalid reads and writes don’t happen on every run. I had to re-run the 
command 3 or 4 times until I got the result below (which matches our 
experience with the build failures in Guix packages)

-- 
Thanks,
Thiago


$ valgrind 
--extra-debuginfo-path=/gnu/store/rkhx3pj1qi7fx6pi9p2cg2sb9zn59qmg-profile/lib/debug
 luatex amsclass.ins
==239904== Memcheck, a memory error detector
==239904== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==239904== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==239904== Command: luatex amsclass.ins
==239904==
This is LuaTeX, Version 1.13.0 (TeX Live 2021)
 restricted system commands enabled.
==239904== Invalid write of size 8
==239904==at 0x4860691: lua_pushlstring (lapi.c:483)
==239904==by 0x56A963: load_hyphenation (texlang.c:306)
==239904==by 0x56D0CC: undump_one_language (texlang.c:1277)
==239904==by 0x56D0CC: undump_language_data (texlang.c:1290)
==239904==by 0x4E0D7F: load_fmt_file (dumpdata.c:520)
==239904==by 0x4F03DD: main_body (mainbody.c:540)
==239904==by 0x45118D: main (luatex.c:609)
==239904==  Address 0x894aa30 is 0 bytes after a block of size 1,184 alloc'd
==239904==at 0x484242B: realloc (in 
/gnu/store/a4xjjppiw7x0vgd2jimmzssj9i22jf5f-valgrind-3.17.0/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==239904==by 0x466BCD: my_luaalloc (luastuff.c:115)
==239904==by 0x48719C2: luaM_realloc_ (lmem.c:86)
==239904==by 0x486A122: luaD_reallocstack (ldo.c:182)
==239904==by 0x486CC17: traversethread (lgc.c:549)
==239904==by 0x486CC17: propagatemark (lgc.c:588)
==239904==by 0x486CFFF: singlestep (lgc.c:1057)
==239904==by 0x486D8BB: luaC_step (lgc.c:1137)
==239904==by 0x48606BB: lua_pushlstring (lapi.c:485)
==239904==by 0x56A963: load_hyphenation (texlang.c:306)
==239904==by 0x56D0CC: undump_one_language (texlang.c:1277)
==239904==by 0x56D0CC: undump_language_data (texlang.c:1290)
==239904==by 0x4E0D7F: load_fmt_file (dumpdata.c:520)
==239904==by 0x4F03DD: main_body (mainbody.c:540)
==239904==
==239904== Invalid write of size 4
==239904==at 0x48606A2: lua_pushlstring (lapi.c:483)
==239904==by 0x56A963: load_hyphenation (texlang.c:306)
==239904==by 0x56D0CC: undump_one_language (texlang.c:1277)
==239904==by 0x56D0CC: undump_language_data (texlang.c:1290)
==239904==by 0x4E0D7F: load_fmt_file (dumpdata.c:520)
==239904==by 0x4F03DD: main_body (mainbody.c:540)
==239904==by 0x45118D: main (luatex.c:609)
==239904==  Address 0x894aa38 is 8 bytes after a block of size 1,184 alloc'd
==239904==at 0x484242B: realloc (in 
/gnu/store/a4xjjppiw7x0vgd2jimmzssj9i22jf5f-valgrind-3.17.0/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==239904==by 0x466BCD: my_luaalloc (luastuff.c:115)
==239904==by 0x48719C2: luaM_realloc_ (lmem.c:86)
==239904==by 0x486A122: luaD_reallocstack (ldo.c:182)
==239904==by 0x486CC17: traversethread (lgc.c:549)
==239904==by 0x486CC17: propagatemark (lgc.c:588)
==239904==by 0x486CFFF: singlestep (lgc.c:1057)
==239904==by 0x486D8BB: luaC_step (lgc.c:1137)
==239904==by 0x48606BB: lua_pushlstring (lapi.c:485)
==239904==by 0x56A963: load_hyphenation (texlang.c:306)
==239904==by 0x56D0CC: undump_one_language (texlang.c:1277)
==239904==by 0x56D0CC: undump_language_data (texlang.c:1290)
==239904==by 0x4E0D7F: load_fmt_file (dumpdata.c:520)
==239904==by 0x4F03DD: main_body (mainbody.c:540)
==239904==
==239904== Invalid read of size 16
==239904==at 0x4861269: lua_rawset (lapi.c:809)
==239904==by 0x56A974: load_hyphenation (texlang.c:307)
==239904==by 0x56D0CC: undump_one_language (texlang.c:1277)
==239904==by 0x56D0CC: undump_language_data (texlang.c:1290)
==239904==by 0x4E0D7F: load_fmt_file (dumpdata.c:520)
==239904==by 0x4F03DD: main_body (mainbody.c:540)
==239904==by 0x45118D: main (luatex.c:609)
==239904==  Address 0x894aa30 is 0 bytes after a block of size 1,184 alloc'd
==239904==at 0x484242B: realloc (in 
/gnu/store/a4xjjppiw7x0vgd2jimmzssj9i22jf5f-valgrind-3.17.0/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==239904==by 0x466BCD: my_luaalloc (luastuff.c:115)
==239904==by 0x48719C2: luaM_realloc_ (lmem.c:86)
==239904==by 0x486A122: luaD_reallocstack (ldo.c:182)
==239904==by 0x486CC17: traversethread (lgc.c:549)
==239904==by 

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 saw it, but after I posted my message above. Thank you!

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.

-- 
Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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
Valgrind doesn’t work for me.

When I use this command:

$ guix environment texlive-amscls --pure\
--with-debug-info=texlive-bin   \
--ad-hoc valgrind glibc:debug gdb 

I get luatex linked with this glibc:

$ /bin/which luatex
/gnu/store/s44lh4hqbklplqm3cpaih3rxsv8i1dx1-profile/bin/luatex
$ ldd /gnu/store/s44lh4hqbklplqm3cpaih3rxsv8i1dx1-profile/bin/luatex | grep 
libc.so
libc.so.6 => 
/gnu/store/rhlm1nixi98x09xbyjc4i38gl9xs01f2-glibc-2.33/lib/libc.so.6 
(0x7fec0ac3d000)

But for some reason I get debug info for a different glibc:

$ ls -1 /gnu/store/s44lh4hqbklplqm3cpaih3rxsv8i1dx1-profile/lib/debug/gnu/store/
5ahv6zfv64jm5y7sficll0k2scr7cxvz-glibc-2.33
d9r40z2klf9l25pjk9k71z3dvxrsifzs-glibc-2.33-static

-- 
Thanks,
Thiago

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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 workaround: use pdftex instead of 
luatex to build the affected packages. I am currently building all packages 
matching ‘^texlive’ a few times to find the ones needing this workaround.
So far, I found these:

• texlive-amsfonts
• texlive-amscls
• texlive-babel
• texlive-babel-swedish
• texlive-latex-amsmath
• texlive-generic-babel-english
• texlive-latex-cyrillic
• texlive-latex-graphics
• texlive-latex-tools

I will submit a patch to the guix-patches mailing list (with this bug in 
Cc:) as soon as the process finishes.

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

[Thiago Jung Bauermann via Bug reports for GNU Guix]

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:

$ guix environment texlive-amscls --with-debug-info=texlive-bin \
--ad-hoc valgrind gdb glibc:debug

Valgrind isn’t working because of the lack of glibc debug info, but I was 
able to get the backtrace below from the core file, using GDB. I am yet to
analyse it and see if it provides any clue:

Core was generated by `luatex amsclass.ins'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f50ad3d5a7a in raise () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
(gdb) backtrace
#0  0x7f50ad3d5a7a in raise () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
#1  0x7f50ad3c0523 in abort () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
#2  0x7f50ad415d28 in ?? () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
#3  0x7f50ad41d54a in ?? () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
#4  0x7f50ad421bd7 in ?? () from 
/gnu/store/vp1q2ymbfzr52zxqs5z3r3nd0yprbg7h-glibc-2.33/lib/libc.so.6
#5  0x00486c7e in my_luaalloc (ud=, ptr=, 
osize=1104, nsize=)
at ../../../texlive-20190410-source/texk/web2c/luatexdir/lua/luastuff.c:115
#6  0x7f50ad754b81 in luaM_realloc_ (L=L@entry=0x12212a8, 
block=block@entry=0x1316cc0,
osize=osize@entry=1104, nsize=nsize@entry=2208)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lmem.c:86
#7  0x7f50ad74d8b3 in luaD_reallocstack (L=0x12212a8, newsize=138)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:182
#8  0x7f50ad74e121 in luaD_precall (L=L@entry=0x12212a8, func=, nresults=0)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:424
#9  0x7f50ad74e393 in luaD_precall (nresults=, 
func=, L=0x12212a8)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:413
#10 luaD_call (L=L@entry=0x12212a8, func=, nResults=)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:498
#11 0x7f50ad74e3f1 in luaD_callnoyield (L=0x12212a8, func=, 
nResults=)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:509
#12 0x7f50ad74d83f in luaD_rawrunprotected (L=L@entry=0x12212a8, 
f=f@entry=0x7f50ad74f6d0 ,
ud=ud@entry=0x0) at 
../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:142
#13 0x7f50ad74e6fb in luaD_pcall (L=L@entry=0x12212a8, 
func=func@entry=0x7f50ad74f6d0 ,
u=u@entry=0x0, old_top=1200, ef=ef@entry=0)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/ldo.c:729
#14 0x7f50ad74f5dd in GCTM (L=L@entry=0x12212a8, 
propagateerrors=propagateerrors@entry=0)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lgc.c:823
#15 0x7f50ad750eca in callallpendingfinalizers (L=)
--Type  for more, q to quit, c to continue without paging--
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lgc.c:862
#16 luaC_freeallobjects (L=L@entry=0x12212a8)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lgc.c:971
#17 0x7f50ad75a93e in close_state (L=0x12212a8)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lstate.c:245
#18 0x7f50ad75ae20 in lua_close (L=)
at ../../../texlive-20190410-source/libs/lua53/lua53-src/src/lstate.c:344
#19 0x004999a6 in do_final_end ()
at ../../../texlive-20190410-source/texk/web2c/luatexdir/tex/errors.c:257
#20 0x0044ea9e in main (ac=, av=)
at ../../../texlive-20190410-source/texk/web2c/luatexdir/luatex.c:609
(gdb)
-- 
Thanks,
Thiago