bug#65924: git searches coreutils and util-linux commands in PATH
Hi,
Simon Tournier writes:
> Hi Maxim,
>
> On Wed, 13 Sep 2023 at 14:00, Maxim Cournoyer
> wrote:
>
>> The 'git' command should be wrapped to include these in its PATH.
>
> $ guix size git-minimal
> [...]
> total: 147.8 MiB
>
> $ guix size git-minimal util-linux coreutils
> [...]
> total: 195.4 MiB
>
>
> It increases the size by 33% which is not nothing. :-)
>
> Is it only the subcommand git-submodule which is broken? Probably not.
>
> $ find $(guix build git-minimal --no-grafts) -type f -exec grep -H
> git-sh-setup {} \; | cut -f1 -d':' | xargs -I {} basename {}
> grep:
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar:
> binary file matches
> grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git:
> binary file matches
> grep:
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
> binary file matches
> grep:
> /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
> binary file matches
> git-submodule
> git-filter-branch
> git-merge-resolve
> git-mergetool
> git-merge-octopus
> git-merge-one-file
> git-web--browse
> git-web--browse
> git-quiltimport
>
> The question could be: is worth to add 33% for these commands?
I'm not sure where uname is needed; we'd have to check. util-linux is
where most of the weigh increase is at. 'git submodule' is part of
git-minimal; it should work without external tools, ideally.
References are also found in bin/git in your search, which suggests
perhaps the size of git-minimal is a "lie" (the core package is not
fully functional).
--
Thanks,
Maxim
bug#65720: Guile-Git-managed checkouts grow way too much
Hi Ludo, On Wed, 13 Sep 2023 at 20:10, Ludovic Courtès wrote: > ‘get-internal-run-time’ returns “units of processor time” used by the > current process (info "(guile) Time"). When shelling out, the process > calls waitpid(2) and does nothing, so naturally its processor time is > close to zero. > > ‘get-internal-real-time’ should give something closer to elapsed time. Well, let avoid to mix unrelated discussion. :-) For discussing that specific part, I reported on guix-devel my timing using ,time. comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git Simon Tournier Tue, 12 Sep 2023 00:48:30 +0200 id:865y4gz5q9@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 https://yhetil.org/guix/865y4gz5q9@gmail.com The result is still significantly less and discussion is welcome overthere. :-) Cheers, simon
bug#65924: git searches coreutils and util-linux commands in PATH
Hi Maxim,
On Wed, 13 Sep 2023 at 14:00, Maxim Cournoyer wrote:
> The 'git' command should be wrapped to include these in its PATH.
--8<---cut here---start->8---
$ guix size git-minimal
[...]
total: 147.8 MiB
$ guix size git-minimal util-linux coreutils
[...]
total: 195.4 MiB
--8<---cut here---end--->8---
It increases the size by 33% which is not nothing. :-)
Is it only the subcommand git-submodule which is broken? Probably not.
--8<---cut here---start->8---
$ find $(guix build git-minimal --no-grafts) -type f -exec grep -H git-sh-setup
{} \; | cut -f1 -d':' | xargs -I {} basename {}
grep:
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/scalar:
binary file matches
grep: /gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/bin/git:
binary file matches
grep:
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/scalar:
binary file matches
grep:
/gnu/store/y3vdq2pdkljrw63xxnc2vb6lz07ycar6-git-minimal-2.41.0/libexec/git-core/git:
binary file matches
git-submodule
git-filter-branch
git-merge-resolve
git-mergetool
git-merge-octopus
git-merge-one-file
git-web--browse
git-web--browse
git-quiltimport
--8<---cut here---end--->8---
The question could be: is worth to add 33% for these commands?
Cheers,
simon
bug#65889: texlive-acronyms is missing dependencies
Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Daniel Meißner via Bug reports for GNU Guix writes: > [...] >> I can provide a patch if desired to add texlive-xstring and >> texlive-bigfoot to texlive-acronym’s (propagated-)inputs. The suffix >> package appears to be bundled with texlive-bigfoot. Do we want to >> unbundle it or simply add texlive-bigfoot to the (propagated-)inputs? > > We use dependencies specified in TeX Live itself (as in "texlive.tlpdb" > file), for sanity reasons. There are 4000+ packages; I think it is not > reasonable to grep through their output to find the unspecified > dependencies. It will also be terrible when using some updater, now this > tool can remove propagated inputs. > > Most dependencies issues are resolved installing collections of > packages, such as `texlive-collection-latexrecommended'. As a data > point, I only resolve dependencies "manually" when they would otherwise > require me to install `texlive-collection-latexextra', which is just too > big. > > AFAIC, I suggest to not fix this, as this is not worth the trouble. I see, makes sense. I am closing this issues then. Thanks for your fast reply and your hint to use collections instead. I sometimes make a game out of the most minimal Texlive manifest.scm for my TeX writings :D Best -- Daniel
bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."
Hi Denis, Denis 'GNUtoo' Carikli skribis: > And it booted fine. Thanks a lot. Awesome, thanks for checking! Ludo’.
bug#65927: the role and location of locale.alias
Hi, In guix 1.4.0 there are 2 locale.alias files from glibc on the disk: $ ls -liL --sort=size `find / -name locale.alias 2>/dev/null | grep -v X11` 940417 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/0dbscs8zq4bdg8vbn9jkdgynjcn3s01p-gcc-toolchain-12.2.0/share/locale/locale.alias 940417 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/share/locale/locale.alias 15716 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33/share/locale/locale.alias 15716 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/c326489r6jvnl69l2nbmdvxmgzqln2hy-profile/share/locale/locale.alias 15716 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/isn13ca7419sj7myb3xr3i3zbxspky8c-profile/share/locale/locale.alias 15716 -r--r--r-- 1 root root 2998 Jan 1 1970 /gnu/store/yh51nb5dq9n6pw8mrdp3nxcfmxzmrp1x-profile/share/locale/locale.alias 1058938 -r--r--r-- 1 root root 261 Jan 1 1970 /gnu/store/wf46adk80fdc1qij8472n8r2xr4cln0a-gdm-42.0/share/gdm/locale.alias I explained the purpose of this file in https://sourceware.org/pipermail/libc-alpha/2023-September/151524.html . In summary, it's a configuration file whose initial contents is provided for glibc, but which needs to be edited by the system administrator in some situations. For this reason, in Debian 12, the file has been moved to /etc/locale.alias, and /usr/share/locale/locale.alias is merely a symbolic link to /etc/locale.alias. IMO, this is the correct way to handle this configuration file. The way Guix handles this file provokes two problems: 1) When the system administrator wants to add a new alias, they have to search for all occurrences of the file in the (two) glibc installations. And if/when they install newer versions of glibc, they will have to reapply their change again and again. 2) GNU gettext needs to access this file, in order to recognize the same aliases that glibc recognizes. But glibc does not export the _nl_expand_alias function. Therefore GNU gettext needs to know where the file is. But how could GNU gettext retrieve any of the file names /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/share/locale/locale.alias /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33/share/locale/locale.alias ? If Guix had this configuration file moved to /etc, like Debian did, GNU gettext could be compiled with '-DLOCALE_ALIAS_PATH=\"/etc\"' and would then be able to access it. Bruno
bug#65926: package openjdk 20.0.2 and release-candidate 21+35 and add helpers for that
Hi, attached are patches to add helpers and package openjdk 20.0.2 and 21+35. The 21+35 package skips the validation of the runpath, because that fails. I don’t know why. From e72a8ec42a4d4a199711c0abf7960f8caeab5c1e Mon Sep 17 00:00:00 2001 Message-ID: From: Arne Babenhauserheide Date: Wed, 13 Sep 2023 21:59:25 +0200 Subject: [PATCH 1/4] Add version-prefix-+ for versions with + as separator of the build * guix/utils.scm (version-prefix-+): new procedure --- guix/utils.scm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/guix/utils.scm b/guix/utils.scm index e9af33bdeb..2993b31a5c 100644 --- a/guix/utils.scm +++ b/guix/utils.scm @@ -116,6 +116,7 @@ (define-module (guix utils) version>? version>=? version-prefix +version-prefix-+ version-major+minor+point version-major+minor version-major @@ -822,6 +823,11 @@ (define (version-major version-string) "Return the major version number as string from the version-string." (version-prefix version-string 1)) +(define (version-prefix-+ version-string) + "Truncate version-string to leave out a suffix appended with +. +For example, (version-prefix-+ \"21+35\" returns \"21\"" + (string-join (take (string-split version-string #\+) 1) "+")) + (define (version-unique-prefix version versions) "Return the shortest version prefix to unambiguously identify VERSION among VERSIONS. For example: base-commit: e2a7c227dea5b361e2ebdbba24b923d1922a79d0 prerequisite-patch-id: e26acb8280f31db9b663b6fc444a2229fc5b588e prerequisite-patch-id: db5cc62f7d04f3ed3014ae984fe732f3b6db8d17 prerequisite-patch-id: 3a0bf9ef6f27f1d92537c5e9ee5c38c7d6ced99e prerequisite-patch-id: 088a72da8c11e5d1c7087b4a5e8bb9c4a3b9b2af prerequisite-patch-id: 1b4787e17ec6ab62978615e1d3804a1024c5e1a0 prerequisite-patch-id: f814d9756faa5d91a68b81654606c66b4cf389e5 prerequisite-patch-id: f2dbed3e6da49472bd141c9fa40de2d2208130fb prerequisite-patch-id: 2dbf557994da4a264566b67294f7f3f8e2931f5f prerequisite-patch-id: 912a76fac540b98d5683ba1886a7d62f0963cd9f prerequisite-patch-id: f6a9bfd16b8952c73b7a6d97be70013a290815d7 prerequisite-patch-id: e50c1aaa1d401bba32a49d2e1fb1661746543d09 prerequisite-patch-id: 1f63cb516bc5c9772ae808371528006fca20dcad prerequisite-patch-id: 1ac04f0120fb6c4f106d05bee88103debb815b41 prerequisite-patch-id: eeff242fb5e41c8c83b3daadd0965e58eb6670ba prerequisite-patch-id: 3812c9ac1252d9d20e8485462be155156f302a54 prerequisite-patch-id: 9d3dd155c91ab334999c03fefab04f361ea4d8b5 prerequisite-patch-id: f5b09b934b65fe45bdfd1273baa3bb949ed52cca prerequisite-patch-id: 61a9b3943bdbe5cb6a4aa97ceb64088f9a14 prerequisite-patch-id: 3f9d50361fb537607c33d09115366aec05160688 prerequisite-patch-id: 765c77b7c31f24491149665a066d2906f8da8d33 prerequisite-patch-id: 2b92c37e3aa74152a7aa226e1fbd5f2735037dc0 prerequisite-patch-id: 2a3123ab0786108f26e25c45fc4c545b99b6dd27 prerequisite-patch-id: 891a2458a90ea90113c576df5029514f5143366e prerequisite-patch-id: 1a08957a2fd3e3637ed7f3cf3f44c9f8194d6668 prerequisite-patch-id: d382210c915c0a809cb709cba45a4542d60c4d20 prerequisite-patch-id: d424ad2c4c4bf14becb025c67757f48d4a6ae6b5 prerequisite-patch-id: 07e1c90231819e0b963645b041522e53891fd344 prerequisite-patch-id: 124009dec6dad63add19bf258f71bdb127078ecb prerequisite-patch-id: 0afa33c8e0e2aca07da2782e04d259d3f8c498c5 prerequisite-patch-id: 205bb6c05a145eb9137e8623687418089351e73e prerequisite-patch-id: 7138f72403701b9749a0a587f1807030d730c00d prerequisite-patch-id: 39bd665160a5e62aaa4ea94ad2e3ca30f31e2127 -- 2.41.0 From 42b2dbb2d09ab5706523f25951f51289e3ad6181 Mon Sep 17 00:00:00 2001 Message-ID: <42b2dbb2d09ab5706523f25951f51289e3ad6181.1694635452.git.arne_...@web.de> In-Reply-To: References: From: Arne Babenhauserheide Date: Wed, 13 Sep 2023 22:00:55 +0200 Subject: [PATCH 2/4] Add syntax make-openjdk-release-candidate for versions like 21+35 * gnu/packages/java.scm (make-openjdk-release-candidate): new procedure --- gnu/packages/java.scm | 39 +++ 1 file changed, 39 insertions(+) diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm index f7464e2168..0c22f4def9 100644 --- a/gnu/packages/java.scm +++ b/gnu/packages/java.scm @@ -1431,6 +1431,45 @@ (define-syntax make-openjdk field ...))) +(define-syntax make-openjdk-release-candidate + ;; Return an OpenJDK package at VERSION with checksum HASH, using BOOTSTRAP, + ;; the bootstrap package. One or more FIELD can be provided to further + ;; refine the package definition; for convenience, the BASE, NAME and + ;; VERSION are defined in their scope. + (lambda (x) +(syntax-case x () + ((_ bootstrap version* hash field ...) + (with-syntax ((base (datum->syntax x 'base)) + (name (datum->syntax x 'name)) + (version (datum->syntax x 'version))) + #'(let ((base (package + (inherit
bug#65925: bluez or jack in the closure of python-ipython?
Hi, IPython is a Python REPL and there is no direct dependencies on bluez or jack. Why does it need unrelated tools as some Bluetooth or JACK audio? --8<---cut here---start->8--- $ guix size python-ipython | grep -E '(jack|bluez)' /gnu/store/kbvyzkxrpf8w9v64jvjkr12hcailhflx-bluez-5.66 192.8 4.3 0.2% /gnu/store/7bhggk7fzvgjvgi9ykphgg21gwlfgx4k-jack-0.125.090.8 1.3 0.1% --8<---cut here---end--->8--- Well, any idea why bluez or jack are in the picture? --8<---cut here---start->8--- $ for p in $(guix show python-ipython | recsel -C -P dependencies); do guix size $p ;done | grep -E '(bluez|jack)' … nothing! --8<---cut here---end--->8--- Last, the chain of dependencies looks like: --8<---cut here---start->8--- $ guix graph --path python-ipython bluez python-ipython@8.5.0 python-matplotlib@3.5.2 python-wxpython@4.2.0 wxwidgets@3.2.2.1 sdl2@2.26.2 pulseaudio@16.1 bluez@5.66 $ guix graph --path python-ipython jack python-ipython@8.5.0 python-matplotlib@3.5.2 python-wxpython@4.2.0 wxwidgets@3.2.2.1 sdl2@2.26.2 pulseaudio@16.1 jack@0.125.0 --8<---cut here---end--->8--- Cheers, simon --8<---cut here---start->8--- $ guix show python-ipython name: python-ipython version: 8.5.0 outputs: + out: everything systems: x86_64-linux dependencies: graphviz@7.0.1 pkg-config@0.29.2 python-backcall@0.2.0 python-decorator@5.0.9 python-jedi@0.18.2 python-jinja2@3.1.1 python-jsonschema@4.5.1 + python-matplotlib-inline@0.1.3 python-matplotlib@3.5.2 python-mistune@0.8.4 python-nbformat@5.3.0 python-numpy@1.23.2 python-numpydoc@1.5.0 + python-pexpect@4.8.0 python-pickleshare@0.7.5 python-prompt-toolkit@3.0.29 python-pygments@2.12.0 python-pytest@7.1.3 python-pyzmq@25.1.0 + python-requests@2.28.1 python-simplegeneric@0.8.1 python-stack-data@0.2.0 python-terminado@0.10.0 python-testpath@0.5.0 python-traitlets@5.9.0 + readline@8.1.2 which@2.21 location: gnu/packages/python-xyz.scm:10859:2 homepage: https://ipython.org license: Modified BSD synopsis: IPython is a tool for interactive computing in Python description: IPython provides a rich architecture for interactive computing with: Powerful interactive shells, a browser-based notebook, support for + interactive data visualization, embeddable interpreters and tools for parallel computing. $ guix show bluez name: bluez version: 5.66 outputs: + out: everything systems: x86_64-linux dependencies: dbus@1.14.0 eudev@3.2.11 gettext-minimal@0.21 glib@2.72.3 libical@3.0.16 pkg-config@0.29.2 python-docutils@0.19 readline@8.1.2 location: gnu/packages/linux.scm:5750:2 homepage: http://www.bluez.org/ license: GPL 2+ synopsis: Linux Bluetooth protocol stack description: BlueZ provides support for the core Bluetooth layers and protocols. It is flexible, efficient and uses a modular implementation. $ guix show jack name: jack version: 0.125.0 outputs: + out: everything systems: x86_64-linux i686-linux dependencies: alsa-lib@1.2.4 bdb@6.2.32 pkg-config@0.29.2 readline@8.1.2 util-linux@2.37.4 location: gnu/packages/audio.scm:2507:2 homepage: https://jackaudio.org/ license: GPL 2+, LGPL 2.1+ synopsis: JACK audio connection kit description: JACK is a low-latency audio server. It can connect a number of different applications to an audio device, as well as allowing them to share + audio between themselves. JACK is different from other audio server efforts in that it has been designed from the ground up to be suitable for + professional audio work. This means that it focuses on two key areas: synchronous execution of all clients, and low latency operation. --8<---cut here---end--->8---
bug#65720: Guile-Git-managed checkouts grow way too much
Hi, wolf skribis: > (define (time proc) > (let* ((start (get-internal-run-time)) > (_ (proc)) > (end (get-internal-run-time))) > (exact->inexact (* 1000 (/ (- end start) > internal-time-units-per-second) > > (format #t "Guix: ~ams\nGit: ~ams\n" > (time (λ () (commit-relation c1 c2))) > (time (λ () (shelling-commit-relation c1 c2 ‘get-internal-run-time’ returns “units of processor time” used by the current process (info "(guile) Time"). When shelling out, the process calls waitpid(2) and does nothing, so naturally its processor time is close to zero. ‘get-internal-real-time’ should give something closer to elapsed time. Ludo’.
bug#65924: git searches coreutils and util-linux commands in PATH
Hello, Attempting to use git-minimal in a --pure environment, I stumbled upon: --8<---cut here---start->8--- /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule: line 7: basename: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule: line 7: sed: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup: line 77: basename: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup: line 77: sed: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-sh-setup: line 292: uname: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule: line 613: sed: command not found /gnu/store/grc79ijx09nygvjh67cpk3g405nzr801-profile/libexec/git-core/git-submodule: line 613: cmd_: command not found ☒ git clone exited 127 --8<---cut here---end--->8--- The 'git' command should be wrapped to include these in its PATH. -- Thanks, Maxim
bug#65923: [mumi] after sending a new patch series, current issue should be set
Hi, Currently doing something like: --8<---cut here---start->8--- $ mumi new $ mumi send-email *.patch (mumi queries new issue number from Debbugs) (patches are sent) $ mumi current -> No current issue! --8<---cut here---end--->8--- I'd expect the last 'mumi current' command to return the issue found querying Debbugs at step 2. -- Thanks, Maxim
bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."
Hi again, For some reasons I didn't receive your last mail. In the machine definition I have (system "aarch64-linux"). I've now also added -s aarch64-linux as well just to be safe. As for the patch, it is now in Guix (4dd33fc628 gnu: shepherd: Switch back to Fibers 1.1 on Arm machines.), and after bisecting the kernel issue I had (I sent a bug report for that), I simply modified the system definition to use linux-libre-lts instead. I used this guix revision: > $ guix describe > Generation 71 Sep 13 2023 16:03:04(current) > guix 4f933f9 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 4f933f977dd8aa61ca3e50b194d3b56e298a3e30 And it booted fine. Thanks a lot. Denis. pgpDbFmKY_RwC.pgp Description: OpenPGP digital signature
bug#65917: aarch64 system broken since "gnu: linux-libre: Update to 6.4.8."
Hi,
When doing a guix-deploy on aarch64 with the following command in a
checked out guix git repository with the following command:
> guix time-machine --commit=$(git rev-parse HEAD) -- deploy -L
> rockpro64/ rockpro64/rockpro64.scm
I've got the following build failure:
> LD [M] net/openvswitch/openvswitch.ko
> LD [M] net/openvswitch/vport-vxlan.ko
> LD [M] net/openvswitch/vport-geneve.ko
> LD [M] net/openvswitch/vport-gre.ko
> LD [M] net/vmw_vsock/vsock.ko
> LD [M] net/vmw_vsock/vsock_diag.ko
> LD [M] net/vmw_vsock/vmw_vsock_vmci_transport.ko
> LD [M] net/vmw_vsock/vmw_vsock_virtio_transport.ko
> LD [M] net/vmw_vsock/vmw_vsock_virtio_transport_common.ko
> LD [M] net/vmw_vsock/hv_sock.ko
> LD [M] net/vmw_vsock/vsock_loopback.ko
> LD [M] net/nsh/nsh.ko
> LD [M] net/qrtr/qrtr.ko
> LD [M] net/qrtr/qrtr-smd.ko
> LD [M] net/qrtr/qrtr-tun.ko
> LD [M] net/qrtr/qrtr-mhi.ko
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "6")
> exit-status: 2 term-signal: #f stop-signal: #f> phase `build' failed
> after 16208.5 seconds command "make" "-j" "6" failed with status 2
> builder for
> `/gnu/store/f678azkxiyxv5vm5yacr7pp6c4rhsnaw-linux-libre-6.4.8.drv'
> failed with exit code 1 cannot build derivation
> `/gnu/store/rqdmzzgcydvy485hp3fib2s6pz6ib5pk-linux-modules.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/fznw4yyx5s4wdi950hmdw78lyz0chlgr-parameters.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/dw3z33as5s7jhppha2bgi3kiab26pix0-profile.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/y385isj6ha1dpzcxnws1vq4b9wf3bpcr-system.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/791hw1spny38mlhiknf77ihikk2km9zz-switch-to-system.scm.drv':
> 1 dependencies couldn't be built cannot build derivation
> `/gnu/store/3hvlqvfd9x7mylkrr8wsiw4vwpja60hk-remote-exp.scm.drv': 1
> dependencies couldn't be built guix deploy: error: build of
> `/gnu/store/3hvlqvfd9x7mylkrr8wsiw4vwpja60hk-remote-exp.scm.drv'
> failed
So I've bisected and the bisect found this commit:
> bff1f2d4d07e934ea296f9c724b5337996a27c44 is the first bad commit
> commit bff1f2d4d07e934ea296f9c724b5337996a27c44
> Author: Leo Famulari
> Date: Tue Aug 8 10:37:16 2023 -0400
>
> gnu: linux-libre: Update to 6.4.8.
>
> * gnu/packages/linux.scm (linux-libre-version,
> linux-libre-gnu-revision, linux-libre-pristine-source,
> linux-libre-source, linux-libre, linux-libre-with-bpf): Update to
> linux-libre 6.4.
>
> gnu/packages/linux.scm | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
Denis.
;;; Copyright © Guix documentation authors
;;; Copyright © 2022 Denis 'GNUtoo' Carikli
;;; This file is not part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix. If not, see
bug#65889: texlive-acronyms is missing dependencies
Hello,
Daniel Meißner via Bug reports for GNU Guix writes:
> The following MWE does not compile with pdflatex using the modular
> texlive packages:
>
> --8<---cut here---start->8---
> \documentclass{article}
> \usepackage{acronym}
>
> \begin{document}
> \end{document}
> --8<---cut here---end--->8---
>
>
> It yields the following:
>
> --8<---cut here---start->8---
> $ guix shell texlive-scheme-basic texlive-acronym -- pdflatex acronym-mwe.tex
> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/GNU Guix)
> (preloaded format=pdflatex)
> restricted \write18 enabled.
> entering extended mode
> (./acronym-mwe.tex
> LaTeX2e <2022-11-01> patch level 1
> L3 programming layer <2023-02-22>
> (/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/base/article.cls
> Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
> (/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/base/size10.clo))
>
> (/gnu/store/v4m2fj7xhpfs7k5l97p238j1bc2ccppf-profile/share/texmf-dist/tex/latex/acronym/acronym.sty
>
> ! LaTeX Error: File `suffix.sty' not found.
>
> Type X to quit or to proceed,
> or enter new name. (Default extension: sty)
>
> Enter file name:
> --8<---cut here---end--->8---
>
> I think this is due to missing dependencies suffix and xstring which are
> required to be installed for acronym to work. On page 10 of the package
> docs [1] it reads
>
> \RequiredPackage{suffix, xstring}
>
> 1: https://ftp.gwdg.de/pub/ctan/macros/latex/contrib/acronym/acronym.pdf
>
> I can provide a patch if desired to add texlive-xstring and
> texlive-bigfoot to texlive-acronym’s (propagated-)inputs. The suffix
> package appears to be bundled with texlive-bigfoot. Do we want to
> unbundle it or simply add texlive-bigfoot to the (propagated-)inputs?
We use dependencies specified in TeX Live itself (as in "texlive.tlpdb"
file), for sanity reasons. There are 4000+ packages; I think it is not
reasonable to grep through their output to find the unspecified
dependencies. It will also be terrible when using some updater, now this
tool can remove propagated inputs.
Most dependencies issues are resolved installing collections of
packages, such as `texlive-collection-latexrecommended'. As a data
point, I only resolve dependencies "manually" when they would otherwise
require me to install `texlive-collection-latexextra', which is just too
big.
AFAIC, I suggest to not fix this, as this is not worth the trouble.
Regards,
--
Nicolas Goaziou
bug#57402: Reopening
reopen 57402 thanks Sorry, this was a mistake. Andreas
bug#57402: Closing
Hopefully really closing the bug this time. Andreas
bug#63047: Can't load glib debug symbols in gdb
On 2023-04-25 08:38, Maxim Cournoyer wrote: > Hi Andrew, > > Josselin Poiret via Bug reports for GNU Guix writes: > >> Hi Andrew, >> >> Andrew Tropin writes: >> >>> I try to run emacs in gdb with debug symbols for some libs available, I >>> succeed with gtk+, but it doesn't work for glib and glibc. It looks >>> strange to me, but maybe I am doing something wrong. >>> >>> Reproducer: >>> >>> guix shell gdb emacs-next-pgtk glibc:debug gtk+:debug glib:debug \ >>> --with-debug-info=glibc --with-debug-info=glib --with-debug-info=gtk+ \ >>> --no-grafts -- gdb .emacs-30.0.50-real >> >> At least for glibc, the glibc that is linked against is the one in (gnu >> packages commencement), which is hidden from the user. The one in (gnu >> packages base), which you can refer to with "glibc" is different. You >> can try to find the proper debug output by looking at `guix size` of >> your store path, then finding out the deriver for glibc with `guix gc >> --derivers` and finally looking at the .drv to find out what the debug >> output should be. >> >> For glib, it might be similar, make sure that you're using exactly the >> right store path for it. > > Perhaps try on the core-updates branch, where glibc no longer has its > symbols stripped. Another thing that can cause the debug symbols to not > be found is grafts, as described in #48907, so when debugging I'd > recommend using --no-grafts for now. Thank you for the tips. For future readers: the core-updates merged, it should be fixed, however, I didn't check if it works now. Closing the issue, but feel free to reopen. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#65909: in Geiser
Hi, If I connect Geiser to a Guix REPL, like so: $ guix repl --listen=tcp:37146 & M-x geiser-connect RET RET and enter the following into it: ,use (guix packages) (package (name "test") (version "1.0.0") (source #f) (build-system #f) (home-page #f) (synopsis #f) (description #f) (license #f)) I get this error: While compiling expression: Syntax error: unknown file:#f:#f: encountered raw symbol in macro output in subform socket of (current-location-vector) When putting the same into a typical `guix repl` instance running in the foreground within a terminal, I get no error, just the object that I expected. This can be temporarily fixed by adding ``(location #f)'' to the end of the package record. Any ideas why this happens? I don't know the first thing about how Geiser works... -- (
