bug#72990: unset LD_LIBRARY_PATH confirmed as good workaround
Running a few guix-managed applications on top of a generally Ubuntu system here. As of today, am getting the same error message as Edison, both when trying to run guix pull and when trying to run individual applications. Can confirm that following Ludo's suggestion "unset LD_LIBRARY_PATH" makes the problem go away, but only for things launched from the same terminal where I ran the unset command. (Suspect that trying to unset the environment variable more globally would bork the underlying Ubuntu system.) signature.asc Description: PGP signature
bug#66866: [PATCH] build-system: copy: Fix cross-compilation.
* guix/build-system/copy.scm (lower): Change arguments passed to host-inputs
and build-inputs.
Change-Id: I2991854b48587ab00ccc03712304e2850727e6b7
---
This patch tries to fix a issue related to grafting when cross-compiling.
See https://issues.guix.gnu.org/66866 for more discussion.
guix/build-system/copy.scm | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/guix/build-system/copy.scm b/guix/build-system/copy.scm
index d58931b33c..64bd61a53f 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -3,6 +3,7 @@
;;; Copyright © 2020 Pierre Neidhardt
;;; Copyright © 2021, 2022 Ludovic Courtès
;;; Copyright © 2023 Jonathan Brielmaier
+;;; Copyright © 2024 dan
;;;
;;; This file is part of GNU Guix.
;;;
@@ -66,13 +67,13 @@ (define* (lower name
(bag
(name name)
(system system)
-(host-inputs `(,@(if source
- `(("source" ,source))
- '())
- ,@inputs
- ;; Keep the standard inputs of 'gnu-build-system'.
- ,@(standard-packages)))
-(build-inputs native-inputs)
+(build-inputs `(,@(if source
+ `(("source" ,source))
+ '())
+,@inputs
+,@native-inputs
+;; Keep the standard inputs of 'gnu-build-system'.
+,@(standard-packages)))
(outputs outputs)
(build copy-build)
(arguments (strip-keyword-arguments private-keywords arguments
base-commit: 38b88d710ea13ba024aed0543bc2862772cdb645
--
2.41.0
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi David, Thanks for the reply. Apr 11, 2024 04:50:03 David Elsing : Can we put everything inside build-inputs? From my understanding, copy-build-system shouldn't care about cross-compilation at all. I understand it that way too. In guix/build-system.scm, it is mentioned that build/host/target are used in the sense of the GNU toolchain [1]. There, "build" is the system used for building and "host" is the target system for which the package is built. I guess this was confused when copy-build-system was added [2]. Then I think I can submit a patch to guix-patches, hoping to bring more attention to this bug.
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi all, I would really appreciate if anyone could give some feedback on my previous patch to the copy build system. -- dan
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi David,
Thanks for sharing your discovery.
David Elsing writes:
Starting from alsa-lib, I narrowed it down further. I found that
the
problem is actually when an input of the package uses
copy-build-system.
I spent some time digging into the rabbit hole. After changing
the lower function of the copy-build-system to look more like the
lower function of the gnu-build-system, I'm able to cross compile
alsa-lib without the --no-grafts flag. The changes I made are
like:
--8<---cut here---start->8---
diff --git a/guix/build-system/copy.scm
b/guix/build-system/copy.scm
index d58931b33c..74304b4bfb 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -66,13 +66,13 @@ (define* (lower name
(bag
(name name)
(system system)
-(host-inputs `(,@(if source
+(build-inputs `(,@(if source
`(("source" ,source))
'())
- ,@inputs
+ ,@native-inputs
;; Keep the standard inputs of
'gnu-build-system'.
,@(standard-packages)))
-(build-inputs native-inputs)
+(host-inputs inputs)
(outputs outputs)
(build copy-build)
(arguments (strip-keyword-arguments private-keywords
arguments
--8<---cut here---end--->8---
Can we put everything inside build-inputs? From my understanding,
copy-build-system shouldn't care about cross-compilation at all.
Any feedback on this would be really helpful.
Best,
--
dan
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
Hi Josselin, Josselin Poiret writes: Could you post some more details about what you mean by "couldn't work"? What exactly is failing, and with what logs? I was testing it with a cloned guix repo on my disk, opening a shell with "guix shell -D guix git". when checkout to the following commit: $ ./pre-inst-env guix describe Git checkout: repository: /home/dan/workspace/guix/guix/ branch: HEAD commit: 1328c4cca531318e3ed90c6aecb522a5b22a4bcc i run "./pre-inst-env guix system build gnu/system/images/pine64.scm --target=aarch64-linux-gnu -n" would get the following result: $ ./pre-inst-env guix system build gnu/system/images/pine64.scm --target=aarch64-linux-gnu -n The following derivations would be built: /gnu/store/jgd1kl2zavkxsvxa875r8lpndq292vgb-glibc-2.35.drv /gnu/store/0za1m1xwpzwai1sgq5zwgyk6zg62w6a0-diffutils-boot0-3.8.drv /gnu/store/1mizwrvfq2f96jjwxbky0q1pbdhfr09g-grep-mesboot-3.8.drv /gnu/store/9xwp6pi7ssi9jhhj50dd1apryidcz2hk-gawk-mesboot-3.1.8.drv /gnu/store/bfh1p0wjl0jgy7yyzrl9kxxls08in0z9-glibc-mesboot-2.16.0.drv /gnu/store/bwx8g1wy9pc4aa5my3c8mqg0cb68hhw3-make-mesboot-3.82.drv /gnu/store/da5mc3xqc5rqlzc6jyvhgw2nklhcxrxn-gcc-mesboot-4.9.4.drv /gnu/store/f5l62q2ykp5vc9pvnw7cwp9ymkyb1m0p-tar-mesboot-1.34.drv /gnu/store/knnik0y9ckaiahhyrc0vrmciz92jfiaf-gcc-mesboot-wrapper-4.9.4.drv /gnu/store/sdz4dcdd1fnp078m4km980h3q5668w44-sed-mesboot-4.8.drv /gnu/store/svcq1qj4j5b784z2sykrm5nj6qsv0mly-make-boot0-4.3.drv /gnu/store/vljsi6fwfpxwf3bivhsv7nvrdilk0c89-xz-mesboot-5.2.8.drv /gnu/store/1am1zifq9lvlrx7xayzfgq10bzwyi9jz-gawk-boot0-5.2.1.drv /gnu/store/2fyrmqijwm1kn90iy1n339kip9c4iq7d-bzip2-boot0-1.0.8.drv /gnu/store/3kcikvc17a4wfh4bz13sibnbbz2ybi8j-sed-boot0-4.8.drv /gnu/store/879pl2y8f87r7x7p14cxg43qzwrabvhz-bash-static-5.1.16.drv /gnu/store/9h6w80fckq0pz6h9w7ab6si6x9arw46s-coreutils-boot0-9.1.drv /gnu/store/b7abpvf7w2yv8qzj9gvrbxqvys3cfvvi-binutils-cross-boot0-2.38.drv /gnu/store/gjln0wdfin1cd4pa5p05xpgcm18zhbpb-tar-boot0-1.34.drv /gnu/store/lzyaiv4rri34n3wqyr7sh7as5rm3qscy-file-boot0-5.44.drv /gnu/store/xkrprcjws5xjanfbyzxvyjrz59dza43l-findutils-boot0-4.9.0.drv /gnu/store/z9v1jii5ja9y8szrgfyq9vbainldzzrx-patch-boot0-2.7.6.drv /gnu/store/bansacd0mz6f0jilr2b18na7k41vyd7l-gcc-cross-boot0-wrapped-11.3.0.drv /gnu/store/c97avnw7ivnsf4zpz2lhpy7gnxvdyi1v-glibc-intermediate-2.35.drv /gnu/store/f9djhbwy9p706xzkl0r0zx5brqhlm0qd-gcc-cross-boot0-11.3.0.drv /gnu/store/r4ab2f6hmrd0z630c1isyyq7dd3pr3zd-libstdc++-boot0-4.9.4.drv /gnu/store/nq5i5b8y411hfzc5a0xcqmjiw6y2f5wq-ld-wrapper-boot0-0.drv but with the previous commit: $ ./pre-inst-env guix describe Git checkout: repository: /home/dan/workspace/guix/guix/ branch: HEAD commit: f62737bfee086040fa3ecb26968f6d16f84147aa i run the same command, would get the following result: $ ./pre-inst-env guix system build gnu/system/images/pine64.scm --target=aarch64-linux-gnu -n The following derivations would be built: /gnu/store/cax2125wghlr5wz8hwllrz6vb3l7wd83-system.drv /gnu/store/1r0j7c31427lirfdrdggjk9q3jqimf2h-etc.drv /gnu/store/4wf34mjqdb7bnx6jfyhlyki5v14dzvvg-profile.drv /gnu/store/3wh899wnr71shq81lnl3kaw1rpnilvrn-linux-libre-arm64-generic-6.4.16.drv /gnu/store/x7c5jrsg2kv71jb5bdxf4cv107mlnf4p-linux-libre-6.4.16-guix.tar.xz.drv /gnu/store/gyhzn3j6iqa3yf25fv2crbkssg5b7xn5-linux-libre-6.4.16-guix.tar.xz.drv /gnu/store/d11phf2n76syynzmrf02va9phjmgr2d2-raw-initrd.drv /gnu/store/fqnahvhkabz9riaw5ffr3pnpsp1qiyj8-init.drv /gnu/store/0arw5hrqdvzf2ma370ki2d2sn7gij3j5-linux-modules.drv /gnu/store/92phv6cpskhywlwv0lqh9ssrmdbm3rls-module-import-compiled.drv /gnu/store/hgd43fd0b1xgfw23xmq99k75kiq94zpq-boot.drv /gnu/store/a5gwz9v5l5slihmws7wh9x0ic1ckjrb7-shepherd.conf.drv /gnu/store/0kiyxgqnjxigfcks0n494apj6wqb6ylg-shepherd-term-tty3.go.drv /gnu/store/hpjcgw36jypikzj4qqsb8wmlh140gy1f-shepherd-term-tty3.scm.drv /gnu/store/14f4h28fs49vnqvdc65xr5ddcmsh2i79-shepherd-user-file-systems.go.drv /gnu/store/njwv1l3hx5lcph4k0d0ld0j3cggc6c3h-shepherd-user-file-systems.scm.drv /gnu/store/1blrbcbd54yxzc6i57gqba3wf59icc6p-shepherd-file-system--sys-kernel-debug.go.drv /gnu/store/69i8aqkgqlka4f9ld1dg6bqgykc6ygpa-shepherd-file-system--sys-kernel-debug.scm.drv /gnu/store/1sriznlp88pvsjl7nc0pjjzbdy5ws3af-shepherd-loopback.go.drv /gnu/store/rrxcn31zcsnxlaq8zk9gll4iidh0ic1m-shepherd-loopback.scm.drv /gnu/store/v31z2xn1cppj0a1f3yiyvj644vmwndin-set-up-network.drv /gnu/store/y6jhmhhi82pmbdajj69bbzmy4k32pdfg-tear-down-network.drv /gnu/store/2kk9i32m2kb8cnz30j4bwh4mmdndppl5-shepherd-term-tty4.go.drv /gnu/store/k05d8mgivw164n2y4gjg2x3z7lkqdpqw-shepherd-term-tty4.scm.drv /gnu/store/520k2gmf1ijjb76ya5w6ygbv4liwp39k-shepherd-sysctl.go.drv /gnu/store/fib3qy0y43a4a93qyndqbikvqgrhfkxa-shepherd-sysctl.scm.drv /gnu/store/7s3s1668iaiim9dpgz1a7csff4jwc3xh-shepherd-file-system--gnu-store.go.drv /gnu/store/bja3yyc9w5hky3r1aq5hdnb
bug#66866: aarch64 system cross compilation + pinebook pro image broken?
with git bisect i found after this commit the cross-compilation couldn't work anymore: http://git.savannah.gnu.org/cgit/guix.git/commit/?id=1328c4cca531318e3ed90c6aecb522a5b22a4bcc i think this is beyond my ability to understand why it breaks, but if anyone could take a look at this it would be really helpful. -- dan
bug#59069: `guix shell -CN' failed to access GPU
Ludovic Courtès writes: Could you check with strace what it’s trying to access, both with and without ‘-N’? guix shell mesa-utils strace … -C -- strace -o /tmp/log.strace glxinfo I looked into the strace logs, and found out that it's actually having trouble accessing /sys, which is not available in a '-N' container. I run the following scripts to test: $ guix shell -C coreutils -- ls / bin dev etc gnu home proc sys tmp while with the '-N' flag: $guix shell -CN coreutils --ls / bin dev etc gnu home proc tmp I have the strace logs in the paste bin, with the line indicating the problem[1][2]. [1]: https://paste.sr.ht/~lizog/950ef117109fb0d34e70a813852cf7cbf04919a6#log-cn.strace-L585 [2]: https://paste.sr.ht/~lizog/950ef117109fb0d34e70a813852cf7cbf04919a6#log-c.strace-L552 -- dan
bug#59166: Fw: Unable to use GPU in guix shell container with FHS
hi jacob, to use gpu in a container, you need a few additional parameters (assuming you are also using x11): guix shell -CF bash coreutils mesa mesa-utils --expose=/tmp/.X11-unix --expose=$XAUTHORITY --expose=/dev/dri --expose=/etc/udev -E "DISPLAY|XAUTHORITY" -- glxgear hope it could help. -- dan
bug#59069: `guix shell -CN' failed to access GPU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I was trying to run some GUI software in a guix container, and would like to have GPU access in it. However, I later found out that if I gave network access to the container, it seems like unable to properly find the GPU. The following are the commands that I run and the output I got: - --without-network-access-- $ guix shell -C mesa-utils --expose=/tmp/.X11-unix --expose=$XAUTHORITY --expose=/dev/dri --expose=/etc/udev -E "DISPLAY|XAUTHORITY" -- glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: AMD (0x1002) Device: AMD RENOIR (DRM 3.47.0, 5.19.15, LLVM 11.0.0) (0x1638) Version: 21.3.8 Accelerated: yes Video memory: 1024MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.6 Max compat profile version: 4.6 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 Memory info (GL_ATI_meminfo): VBO free memory - total: 655 MB, largest block: 655 MB VBO free aux. memory - total: 15305 MB, largest block: 15305 MB Texture free memory - total: 655 MB, largest block: 655 MB Texture free aux. memory - total: 15305 MB, largest block: 15305 MB Renderbuffer free memory - total: 655 MB, largest block: 655 MB Renderbuffer free aux. memory - total: 15305 MB, largest block: 15305 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 1024 MB Total available memory: 16487 MB Currently available dedicated video memory: 655 MB OpenGL vendor string: AMD OpenGL renderer string: AMD RENOIR (DRM 3.47.0, 5.19.15, LLVM 11.0.0) OpenGL core profile version string: 4.6 (Core Profile) Mesa 21.3.8 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.6 (Compatibility Profile) Mesa 21.3.8 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 - --with-network-access-- $ guix shell -CN mesa-utils --expose=/tmp/.X11-unix --expose=$XAUTHORITY --expose=/dev/dri --expose=/etc/udev -E "DISPLAY|XAUTHORITY" -- glxinfo -B name of display: :1 libGL error: MESA-LOADER: failed to retrieve device information libGL error: MESA-LOADER: failed to open amdgpu: /gnu/store/83kzrpczis5s8hn3ly9y89mij7ngq4bw-mesa-21.3.8/lib/dri/amdgpu_dri.so: cannot open shared object file: No such file or directory (search paths /gnu/store/83kzrpczis5s8hn3ly9y89mij7ngq4bw-mesa-21.3.8/lib/dri, suffix _dri) libGL error: failed to load driver: amdgpu libGL error: MESA-LOADER: failed to retrieve device information libGL error: MESA-LOADER: failed to open amdgpu: /gnu/store/83kzrpczis5s8hn3ly9y89mij7ngq4bw-mesa-21.3.8/lib/dri/amdgpu_dri.so: cannot open shared object file: No such file or directory (search paths /gnu/store/83kzrpczis5s8hn3ly9y89mij7ngq4bw-mesa-21.3.8/lib/dri, suffix _dri) libGL error: failed to load driver: amdgpu display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa/X.org (0x) Device: llvmpipe (LLVM 11.0.0, 256 bits) (0x) Version: 21.3.8 Accelerated: no Video memory: 30926MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 11.0.0, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.8 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.5 (Compatibility Profile) Mesa 21.3.8 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.8 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 - --paste-ends-here-- The only difference between these two executions are the `-N' flag. I also had a look at the related guile code, and it seems like the `-N' flag is only doing two things: 1. bind several network related files to /etc 2. share network namespace to the container I've had a few other guix users tested the commands, and they reported the similar results. Some info about my environment: kernel version: 6.0.7 mesa version: 21.3.8 - -- dan -BEGIN PGP SIGNATURE-
bug#57983: Error installing on a Framework Laptop
Cool, I'll retry for now!
- Dan
On Wed, Sep 21, 2022, at 11:50 PM, Mathieu Othacehe wrote:
> Hello Dan,
>
> Thanks a lot for the bug report.
>
>> The dump was uploaded as installer-dump-11a1087c.
>
> As you are the first one reporting an installer bug using the new dump
> mechanism, a small precision:
>
> the dump can be downloaded this way:
>
> --8<---cut here---start->8---
> mathieu@meije ~$ wget -qO-
> dump.guix.gnu.org/download/installer-dump-11a1087c | tar xvz
> dump.2022-09-21.05.57.10/syslog
> dump.2022-09-21.05.57.10/installer-result
> dump.2022-09-21.05.57.10/installer-backtrace
> dump.2022-09-21.05.57.10/dmesg
> --8<---cut here---end--->8---
>
> It looks like the issue is:
>
> --8<---cut here---start->8---
> Sep 21 05:45:33 localhost installer[548]: substitute: ^Msubstitute:
> ^[[Kupdating substitutes from 'https://ci.guix.gnu.org'...
> 0.0%Backtrace:
> Sep 21 05:45:33 localhost installer[548]: substitute: 14
> (primitive-load "/gnu/store/hsvz87ld2q231g3pqg62a0bwr4j…")
> Sep 21 05:45:33 localhost installer[548]: substitute: In guix/ui.scm:
> Sep 21 05:45:33 localhost installer[548]: substitute:2263:7 13
> (run-guix . _)
> Sep 21 05:45:33 localhost installer[548]: substitute: 2226:10 12
> (run-guix-command _ . _)
> Sep 21 05:45:33 localhost installer[548]: substitute: In
> ice-9/boot-9.scm:
> Sep 21 05:45:33 localhost installer[548]: substitute: 1752:10 11
> (with-exception-handler _ _ #:unwind? _ # _)
> Sep 21 05:45:33 localhost installer[548]: substitute: 1752:10 10
> (with-exception-handler _ _ #:unwind? _ # _)
> Sep 21 05:45:33 localhost installer[548]: substitute: In
> guix/scripts/substitute.scm:
> Sep 21 05:45:33 localhost installer[548]: substitute:763:18 9 (_)
> Sep 21 05:45:33 localhost installer[548]: substitute:348:26 8
> (process-query # _ #:cache-urls _ #:acl _)
> Sep 21 05:45:33 localhost installer[548]: substitute: In
> guix/substitutes.scm:
> Sep 21 05:45:33 localhost installer[548]: substitute:365:27 7
> (lookup-narinfos/diverse _ _ # …)
> Sep 21 05:45:33 localhost installer[548]: substitute:322:31 6
> (lookup-narinfos "https://ci.guix.gnu.org"; _ # _ # _)
> Sep 21 05:45:33 localhost installer[548]: substitute:245:26 5
> (fetch-narinfos _ _ #:open-connection _ # _)
> Sep 21 05:45:33 localhost installer[548]: substitute: In
> ice-9/boot-9.scm:
> Sep 21 05:45:33 localhost installer[548]: substitute: 1685:16 4
> (raise-exception _ #:continuable? _)
> Sep 21 05:45:33 localhost installer[548]: substitute: 1685:16 3
> (raise-exception _ #:continuable? _)
> Sep 21 05:45:33 localhost installer[548]: substitute: 1780:13 2 (_
> #<&compound-exception components: (#<&error> #<&orig…>)
> Sep 21 05:45:33 localhost installer[548]: substitute: 1685:16 1
> (raise-exception _ #:continuable? _)
> Sep 21 05:45:33 localhost installer[548]: substitute: 1685:16 0
> (raise-exception _ #:continuable? _)
> Sep 21 05:45:33 localhost installer[548]: substitute:
> Sep 21 05:45:33 localhost installer[548]: substitute:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Sep 21 05:45:33 localhost installer[548]: substitute: In procedure
> write_wait_fd: unimplemented
> Sep 21 05:45:33 localhost installer[548]: guix system: error:
> `/gnu/store/hsvz87ld2q231g3pqg62a0bwr4jq5rb6-guix-command substitute'
> died unexpectedly
> Sep 21 05:45:33 localhost installer[548]: command ("guix" "system"
> "init" "--fallback" "/mnt/etc/config.scm" "/mnt") exited with value 1
> --8<---cut here---end--->8---
>
> This is an unfixed bug reported here: https://issues.guix.gnu.org/56005
>
> Then the final phase is retried and fails this way:
>
> --8<---cut here---start->8---
> Sep 21 05:57:10 localhost vmunix: [ 1295.546730] /dev/mapper/cryptroot:
> Can't open blockdev
> Sep 21 05:57:10 localhost installer[426]: mounting
> "/dev/mapper/cryptroot" on "/mnt/"
> Sep 21 05:57:10 localhost installer[426]: crashing due to uncaught
> exception: system-error ("mount" "mount ~S on ~S: ~A"
> ("/dev/mapper/cryptroot" "/mnt/" "No such file or directory") (2))
> --8<---cut here---end--->8---
>
> The first issue is most likely transient and you might have better luck
> just by retrying. In the meantime I'll try to understand why the final
> phase retry fails.
>
> Thanks,
>
> Mathieu
bug#57983: Error installing on a Framework Laptop
Hi, I had a problem installing guix on a Framework laptop. The dump was uploaded as installer-dump-11a1087c. Are you able to help me? - Dan
bug#33745: (no subject)
Well it looks like this has been resolved in 8a2cfc7bea37fd5cc5d384ac16d7cd3bd5603ab9
bug#33745: Unnecessary dependencies in Coq
Oh, I forgot about another potential issue: right now the Coq package _hardcodes_ the use of Icecat as a default browser: (modify-phases %standard-phases (replace 'configure (lambda* (#:key outputs #:allow-other-keys) (let* ((out (assoc-ref outputs "out")) (mandir (string-append out "/share/man")) (browser "icecat -remote \"OpenURL(%s,new-tab)\"")) (invoke "./configure" "-prefix" out "-mandir" mandir "-browser" browser "-coqide" "opt" .. Can this be avoided somehow?
bug#33745: Unnecessary dependencies in Coq
I believe that the current Coq package [1] pulls in way too many dependencies. Firstly, as it was already mentioned on Guix-devel [2], the package pulls in texlive and Hevea. I think those are needed only for building the pdf reference manual. Secondly, the Coq package depends on lablgtk -- I guess this is needed for building CoqIDE. Unfortunately, it seems that due to this dependency, the package pulls in all sorts of stuff, including gstreamer and jack! The dependency graph generated by `guix graph coq` is absolutely huge. I think it would be beneficial to split the CoqIDE into a separate package for this reason. [1]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ocaml.scm#n628 [2]: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00291.html
bug#31907: New users get wrong/old profile path to guix after reconfiguring
Well, I wondered myself , and I was palning to test when I arrive home today. But here is my take: 1. Premise: The system configuration is declarative. The declarative state should be obeyed all times by the system 2. Implication: running a guix pull (or any other form of update) as any user should not do anything to the guix stored in the system profile 3. Implication: updates of binaries in the system profile should never be triggered by anything else than a guix reconfigure 4. Implication creating a new user should result in him seeing the base state of the system , as left by guix reconfigure . It should never see any version installed by any other user , root included. Now the issues: - Although the system is declarative, once you run guix config / guys reconfigure you do not know the whole state of the system. Arbitrary package versions are installed, and reconfigure will arbitrary update those packages - the only way I seen to have consistent state is to lock all system packages to a known version, and reconfigure should obey the lock. -running guix reconfigure is an issue at the current time. It is because unless you lock each package @version (and I did not tried t see if this works , a developer should confirm, or point to some good workarround) adding a user, changing system configuration in some othe small way seems to trigger a rebuild - there is no guarantee that GuixSD will offer you a substitution instead of building the derivation. Which if you are unfortunate to update a package for which is not prebuilt substitution you will end up looking at compiles wearing out your time. -it may cause rebuild of critical system daemons, then, guess what, stop them and reload. You have to be very careful and run dry builds to see if anyone touches your system services, cause you do not want unplanned service outage on a server. -it reports success even if it fails to bring the system in the required state. For example for me reconfigure failed to restart 2 services it stopped, but it happily reported all went ok - guix is still broken for me: reconfiguring the system results in build errors sometimes. Also results in service errors , like home service not being able to be restarted. - guix pull inflicts all the wrongs of the universe upon its users. No critical system utility should ever update itself from the bleeding edge of a source repository. No matter how genius the developer is, it will always break in too many ways. This is very bad practice. - guix reconfigure without locked packages does the same offense. will try to update to a version of itself derived directly from development. Tools: - guix still lacks the tools to make sense as a user of what is happening. For example, a guix diff which gives insight what exactly triggered a rebuild. I could not find such a thing. - other tools to keep under control the rebuilding happiness. I have better things to do on my system then looking at walls of compiling , donno for others. I want to add a user , not trigger compiles :P > On Jun 26, 2018, at 14:06, swedebu...@riseup.net wrote: > > ou could ask: why care about the guix version in the system > profile at all? It is not used as soon as you run guix pull or populated > the .config/guix some other way and adjusted the this to preceede in the > PATH. > I care because if I create a new user via config.scm they by > default get access to an outdated guix when a newer is available. This > is in my view a bug.
