bug#60026: Failed to compute derivation bug
Simon Tournier writes: > For the record -- maybe next time :-) -- for closing, you need to > append -done to the bug number in the email address; as in > <60026-d...@debbugs.gnu.org>. Good to know! Thank you :) Joseph
bug#60200: Incompatibilities between gcc-toolchain and R packages
Hi Lars,
On Mon, 19 Dec 2022 at 13:00, Lars-Dominik Braun wrote:
> $ guix shell r-brms r make sed gcc-toolchain bash -C --no-cwd --share=/tmp
> $ R
> > library(brms)
> > fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data =
> epilepsy, family = poisson())
> Compiling Stan program...
> Error in dyn.load(libLFile) :
> unable to load shared object '/tmp/RtmpKqzbYg/file3245e787c.so':
>
> /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6:
> version `GLIBCXX_3.4.29' not found (required by
> /tmp/RtmpKqzbYg/file3245e787c.so)
> Error in sink(type = "output") : invalid connection
>
> The same code works well with gcc-toolchain@10 instead of gcc-toolchain
> (@12, which is the default). As we can see the generated shared library
> above depends on GCC 12, 10 and GFortran 10 at the same time:
[...]
> Possible solutions:
>
> - Make gcc-toolchain@10 the default and rename gcc-toolchain@12 to
> gcc-toolchain-next@12, like we do for Haskell and (sometimes) Python.
> - Update, both, the default GCC and GFortran to version 12.
> - Explicitly depend on the correct gcc-toolchain in packages that need
> a compiler.
It depends on what you are naming default. :-)
The default GCC toolchain for compiling is provided by the package
gcc-toolchain@10.
Without any specification about the version, if a package name is
defined at several versions, then the command-line uses the higher
version of this package. To avoid the kind of confusing error as you
are observing, usually, the suffix ’-next’ is applied to the package
name for higher versions. For instance, python-numpy-next.
To add a data point to the confusion, consider the package ’gcc’ instead
of ’gcc-toolchain’. As noticed earlier [1], there is a bug. Consider:
--8<---cut here---start->8---
$ guix show gcc@6
guix show: error: gcc@6: package not found
$ guix show gcc@7
name: gcc
version: 7.5.0
outputs:
+ lib: shared libraries
+ debug: debug information
+ out: everything else
systems: x86_64-linux i686-linux
dependencies: gmp@6.2.1 isl@0.23 libelf@0.8.13 libstdc++-headers@10.3.0
mpc@1.2.1 mpfr@4.1.0 perl@5.34.0 texinfo@6.7 zlib@1.2.11
location: gnu/packages/gcc.scm:601:2
homepage: https://gcc.gnu.org/
license: GPL 3+
synopsis: GNU Compiler Collection
description: GCC is the GNU Compiler Collection. It provides compiler
front-ends for several languages, including C, C++, Objective-C, Fortran, Ada,
and
+ Go. It also includes runtime support libraries for these languages.
--8<---cut here---end--->8---
It is because the ’properties’ field of gcc@7 is rewritten,
--8<---cut here---start->8---
(define-public gcc-7
(package
(inherit gcc-6)
(version "7.5.0")
[...]
(properties
`((compiler-cpu-architectures
("aarch64" ,@%gcc-7.5-aarch64-micro-architectures)
("armhf" ,@%gcc-7.5-armhf-micro-architectures)
("x86_64" ,@%gcc-7.5-x86_64-micro-architectures))
--8<---cut here---end--->8---
and thus, it looses ’hidden’, as shown here:
--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages gcc)
scheme@(guix-user)> (package-properties gcc-6)
$1 = ((hidden? . #t) (gcc-libc . #f))
scheme@(guix-user)> (package-properties gcc-7)
$2 = ((compiler-cpu-architectures ("aarch64" "armv8-a" "armv8.1-a" "armv8.2-a"
"armv8.3-a") ("armhf" "armv7" "armv7-a" "armv7-m" "armv7-r" "armv7e-m"
"armv7ve" "armv8-a" "armv8-a+crc" "armv8.1-a" "armv8.1-a+crc" "armv8-m.base"
"armv8-m.main" "armv8-m.main+dsp" "iwmmxt" "iwmmxt2") ("x86_64" "core2"
"nehalem" "westmere" "sandybridge" "ivybridge" "haswell" "broadwell" "skylake"
"bonnell" "silvermont" "knl" "skylake-avx512" "k8" "k8-sse3" "barcelona"
"bdver1"
"bdver2" "bdver3" "bdver4" "znver1" "btver1" "btver2" "geode")))
scheme@(guix-user)>
--8<---cut here---end--->8---
Because the intent of,
--8<---cut here---start->8---
(define-public gcc-toolchain-aka-gcc
;; It's natural for users to try "guix install gcc". This package
;; automatically "redirects" them to 'gcc-toolchain'.
(deprecated-package "gcc" gcc-toolchain-10))
--8<---cut here---end--->8---
is to return the default GCC toolchain when typing ’gcc’ at the command
line. And error for any other version than @10.
1:
Update the default GCC toolchain from 10 to 12 is a core-updates change
and a
bug#60026: Failed to compute derivation bug
Hi Joseph, On Mon, 19 Dec 2022 at 23:37, Joseph Turner wrote: > > Can we close this report? > > Yes, thank you!! For the record -- maybe next time :-) -- for closing, you need to append -done to the bug number in the email address; as in <60026-d...@debbugs.gnu.org>. Cheers, simon
bug#60026: Failed to compute derivation bug
zimoun writes: > Can we close this report? Yes, thank you!! Joseph
bug#60205: Dino lacks some icons
Am Montag, dem 19.12.2022 um 16:14 + schrieb Tirifto: > ** (dino:17647): CRITICAL **: 17:06:11.642: file /tmp/guix-build- > dino-0.3.1.drv-0/dino-0.3.1/main/src/ui/main_window.vala: line 68: > uncaught > error: Unrecognized image file format (gdk-pixbuf-error-quark, 3) > > (dino:17647): Gtk-WARNING **: 17:06:11.676: Found an icon but could > not load > it. Most likely gdk-pixbuf does not provide SVG support. > > (dino:17647): Gtk-WARNING **: 17:06:11.680: Could not load a pixbuf > from > icon theme. > This may indicate that pixbuf loaders or the mime database could > not be found. These two lines appear to mark the most likely culprit. Now, normally our gdk-pixbuf packages do support svg, but there's some strings attached. Most of our GNOME related programs are tested in a GNOME environment rather than a pure one, which means that things that shouldn't work happen to do. Compare the output of guix shell --pure -E DISPLAY dino librsvg adwaita-icon-theme -- dino to guix shell --pure -E DISPLAY dino -- dino Note that librsvg is a regular input to dino and should thus be available as a pixbuf loader. I'm not sure what exactly is wrong here (perhaps dino should swap its librsvg input for gdk-pixbuf), but another caveat is that on non-x86_64 systems we are forced to use a pre-Rust version of librsvg, which barfs on some particular input files. Hope that helps. Cheers
bug#60207: Bug report
Hi all, I was requested to send this mail by the tool. Please see the output below. I hope it can help. I am running Armbian 22.11 on an ASUS Tinker Board. Best regards, Julius julius@tinkerboard:~$ guix pull hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-utf8-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. Kanaal 'guix' bijwerken vanuit Git-repository op 'https://git.savannah.gnu.org/git/guix.git'... Authenticatiekanaal 'guix', kent 9edb3f6 toe aan 5d48d9b (24 nieuwe toekenningen)... Aan het bouwen uit dit kanaal: guix https://git.savannah.gnu.org/git/guix.git 5d48d9b substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% /gnu/store/894c9cqdl7h8agc98911w816s85v7m6n-compute-guix-derivation.drv bouwen... substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% guix-1.4.0-checkout 9.7MiB 1.1MiB/s 00:09 [##] 100.0% /gnu/store/ram1dk48llha4y9lz42288ylrqjk8nmz-subversion-1.14.1.drv bouwen... / 'build' faseild-log 31802 181 subversion/libsvn_subr/sysinfo.c:693:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 693 | ptr = (const unsigned char*)val; | ^ 100% 'check' [\Backtrace: 13 (primitive-load "/gnu/store/824kiadrljmz6g4ad8bjqd00idl8iv5b-compute-guix-derivation") In ice-9/eval.scm: 155:9 12 (_ _) 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ice-9/boot-9.scm: 152:2 10 (with-fluid* _ _ _) 152:2 9 (with-fluid* _ _ _) In ./guix/store.scm: 2170:24 8 (run-with-store # _ #:guile-for-build _ #:system _ #:target _) 1998:8 7 (_ _) In ./guix/gexp.scm: 299:22 6 (_ _) 1180:2 5 (_ _) 1046:2 4 (_ _) 892:4 3 (_ _) In ./guix/store.scm: 2055:12 2 (_ #) 1403:5 1 (map/accumulate-builds # # ?) 1419:15 0 (_ # _ _) ./guix/store.scm:1419:15: ERROR: 1. : message: "build of `/gnu/store/ram1dk48llha4y9lz42288ylrqjk8nmz-subversion-1.14.1.drv' failed" status: 100 guix pull: error: You found a bug: the program '/gnu/store/824kiadrljmz6g4ad8bjqd00idl8iv5b-compute-guix-derivation' failed to compute the derivation for Guix (version: "5d48d9b90575b126911cb942f7894ebd93770903"; system: "armhf-linux"; host version: "1.3.0"; pull-version: 1). Please report the COMPLETE output above by email to .
bug#60205: Dino lacks some icons
Hello! I am running Guix as a supplementary package manager on openSUSE Leap 15.4, and have used it to install the GTK3 XMMP client Dino (package ‘dino’, version 0.3.1). The program seems to work fine, but some icons don’t show up in the graphical user interface. Some of them do (plus symbol, hamburger menu, security lock), but other show a placeholder instead (phone call), while some of them don’t show up at all (checkboxes, window control buttons, i.e. maximise, minimise, close). Please see the attached pictures (‘chat.png’ and ‘settings.png’) for reference. Here is the terminal ouput after running ‘dino’: Gtk-Message: 17:06:11.398: Failed to load module "colorreload-gtk-module" Gtk-Message: 17:06:11.398: Failed to load module "window-decorations-gtk- module" Gtk-Message: 17:06:11.398: Failed to load module "appmenu-gtk-module" ** (dino:17647): CRITICAL **: 17:06:11.642: file /tmp/guix-build- dino-0.3.1.drv-0/dino-0.3.1/main/src/ui/main_window.vala: line 68: uncaught error: Unrecognized image file format (gdk-pixbuf-error-quark, 3) (dino:17647): Gtk-WARNING **: 17:06:11.676: Found an icon but could not load it. Most likely gdk-pixbuf does not provide SVG support. (dino:17647): Gtk-WARNING **: 17:06:11.680: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. Here is the output of ‘guix describe’: guix describe Generation 4pro 17 2022 14:18:38(current) guix 491bddf repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 491bddfa276cc9775adf325c07e5f82638f330e7 Guix usually tries to tell me when I have to do extra steps after installing a package, but it says nothing this time around, so I presume this is a bug. Any help would be appreciated! Best of wishes // Tirifto
bug#60181: fwupd: Using fwupdate fails to find $store/libexec/fwupd/efi/fwupdx64.efi
Hello all, As a user, I am trying to update the UEFI bios on my Lenovo laptop using fwupd package's fwupdate command so that I don't have to use some other OS or USB key drive, etc. I acknowledge this laptop requires a non-free kernel already but in case that is not the main factor, here my output log: sudo fwupdate -a e20bafd3-9914-4f4f-9537-3129e090eb3c ./EECN40WW.cap --verbose Password: (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: loading HwId overrides from /gnu/store/0178g3dzgkp1vm07j48fm66ikpiw5ni1-fwupd-1.8.3/etc/fwupd/daemon.conf (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: not loading HwId overrides from /var/lib/fwupd/daemon.conf (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property Manufacturer=LENOVO (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property EnclosureKind=1f (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property Family=IdeaPad Flex 5 14ARE05 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property ProductName=81X2 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property ProductSku=LENOVO_MT_81X2_BU_idea_FM_IdeaPad Flex 5 14ARE05 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BiosVendor=LENOVO (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BiosVersion=EECN20WW (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BiosMajorRelease=01 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BiosMinorRelease=14 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property FirmwareMajorRelease=01 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property FirmwareMinorRelease=10 (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BaseboardManufacturer=LENOVO (fwupdate:2287): FuHwids-DEBUG: 07:26:27.203: smbios property BaseboardProduct=LNVNB161216 (fwupdate:2287): FuQuirks-DEBUG: 07:26:27.203: ignoring: The resource at “/org/freedesktop/fwupd” does not exist (fwupdate:2287): GLib-GIO-DEBUG: 07:26:27.204: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’ (fwupdate:2287): XbSilo-DEBUG: 07:26:27.206: attempting to load /var/cache/fwupd/quirks.xmlb (fwupdate:2287): XbSilo-DEBUG: 07:26:27.206: file: 251a9493-4cb8-2518-7827-79f2e57cfc8d, current:d28c5cad-29f3-902a-d770-cb40c4dc4657, cached: (null) (fwupdate:2287): FuQuirks-DEBUG: 07:26:27.233: invalid key names: CcgxDmcTriggerCode,CcgxFlashRowSize,CcgxFlashSize,CcgxImageKind,CorsairDeviceKind,CorsairSubdeviceId,CxaudioChipIdBase,CxaudioPatch1ValidAddr,CxaudioPatch2ValidAddr,DellDockBlobBuildOffset,DellDockBlobMajorOffset,DellDockBlobMinorOffset,DellDockBlobVersionOffset,DellDockBoardMin,DellDockHubVersionLowest,DellDockInstallDurationI2C,DellDockUnlockTarget,DellDockVersionLowest,DfuAltName,DfuForceTimeout,DfuForceVersion,ElantpI2cTargetAddress,ElantpIapPassword,ElantpIcPageCount,FastbootBlockSize,FastbootOperationDelay,GenesysScalerCfiFlashId,GenesysScalerGpioEnableRegister,GenesysScalerGpioOutputRegister,GenesysScalerGpioValue,GenesysUsbhubReadRequest,GenesysUsbhubSwitchRequest,GenesysUsbhubWriteRequest,JabraMagic,LogitechHidppModelId,NordicHidBootloader,ParadeLspconAuxDeviceName,PciBcrAddr,RealtekMstDpAuxName,RealtekMstDrmCardKernelName,RedfishResetPostDelay,RedfishResetPreDelay,Rts54I2cSpeed,Rts54RegisterAddrLen,Rts54TargetAddr,SuperioAutoloadAction,SuperioControlPort,SuperioDataPort,SuperioGType,SuperioId,SuperioPort,SuperioTimeout,SynapticsMstDeviceKind,WacomI2cFlashBaseAddr,WacomI2cFlashBlockSize,WacomI2cFlashSize (fwupdate:2287): FuCommon-DEBUG: 07:26:27.242: reading ./EECN40WW.cap with 17714240 bytes (fwupdate:2287): FuPluginUefiCapsule-DEBUG: 07:26:27.243: maximum size is not configured failed: /gnu/store/0178g3dzgkp1vm07j48fm66ikpiw5ni1-fwupd-1.8.3/libexec/fwupd/efi/fwupdx64.efi and /gnu/store/0178g3dzgkp1vm07j48fm66ikpiw5ni1-fwupd-1.8.3/libexec/fwupd/efi/fwupdx64.efi.signed cannot be found I asked on IRC beginning here: https://logs.guix.gnu.org/guix/2022-12-18.log#142657 A cursory look by nckx revealed there might be packaging concerns (if I'm understanding correctly). So, with their motivation, I'm filing this report. Thanks, Charlie
bug#60194: Guix (package manager) fails in initramfs
Because guix relies on pivot_root, it doesn't work in initramfs. Could it be modified to use something else (chroot? switch_root?) to allow for this?
bug#60202: tests/cpio failure
Hi,
Christopher Baines skribis:
> This test seems to fail, maybe because of high inode numbers, maybe
> something to with btrfs.
Uh.
> scheme@(guix-user)> (file->cpio-header "guix/guix.scm")
> $1 = #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 gid:
> 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24
> rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>
[...]
> (let ((port (open-bytevector-input-port (get-bv
> (equal? (peek "A" header)
> (peek "B" (read-cpio-header port))
>
> ;;; ("A" #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003
> gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24
> rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)
>
> ;;; ("B" #< magic: 460545 ino: 736547992 mode: 33188 uid: 1003
> gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24
> rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)
> $3 = #f
(guix cpio) defines cpio headers like this:
--8<---cut here---start->8---
(define-pack
%make-cpio-header cpio-header?
write-cpio-header read-cpio-header
(magic 6 cpio-header-magic)
(ino 8 cpio-header-inode)
(mode 8 cpio-header-mode)
(uid 8 cpio-header-uid)
(gid 8 cpio-header-gid)
(nlink 8 cpio-header-nlink)
(mtime 8 cpio-header-mtime)
(file-size 8 cpio-header-file-size)
(dev-maj 8 cpio-header-device-major)
(dev-min 8 cpio-header-device-minor)
(rdev-maj 8 cpio-header-rdevice-major)
(rdev-min 8 cpio-header-rdevice-minor)
(name-size 8 cpio-header-name-size)
(checksum 8 cpio-header-checksum));0 for "newc" format
--8<---cut here---end--->8---
The ‘ino’ value is stored as an 8-digit hexadecimal number—i.e., on 32
bits. And, guess what:
--8<---cut here---start->8---
scheme@(guile-user)> 5031515288 ;the inode number above
$15 = 5031515288
scheme@(guile-user)> (expt 2 32)
$16 = 4294967296
scheme@(guile-user)> (- $16 $15)
$17 = -736547992
--8<---cut here---end--->8---
Noways, libc + kernel typically use a 64-bit ‘ino_t’, so fundamentally
the cpio format is “wrong”. But what can we do?
At least we can skip this test when that is the case (patch below).
WDYT?
Thanks,
Ludo’.
diff --git a/tests/cpio.scm b/tests/cpio.scm
index 516de0655b..832101d1bb 100644
--- a/tests/cpio.scm
+++ b/tests/cpio.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2015 Ludovic Courtès
+;;; Copyright © 2015, 2022 Ludovic Courtès
;;;
;;; This file is part of GNU Guix.
;;;
@@ -31,12 +31,18 @@ (define-module (test-cpio)
(define %cpio-program
(which "cpio"))
+(define %test-file
+ (search-path %load-path "guix.scm"))
+
(test-begin "cpio")
+;; The cpio format expects 'ino' to fit in 32 bits. If we have a bigger inode
+;; number, skip this test.
+(test-skip
+ (if (>= (stat:ino (lstat %test-file)) (expt 2 32)) 1 0))
(test-assert "file->cpio-header + write-cpio-header + read-cpio-header"
- (let* ((file (search-path %load-path "guix.scm"))
- (header (file->cpio-header file)))
+ (let* ((header (file->cpio-header %test-file)))
(call-with-values
(lambda ()
(open-bytevector-output-port))
bug#60202: tests/cpio failure
This test seems to fail, maybe because of high inode numbers, maybe
something to with btrfs.
I saw this with the failed builds here
https://data.guix.gnu.org/gnu/store/kg93i3bmvpdfkiqyx6g9r7ywh0xpvm8w-guix-1.4.0
cbaines@milano-guix-1 ~$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> (use-modules (guix cpio))
scheme@(guix-user)> (file->cpio-header "guix/guix.scm")
$1 = #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003 gid:
998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24 rdev-maj:
0 rdev-min: 0 name-size: 14 checksum: 0>
scheme@(guix-user)> (use-modules (rnrs io ports))
scheme@(guix-user)> (define header $1)
scheme@(guix-user)> (call-with-values
(lambda ()
(open-bytevector-output-port))
(lambda (port get-bv)
(write-cpio-header header port)
(let ((port (open-bytevector-input-port (get-bv
(equal? header (read-cpio-header port)
$2 = #f
scheme@(guix-user)> (call-with-values
(lambda ()
(open-bytevector-output-port))
(lambda (port get-bv)
(write-cpio-header header port)
(let ((port (open-bytevector-input-port (get-bv
(equal? (peek "A" header)
(peek "B" (read-cpio-header port))
;;; ("A" #< magic: 460545 ino: 5031515288 mode: 33188 uid: 1003
gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24
rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)
;;; ("B" #< magic: 460545 ino: 736547992 mode: 33188 uid: 1003
gid: 998 nlink: 1 mtime: 1671460627 file-size: 1452 dev-maj: 0 dev-min: 24
rdev-maj: 0 rdev-min: 0 name-size: 14 checksum: 0>)
$3 = #f
signature.asc
Description: PGP signature
bug#60194: Guix (package manager) fails in initramfs
Hi, guix question skribis: > Because guix relies on pivot_root, it doesn't work in initramfs. Could it > be modified to use something else (chroot? switch_root?) to allow for this? Could you clarify what you’re doing? You’re trying to run guix-daemon and guix in the initramfs of some distro, is that correct? I don’t think guix-daemon can do away with ‘pivot_root’ though. Thanks, Ludo’.
bug#60165: [1.4.0rc2] Installer doesn't properly render some non-Latin glyphs
Hi, "pelzflorian (Florian Pelz)" skribis: > is it too late to replace by font-gnu-unifont to fix CJK fonts? Oh sure. Could you send a patch? That’ll be in the next release… Thanks, Ludo’.
bug#60200: Incompatibilities between gcc-toolchain and R packages
Hi, I ran into issues with the package r-brms. Take the following reproducer as an example: $ guix shell r-brms r make sed gcc-toolchain bash -C --no-cwd --share=/tmp $ R > library(brms) > fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data = epilepsy, family = poisson()) Compiling Stan program... Error in dyn.load(libLFile) : unable to load shared object '/tmp/RtmpKqzbYg/file3245e787c.so': /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/RtmpKqzbYg/file3245e787c.so) Error in sink(type = "output") : invalid connection The same code works well with gcc-toolchain@10 instead of gcc-toolchain (@12, which is the default). As we can see the generated shared library above depends on GCC 12, 10 and GFortran 10 at the same time: $ ldd /tmp/RtmpKqzbYg/file3245e787c.so | grep -e gcc -e fortran libstdc++.so.6 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libstdc++.so.6 (0x7f69bd9fc000) libgcc_s.so.1 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x7f69bd898000) libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x7f69bd3e6000) libquadmath.so.0 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libquadmath.so.0 (0x7f69bd39b000) libgomp.so.1 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so.1 (0x7f69bccf9000) The command used to link that .so is revealed by strace to be (filenames are random and may differ between runs): ["g++", "-std=gnu++14", "-shared", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-L/usr/local/lib", "-o", "file3373276d0.so", "file3373276d0.o", "/gnu/store/5rdg6sv1nrg1ikqxcykvdh9g4yd2xjvy-r-rstan-2.21.7/site-library/rstan/lib//libStanServices.a", "-L/gnu/store/y7rvp47mz3hcnpvnqsx42qz5yvs10pnl-r-stanheaders-2.21.0-7/site-library/StanHeaders/lib/", "-lStanHeaders", "-L/gnu/store/01lhjrrkvrnsjd8xh4ssdn3bgxc422jl-r-rcppparallel-5.1.5/site-library/RcppParallel/lib/", "-ltbb", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-lR"] So it links against libStanServices.a, libStanHeaders(.a), libtbb(.so) and libR(.so) of which only libR has a reference to gfortran: $ ldd /gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib/libR.so | grep -i fortran libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x7f5be49db000) That means every software linking against R is also incompatible with the current default gcc-toolchain (when using the command line or specifications; different story when writing package recipes). Possible solutions: - Make gcc-toolchain@10 the default and rename gcc-toolchain@12 to gcc-toolchain-next@12, like we do for Haskell and (sometimes) Python. - Update, both, the default GCC and GFortran to version 12. - Explicitly depend on the correct gcc-toolchain in packages that need a compiler. Cheers, Lars
bug#60026: Failed to compute derivation bug
Hi, On Sat, 17 Dec 2022 at 22:19, Joseph Turner wrote: > You were right, zimoun! Sorry to waste your time! No worry. :-) Can we close this report? Cheers, simon
