bug#70456: Request for merging core-updates branch
Hi, it seems the core-updates branch is first in the merge-queue. haskell-team was successfully built by the CI and is ready to be merged. Since there does not seem to be an ETA for core-updates, can I skip the queue and go ahead with merging haskell-team? Lars
bug#70480: Guix bios installation: Grub error: unknown filesystem
Hi, >Installing for i386-pc platform. >/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: > error: unknown filesystem. this should be fixed by 71210, which I just merged. Lars
bug#66248: ghc: stale versions
Hi, > The latest GHC version available in the main channel is 9.2.5, released > in November 2022. Latest 9.2.x is now 9.2.8. I would also like to > mention that no GHC versions matching 9.4.x and 9.6.x are available either. I’m updating GHC to 9.2.8 on the haskell-team branch, 9.4.4 is packaged as ghc-next and there’s a patch-set to bump to 9.4.8 and add 9.6 here: https://issues.guix.gnu.org/67921#8 Lars
bug#64734: Recursive hackage import fails
Hi, > $ guix import hackage linear-generics --recursive have you ever figured out what caused this? I cannot reproduce it currently – probably because ghc-th-abstraction is part of Guix already and no recursion actually happens. Lars
bug#38946: guix import fails for cabal-helper
Hi, > I've been trying to improve the Haskell tooling we have here on Guix, but > I ran into this problem: if I try to do ~guix import hackage > cabal-helper~ it fails with: Guix has had support for the `common` stanza for quite a while now and importing cabal-helper works. Closing. Lars
bug#25235: [Maxim Cournoyer] bug#25235: [PATCH v3 1/1] build-system/pyproject: Do not wrap native-inputs.
Hi, > I'm advancing with my patch series, which I can submit soon. I was > curious about why this 25235 patch isn't in python-team branch yet since > it's also a very welcome change to the pyproject-build-system. I believe this change is based on #60847, which Ludo objected to (https://issues.guix.gnu.org/60847#19-lineno32). Thus it cannot be merged. Lars
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hey Ludo, > Should ‘guix import pypi’ attempt to get dependency information from > ‘pyproject.toml’, in addition to ‘requirements.txt’ and wheel ‘METADATA’ > as it already does? yes it should. It’s the next logical step after having a pyproject-build-system. The python-team branch (not sure whether Ricardo had time to merge it yet) adds a TOML parser to Guix as a first step. > It might be more complicated than we’d like: in some cases, that file > seems to be used as a “trampoline” to Poetry. For instance, in > python-pypugjs, the ‘requires’ bit delegates everything to Poetry: The file is always a trampoline to other build systems, like setuptools or poetry. That’s (unfortunately) by design, see the [build-system] section. > [tool.poetry.dependencies] > python = "^3.8" > Jinja2 = "^3.1.1" > Mako = "^1.1.3" > tornado = "^6.0.4" > six = "^1.15.0" > coverage = "^6.3.2" > nose = "^1.3.7" > Flask = "^2.1.1" > charset-normalizer = "^2.1.0" > flake8 = "^4.0.1" That’s unfortunate, because the specification includes a common field for dependencies: https://packaging.python.org/en/latest/specifications/pyproject-toml/#dependencies-optional-dependencies I guess we’ll have to deal with these idiosyncracies as well :( Lars
bug#35743: guix import hackage: fails with mixed indentation
Hi, > http://hackage.haskell.org/package/warp-3.2.27/warp.cabal > http://hackage.haskell.org/package/streaming-commons-0.2.1.0/streaming-commons.cabal > > contain things along the following lines: these should be fixed by the patch in #67564. Cheers, Lars
bug#67572: tests fail for python-sphinx-prompt
Hi, > All 12 of the tests for python-sphinx-prompt fail: > > https://ci.guix.gnu.org/build/2678884/log/raw fixed by commit 877086a8649a86f1556bddd430e9478b2562f365. Cheers, Lars
bug#51928: GHC 8.10 occupies 1.6 GiB
Hi, > still current. I’m not so sure about that. We link (most/all?) Haskell binaries (pandoc for example) statically, so none of them should pull in GHC any more. If they do, that’s a bug. It’s almost impossible to untangle GHC libraries (and also GHC itself), since there are circular references between config files, static libraries and shared libraries. So I believe the solution above is the best we can do right now. Cheers, Lars
bug#66072: Duplicate/conflicting definitions for ocl-icd
Hi, > Which is the good one? according to commit 4d1157fca7627c11672df0cd80fae4f4d27e2185 ocl-icd was dead, which is why I replaced it. I cannot tell which one is better though. Tobias maybe? Lars
bug#64309: Python dlopen()s musl libc
Hi Josselin, > Woah, looks like a neat solution. Do you think it would scale for all > our Python packages without manual intervention? If so, this would > definitely be the way forward. I hope so, but haven’t tried it yet. > I mostly agree with you, but for this rather common case of having also > a usercustomize it would be nice to circumvent it. In general, I don't > think we ever want a Guix-produced Python script to load the > usercustomize, hence my suggestion. The other case of PYTHONPATH is > also annoying but can be tamed by modifying the env variable > temporarily. True, PYTHONPATH can be unset more easily than moving the user site dir. I’ll have a look at #64573, which should work around this issue. Cheers, Lars
bug#64309: Python dlopen()s musl libc
Hi,
there’s a similar issue #63912 and a thread on the guix-devel
mailinglist at
https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00066.html
> So, looks like the default Python behavior is to load the usercustomize
> after the sitecustomize [1], which leads to exactly the behavior you're
> experiencing. I don't know what we should do here, maybe pass `-s` to
> the shebang line of Python to disable loading the usercustomize? That
> would probably be a world-rebuild though. CC'ing the Python team to see
> what they think.
I think the problem is bigger than usercustomize. Any custom PYTHONPATH
also slips through and causes this issue, as well as any custom
GUIX_PYTHONPATH, because the executable wrapper appends it (think nested
`guix shell` invokations with different versions of a library for
an example where this could go wrong).
Guix-managed Python packages (libraries nor applications) should
generally not pick up dependencies from random paths – only those
from their package description, so we can keep Guix’ promise of being
self-contained.
I have experimented with customizing Python’s importing mechanism
through a custom MetaPathFinder. It works by adding a __guix_pythonpath__
variable to every Python package’s __init__.py file and modifying the
module loader’s search path accordingly if such a variable exists. It
would provide exactly that guarantee, but it’s just a PoC at this
point – see attached file.
Apart from that I don’t see a good short-term solution right now. It’s
just how Python works.
Cheers,
Lars
# Credits to
#
https://tenthousandmeters.com/blog/python-behind-the-scenes-11-how-the-python-import-system-works/
# for the very good explanation of how Python’s import statement works.
import sys, os
from importlib.abc import MetaPathFinder
from importlib.machinery import SourceFileLoader, ModuleSpec, PathFinder
class GuixPythonFinder (MetaPathFinder):
def find_spec (self, fullname, path, target=None):
# Short-circuit for non-top-level imports, which already have a path.
if path:
return None
attrname = '__guix_pythonpath__'
searchPath = None
# Search for our caller.
frame = sys._getframe ()
while frame:
# If he has a search path, use it. This is mainly for executable
# scripts with `__name__ == '__main__'`.
searchPath = frame.f_globals.get (attrname, None)
if not searchPath:
# Otherwise check the top-level package for search paths
# declared in __init__.py
package = frame.f_globals.get ('__package__')
if package:
module = sys.modules.get (package)
if module:
searchPath = getattr (module, attrname, None)
if searchPath is not None:
break
frame = frame.f_back
# If we have a caller…
if searchPath is not None:
return PathFinder.find_spec (fullname, searchPath, target=target)
else:
# Otherwise we’re not responsible for this module.
return None
sys.meta_path.insert (0, GuixPythonFinder ())
bug#62956: [PATCH] Updates for python-k5test and python-gssapi
Hi, > just bumping this thread. ik there's a lot to be done since the > core-updates merge but I wanted to make sure this wasn't forgotten > about. haven't been able to contact some friends in a few weeks. I already bumped k5test and gssapi independently and just added python-idna to gajim. Looks like it builds and starts. Cheers, Lars
bug#63514: alacritty>=0.12.0 does not work with Wayland
Hi, > easy reproducer: 'DISPLAY="" alacritty' gives the same error. that’s exactly what I used under Wayland, otherwise it’ll fall back to XWayland with ugly font rendering (because of my hidpi monitor). > Do you know if the X11 error is also a problem? Not sure what you mean. As I wrote it works with XWayland, so I’m guessing X11 is not broken. Thank you, Lars PS: What *is* entirely broken is swaylock, which also got updated recently: wl_registry@2: error 0: invalid version for global wl_output (39): have 3, wanted 4 signature.asc Description: PGP signature
bug#63514: alacritty>=0.12.0 does not work with Wayland
Hi Efraim, since the upgrade from alacritty 0.9 to 0.12 it does not work any more with the DISPLAY environment variable unset (i.e. without xwayland). The error message is: thread 'main' panicked at 'Failed to initialize any backend! Wayland status: NoWaylandLib X11 status: XOpenDisplayFailed', /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9 Could you have a look? Thanks, Lars signature.asc Description: PGP signature
bug#63156: guix package -u failure on pyopengl-accelerate-3.1.5
Hi, I discovered this issue independently and fixed it in commit 3d05d549184d5399d2949535cf5cad8b92b263dd. Cheers, Lars
bug#58485: [shepherd] Restarting guix-publish fails
Hi, > Can you confirm nothing else is competing to bind port on that > machine? not sure how to confirm that with certainty (it’s hard to get an lsof in the exact right moment), but according to the OS config only SSHd is supposed to use port , see [1]. [1] https://github.com/leibniz-psychology/psychnotebook-deploy/blob/master/src/zpid/machines/patna/os.scm Cheers, Lars -- Lars-Dominik Braun Wissenschaftlicher Mitarbeiter/Research Associate www.leibniz-psychology.org ZPID - Leibniz-Institut für Psychologie / ZPID - Leibniz Institute for Psychology Universitätsring 15 D-54296 Trier - Germany Tel.: +49–651–201-4964 signature.asc Description: PGP signature
bug#62442: Latest Guix binary download permission issues
Hi, as noted in [1] the latest Guix binary (tar.xz) from CI has the following directory entry: drwx-- root/root 0 1970-01-01 01:00 ./ When installing this tarball using guix-install.sh the system will be bricked instantly, because the `tar -xf` command does not include --no-overwrite-dir, causing / to become readable only for the root user. Cheers, Lars [1] https://github.com/PromyLOPh/guix-install-action/issues/20
bug#62071: openjdk@9/10 sources not reproducible
Hi, it looks like the (auto-generated) tarballs for openjdk@9 and openjdk@10 changed their hash, causing a hash mismatch via guix build -S openjdk@9 --no-substitutes --no-grafts I’m not sure why it uses these tarballs in the first place, since we have a hg-download. Lars
bug#58485: [shepherd] Restarting guix-publish fails
Hi Ludo,
> Can you confirm shepherd (PID 1) is 0.9.3?
it is:
root 1 0.2 0.2 308148 76816 ?Sl Feb07 52:08
/gnu/store/kphp5d85rrb3q1rdc2lfqc1mdklwh3qp-guile-3.0.9/bin/guile
--no-auto-compile
/gnu/store/4nw0zb4swga0cb8i35nvng3rg6z5qm8p-shepherd-0.9.3/bin/shepherd
--config /gnu/store/cvrai6z8777jf7860rnvppfznl1lcxi1-shepherd.conf
> ‘sudo herd restart ssh-daemon’ works fine on my laptop FWIW.
This works fine too. Only unattended-upgrades seems to have this issue :/
The strace looks unsuspicious right now:
---snip---
1 14:12:15.117035 read(21, "(shepherd-command (version 0) (action restart)
(service ssh-daemon) (arguments ()) (directory \"/root\"))", 1024) = 103
1 14:12:15.117254 close(27) = 0
1 14:12:15.117283 close(30) = 0
1 14:12:15.117416 newfstatat(AT_FDCWD, "/etc/localtime",
{st_dev=makedev(0x8, 0x2), st_ino=110100491, st_mode=S_IFREG|0444, st_nlink=1,
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, s
t_size=2298, st_atime=1676898665 /* 2023-02-20T14:11:05.338746772+0100 */,
st_atime_nsec=338746772, st_mtime=1676898664 /*
2023-02-20T14:11:04.874743456+0100 */, st_mtime_nsec=874743456, st_c
time=1676898664 /* 2023-02-20T14:11:04.874743456+0100 */,
st_ctime_nsec=874743456}, 0) = 0
1 14:12:15.117475 write(17, "shepherd[1]: Service ssh-daemon has been
stopped.\n", 50) = 50
1 14:12:15.117524 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK,
IPPROTO_IP) = 26
1 14:12:15.117561 setsockopt(26, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
1 14:12:15.117598 bind(26, {sa_family=AF_INET, sin_port=htons(),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
1 14:12:15.117724 write(21, "(reply (version 0) (result #f) (error (error
(version 0) action-exception start ssh-daemon system-error (\"bind\" \"~A\"
(\"Address already in use\") (98 (messages (\"Service ssh-daemon has been
stopped.\")))", 204) = 204
1 14:12:15.117754 close(21) = 0
---snap---
But nginx seems to have the same issue, except that it does not fail
entirely and succeeds after waiting a short period of time:
---snip---
2023/02/20 14:12:14 [notice] 7136#0: signal 15 (SIGTERM) received from 6644,
exiting
2023/02/20 14:12:14 [notice] 7137#0: exiting
2023/02/20 14:12:14 [notice] 7137#0: exit
2023/02/20 14:12:14 [notice] 7136#0: signal 17 (SIGCHLD) received from 7137
2023/02/20 14:12:14 [notice] 7136#0: worker process 7137 exited with code 0
2023/02/20 14:12:14 [emerg] 6645#0: bind() to 0.0.0.0:443 failed (98: Address
already in use)
2023/02/20 14:12:14 [emerg] 6645#0: bind() to 0.0.0.0:80 failed (98: Address
already in use)
2023/02/20 14:12:14 [emerg] 6645#0: bind() to [::]:80 failed (98: Address
already in use)
2023/02/20 14:12:14 [notice] 7136#0: exit
2023/02/20 14:12:14 [notice] 6645#0: try again to bind() after 500ms
2023/02/20 14:12:14 [notice] 6645#0: using the "epoll" event method
2023/02/20 14:12:14 [notice] 6645#0: nginx/1.23.3
2023/02/20 14:12:14 [notice] 6645#0: OS: Linux 6.1.9
2023/02/20 14:12:14 [notice] 6645#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2023/02/20 14:12:14 [notice] 6648#0: start worker processes
2023/02/20 14:12:14 [notice] 6648#0: start worker process 6649
2023/02/20 14:12:32 [info] 6649#0: epoll_wait() failed (4: Interrupted system
call)
---snap---
I see we’re already using SO_REUSEADDR, so all of this is a bit of a
mystery to me.
Thanks,
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
signature.asc
Description: PGP signature
bug#58485: [shepherd] Restarting guix-publish fails
Hi Ludo,
> Indeed. This is fixed by Shepherd commit
> d97592f58603ff51cb280ae57d413c8731e601b3, which will be in the upcoming
> 0.9.3 release.
I’m on 0.9.3 and it works fine with `herd restart` now. But ssh-daemon
has the same issue when being restarted by unattended-upgrades (which
is fatal, because unable to use SSH I have to restart the entire box):
---snip---
shepherd: Service nginx has been stopped.
shepherd: Service nginx has been started.
shepherd: Service collectd has been stopped.
shepherd: Service collectd has been started.
shepherd: Service ntpd has been stopped.
shepherd: Service ntpd has been started.
shepherd: Service guix-publish has been stopped.
shepherd: Service guix-publish has been started.
shepherd: Service ssh-daemon has been stopped.
Backtrace:
7 (primitive-load "/gnu/store/ip5m1n8kb6p0rfglzpkk17k060a?")
In ice-9/boot-9.scm:
724:2 6 (call-with-prompt ("prompt") # ?)
1752:10 5 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/eval.scm:
619:8 4 (_ #(#(#)))
In ice-9/boot-9.scm:
260:13 3 (for-each # _)
In gnu/services/herd.scm:
168:4 2 (invoke-action ssh-daemon restart () #)
176:7 1 (failure)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
1. :
service: ssh-daemon
action: start
key: system-error
args: ("bind" "~A" ("Address already in use") (98)
---snap---
Maybe I can strace herd and see what happens exactly.
Thanks,
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
signature.asc
Description: PGP signature
bug#61055: file-needed/recurive does not canonicalize paths
Hi Ludo, > Can you see how we end up with those entries? These at DT_NEEDED > entries, not DT_RUNPATH, right? they definitely do not come from the hindent binary. `readelf -d` looks like this ---snip--- 0x0001 (NEEDED) Shared library: [libHSpath-io-1.7.0-Y7nuUr9RcCC0rgElOk2Zd-ghc9.2.5.so] 0x0001 (NEEDED) Shared library: [libHSunix-compat-0.5.4-2Fa5hW7FPv81iCQxP5gtt5-ghc9.2.5.so] 0x0001 (NEEDED) Shared library: [libHStemporary-1.3-K9lHfUrZ43CE7BhnE8cSVB-ghc9.2.5.so] … 0x001d (RUNPATH)Library runpath: [/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/lib/x86_64-linux-ghc-9.2.5:/gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0:/gnu/store/lk1mgbds7rf9ilv425msz840ky8cfn79-ghc-diff-0.4.1/lib/x86_64-linux-ghc-9.2.5:/gnu/store/866s8qcghallds7azzcx075a06mr64h4-ghc-hunit-1.6.2.0/lib/x86_64-linux-ghc-9.2.5:/gnu/store/rgm9h2a4v1zgwm1mbfb36ycjbkywlxj6-ghc-onetuple-0.3.1/lib/x86_64-linux-ghc-9.2.5:… ---snap--- and I believe GHC adds `-L/gnu/store/…` and `-lHSXXX` to the linker invokation only, which should be correct. However GHC’s bundled libraries are linked differently and result in a `readelf -d /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/libHSCabal-3.6.3.0-ghc9.2.5.so` like this: ---snip--- 0x0001 (NEEDED) Shared library: [libHSprocess-1.6.16.0-ghc9.2.5.so] 0x0001 (NEEDED) Shared library: [libHSparsec-3.1.15.0-ghc9.2.5.so] 0x0001 (NEEDED) Shared library: [libHStext-1.2.5.0-ghc9.2.5.so] … 0x001d (RUNPATH)Library runpath: [$ORIGIN/../process-1.6.16.0:$ORIGIN/../parsec-3.1.15.0:$ORIGIN/../text-1.2.5.0:$ORIGIN/../mtl-2.2.2:$ORIGIN/../transformers-0.5.6.2:$ORIGIN/../directory-1.3.6.2:$ORIGIN/../unix-2.7.2.2:$ORIGIN/../time-1.11.1.1:$ORIGIN/../filepath-1.4.2.2:$ORIGIN/../binary-0.8.9.0:$ORIGIN/../containers-0.6.5.1:$ORIGIN/../bytestring-0.11.3.1:$ORIGIN/../template-haskell-2.18.0.0:$ORIGIN/../pretty-1.1.3.6:$ORIGIN/../ghc-boot-th-9.2.5:$ORIGIN/../deepseq-1.4.6.1:$ORIGIN/../array-0.5.4.0:$ORIGIN/../base-4.16.4.0:$ORIGIN/../ghc-bignum-1.2:$ORIGIN/../ghc-prim-0.8.0:$ORIGIN/../rts:/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib:/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1/lib:/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..] ---snap--- These obviously will get expanded to /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/../process-1.6.16.0 And there’s about 40 of these bundled libraries referencing each other, which is why the problem is amplified. I still believe this is a bug in file-needed/recursive, because it recurses, but does not correctly keep track of “visited” shared libraries (by not canonicalizing paths). Its documentation also says that it returns a “list of absolute .so file names” – which I would expect not to have relative path elements in. The output of `ldd` does so too. So yes, canonicalize-path may be expensive, but evaluating 1 shared libraries is too. Cheers, Lars PS: This is not a problem for wip-haskell any more, since I switched to static linking, but it’s going to bite someone else.
bug#61055: file-needed/recurive does not canonicalize paths
Hi, (CC-ing Ludo, who wrote the code according to git logs) during testing of wip-haskell I observed the make-dynamic-linker-cache phase is taking alot of time (up to two minutes on a fast machine with SSD). Looking at ghc-hindent for example [1]: starting phase `make-dynamic-linker-cache' created '/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/etc/ld.so.cache' from 10085 library search path entries phase `make-dynamic-linker-cache' succeeded after 119.5 seconds And while Haskell packages link to a pretty large number of dynamic libraries (116 in this case), 1 search path entries seems wrong. Running just (file-needed/recursive "/gnu/store/2nrzbaxmqs2rq9yv52bpyn2azb3qj6h1-ghc-hindent-5.3.4/bin/hindent") takes a long time and reveals entries like /gnu/store/1cyk8j2nd6r0cvm6kx1408kd763yf8h5-ghc-9.2.5/lib/ghc-9.2.5/Cabal-3.6.3.0/../directory-1.3.6.2/../unix-2.7.2.2/../bytestring-0.11.3.1/../template-haskell-2.18.0.0/../pretty-1.1.3.6/../array-0.5.4.0/../base-4.16.4.0/../ghc-bignum-1.2/../ghc-prim-0.8.0/libHSghc-prim-0.8.0-ghc9.2.5.so so it looks like it deduplicates values, but does not canonicalize paths. A relatively straight-forward fix could be the following change, but I don’t know if that would cause any issues, since canonicalize-path throws an exception if the resulting path does not exist. It’s also a world rebuild since pretty much any package uses this phase (and the reason and I cannot test it on a larger scale). ---snip--- diff --git a/guix/build/gremlin.scm b/guix/build/gremlin.scm index 2a74d51dd9..6eb8f688ea 100644 --- a/guix/build/gremlin.scm +++ b/guix/build/gremlin.scm @@ -285,8 +285,8 @@ (define (file-needed/recursive file) (if (and runpath needed) (let* ((runpath (map (cute expand-origin <> (dirname file)) runpath)) - (resolved (map (cut search-path runpath <>) - needed)) + (resolved (map (lambda (x) (and=> x canonicalize-path)) (map (cut search-path runpath <>) + needed))) (failed (filter-map (lambda (needed resolved) (and (not resolved) (not (libc-library? needed)) ---snap--- Cheers, Lars [1] https://ci.guix.gnu.org/build/366156/log/raw
bug#55178: ghc cannot find libraries of ghc-comonad
Hi, > > guix shell --pure ghc ghc-comonad gcc-toolchain -- ghc LinkMe.hs > [1 of 1] Compiling Main ( LinkMe.hs, LinkMe.o ) > Linking LinkMe ... > ld: cannot find -lHScomonad-5.0.8-KDPzf2kORSz9Qeif8nQH6d > ld: cannot find -lHStransformers-compat-0.6.6-9ADqfwGTALm8Nq2ZeUpa4p > ld: cannot find -lHSindexed-traversable-0.1.1-Dfr00dUbJtB3rFEVdhtcE9 > ld: cannot find -lHSdistributive-0.6.2.1-L7rr3EplzD03NITUnJxmCO > ld: cannot find -lHStagged-0.8.6.1-EiQY3za6Q5HE9cdvqupke2 > ld: cannot find -lHSbase-orphans-0.8.5-Iz1X6ZIULaHC76vf03czEu > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) the problem here is that in Guix we link Haskell executables dynamically and sometimes move static libraries to a separate output without updating the config file (because otherwise it would create a reference, which we’re trying to avoid to save space). It works fine for me using guix shell --pure ghc ghc-comonad gcc-toolchain@10 -- ghc --make -dynamic -v LinkMe.hs Cheers, Lars
bug#34227: Non-deterministic GHC build errors
None of these are actual errors, but warnings. I’ve built a ton of Haskell packages and never encountered transient errors.
bug#45055: cabal-install does not work with default ghc
GHC 8.8 is not the default any more.
bug#38790: ghc-doc is not reproducible
Not applicable to GHC 9.2 any more.
bug#60879: `guix pull` profile reproducibility issues
Hi,
here at ZPID we “cache” Guix pull profiles (via `guix pull -p`) in project
directories, which can be shared between users. I’ve been trying to
ensure that a given Guix pull profile corresponds to a given channels.scm
file, i.e. it has not been tampered with, because calls to the Guix binary
currently run outside of the project sandbox (`guix shell -C`). Doing
so I discovered two reproducibility issues:
1) `guix pull` and `guix time-machine` currently do not produce the same
Guix profile, even with exactly the same channels.scm
file. Unfortunately time-machine does not print the profile path
anywhere, but this can be reproduced implicitly by looking at the
output of cached-channel-instance, which the time-machine uses. Looking
at `guix describe` vs `guix time-machine -C channels.scm -- describe`
reveals a reversed channel order. Thus channel order matters when
using a channels.scm, when it really should not.
2) `guix pull` seems to depend on the host `guix` and produces
different profile paths depending on which `guix` command
was used to pull. In the following example `guix` is at commit
f094c3831f382b7299a2aaa04d85f4b27320e9ec and we’re pulling commit
5fd9d3ba82faddf8393027655d4a10a1562dac47 through the attached
channels.scm. These commits were selected carefully, because the
problem is more likely for older commits pulled from newer commits.
$ guix pull -C channels.scm -p guix-level1
$ ./guix-level1/bin/guix pull -C channels.scm -p guix-level2
$ readlink -f guix-level1
/gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile
$ readlink -f guix-level2
/gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile
$ diffoscope guix-level1 guix-level2
[…]
│ │ --- guix-level1/etc/profile
│ ├── +++ guix-level2/etc/profile
│ │ @@ -4,8 +4,8 @@
│ │ #
│ │ # GUIX_PROFILE=/path/to/profile ; \
│ │ # source /path/to/profile/etc/profile
│ │ #
│ │ # When GUIX_PROFILE is undefined, the various environment variables
refer
│ │ # to this specific profile generation.
│ │
│ │ +export
PATH="${GUIX_PROFILE:-/gnu/store/4gyv6m8v47f6wpmrq86iy6wgvivm2sh8-profile}/bin${PATH:+:}$PATH"
│ │ -export
PATH="${GUIX_PROFILE:-/gnu/store/3fr7rlx9hm29a5c0mh0lnxpqg8prfvw7-profile}/bin${PATH:+:}$PATH"
The only visible difference is the adjusted PATH, which means there
actually is no difference. Pulling again from level2 results in the
same profile as level2, so clearly something is leaking from our
original `guix` into level1. The .drv files for both reveal that
fonts-dir.drv is different, because mkfontdir and mkfontscale
differ. These are part of the profile generation code, which apparently
comes from the host Guix, when the newly built Guix should be used.
Cheers,
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
bug#60200: Incompatibilities between gcc-toolchain and R packages
Hi Simon,
> 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.
minor nit-pick: Not the command-line, but everything that uses
specifications. So manifests via SPECIFICATIONS->MANIFEST are also
affected, see:
(use-modules (gnu packages) (guix profiles))
(manifest-entries (specifications->manifest '("gcc-toolchain")))
$2 = (#< name: "gcc-toolchain" version: "12.2.0" …)
The -next suffix has the obvious disadvantage that specifications may
become invalid as we move -next to the “regular” package. So maybe
marking packages “default” like the attached patch does could improve
the current situation. Not just for gcc, but also Haskell and Python
come to mind.
Cheers,
Lars
diff --git a/gnu/packages.scm b/gnu/packages.scm
index 61345f75a9..7e5a6d49c2 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -356,20 +356,24 @@ (define cache
(find-packages-by-name/direct name version
(define (find-best-packages-by-name name version)
- "If version is #f, return the list of packages named NAME with the highest
-version numbers; otherwise, return the list of packages named NAME and at
-VERSION."
+ "If version is #f, return the list of packages named NAME with only
+packages marked default? or, if none exist, the highest version numbers;
+otherwise, return the list of packages named NAME and at VERSION."
(if version
(find-packages-by-name name version)
(match (find-packages-by-name name)
(()
'())
((matches ...)
- ;; Return the subset of MATCHES with the higher version number.
- (let ((highest (package-version (first matches
- (take-while (lambda (p)
- (string=? (package-version p) highest))
- matches))
+ ;; Return the subset of MATCHES which are marked default or those with
+ ;; the higher version number.
+ (let ((highest (package-version (first matches)))
+ (default (filter (lambda (p) (assoc-ref (package-properties p)
'default?)) matches)))
+ (if (not (null? default))
+ default
+ (take-while (lambda (p)
+ (string=? (package-version p) highest))
+ matches)))
;; Prevent Guile 3 from inlining this procedure so we can mock it in tests.
(set! find-best-packages-by-name find-best-packages-by-name)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..2d5e0add26 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc
("libc-static" ,libc "static"))
(define-public gcc-toolchain
- (make-gcc-toolchain gcc-final))
+ (let ((parent (make-gcc-toolchain gcc-final)))
+(package
+ (inherit parent)
+ (properties (alist-cons 'default? #t (package-properties parent))
(define-public gcc-toolchain-4.8
(make-gcc-toolchain gcc-4.8))
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#58485: [shepherd] Restarting guix-publish fails
Hi, > Ahh, so the issue is that shepherd waits neither for the process to be > actually killed nor for the socket to become available, isn't it? I would argue it’s the former, but having either of them would solve the problem, I think. Lars
bug#58485: [shepherd] Restarting guix-publish fails
Hi Liliana, > Shouldn't [1] address this very issue? > [1] > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2 no, if the process is running make-systemd-destructor is just an alias for make-kill-destructor. So it does not matter which one we use in this case. Lars
bug#58485: [shepherd] Restarting guix-publish fails
Hi,
it seems that `herd restart guix-publish` stopped working after the
introduction of socket activation into shepherd. This is a problem,
because I restart guix-publish automatically after unattended-upgrades. It
fails with the following error for me:
---snip---
Backtrace:
7 (primitive-load "/gnu/store/7xrg2sbb529ki6hv99n27svg0fi?")
In ice-9/boot-9.scm:
724:2 6 (call-with-prompt ("prompt") # ?)
1752:10 5 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/eval.scm:
619:8 4 (_ #(#(#)))
In ice-9/boot-9.scm:
260:13 3 (for-each # _)
In gnu/services/herd.scm:
168:4 2 (invoke-action guix-publish restart () #)
176:7 1 (failure)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
1. :
service: guix-publish
action: start
key: system-error
args: ("bind" "~A" ("Address already in use") (98))
---snap---
Note that due to the socket activation you must visit the URL at least
once to start up the guix-publish process. Otherwise a restart will
work fine. It also works fine the second time I invoke `herd restart
guix-publish`, because `guix-publish` is dead by that time.
Looking at an strace shepherd is indeed trying to kill `guix-publish`
and re-bind to the same address:
---snip---
1 read(23, "(shepherd-command (version 0) (action restart) (service
guix-publish) (arguments ()) (directory \"/root\"))", 1024) = 105
1 getpgid(18096)= 18096
1 getpgid(0)= 0
1 kill(-18096, SIGTERM) = 0
1 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444,
st_size=2298, ...}, 0) = 0
1 write(17, "shepherd[1]: Service guix-publish has been stopped.\n", 52) =
52
1 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 36
1 setsockopt(36, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
1 bind(36, {sa_family=AF_INET, sin_port=htons(8082),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)
1 write(23, "(reply (version 0) (result #f) (error (error (version 0)
action-exception start guix-publish system-error (\"bind\" \"~A\" (\"Address
already in use\") (98 (messages (\"Service guix-publish has been
stopped.\")))", 208) = 208
1 close(23)
---snap---
The obvious explanation would be that stopping does not wait for the
process to actually exit. make-kill-destructor does not waitpid it seems
and 'running is set unconditionally to #f after 'stop has finished.
Cheers,
Lars
bug#57272: libvirt 8.6 fails to start network
Hi,
after the update to libvirt 8.6.0 in
3a76c2bfd94557c9776aa11240fec14580aec1b0 networks don’t start any more:
> LANG=C virsh net-start default
error: Failed to start network default
error: Unable to find 'dnsmasq' binary in $PATH: No such file or directory
I tried to patch dnsmasq’s path like follows, but then the testcase
networkxml2conftest fails and cannot find dnsmasq either.
---snip---
diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index d451b8529e..89507774cb 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -1311,6 +1311,12 @@ (define-public libvirt
(substitute* "scripts/meson-install-dirs.py"
(("destdir = .*")
"destdir = '/tmp'"
+ (add-after 'unpack 'fix-paths
+(lambda* (#:key inputs #:allow-other-keys)
+ (let ((dnsmasq (search-input-file inputs "sbin/dnsmasq")))
+(substitute* "src/util/virdnsmasq.c"
+ (("#define DNSMASQ \"dnsmasq\"")
+ (string-append "#define DNSMASQ \"" dnsmasq "\""))
(add-before 'configure 'disable-broken-tests
(lambda _
(let ((tests (list "commandtest" ; hangs idly
---snap---
I’m not sure what the problem might be.
Lars
bug#56864: qutebrowser: wrap-qt-process-path phase wrong type to string-append
Hi Maxim, > Yep, that did it. > > Fixed in aea756ea3312ba7e8229804492ba12001c8de568. this does not fix the build of lyx and twinkle for me, which both fail at 'qt-wrap: ---snip--- starting phase `qt-wrap' error: in phase 'qt-wrap': uncaught exception: wrong-type-arg "substring" "Wrong type argument in position ~A (expecting ~A): ~S" (1 "string" #f) (#f) phase `qt-wrap' failed after 0.0 seconds Backtrace: 9 (primitive-load "/gnu/store/gm47sv2ndfg906vkdr68nbv7zsi…") In guix/build/gnu-build-system.scm: 906:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #) In ice-9/boot-9.scm: 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In srfi/srfi-1.scm: 634:9 6 (for-each # …) In ice-9/boot-9.scm: 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _) In guix/build/gnu-build-system.scm: 927:23 4 (_) In guix/build/qt-utils.scm: 148:22 3 (wrap-all-qt-programs #:inputs _ #:outputs _ #:qtbase _ …) In unknown file: 2 (string-drop #f 44) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure substring: Wrong type argument in position 1 (expecting string): #f ---snap--- Maybe a different incarnation of the same issue? Lars
bug#56343: ‘tests/services/telephony.scm’ fails to run
Hi Maxim, > It isn't obsolete, but I had forgotten there were both unit and functional > (system) tests for our Jami seevice. It's probably easy to adjust, I can look > into it when I'm back from travels in a few days. I had to remove tests/services/telephony.scm from Makefile.am, so we could update the guix package to fix other issues. Please revert c23e0aa65d511a29f31da876f905594c0f8bce00 once you’ve fixed the tests. Thanks, Lars
bug#52152: Haskell Hackage importer can create dependency cycles
Hi, this issue has been fixed in commit dedfcaa8e2b948124f76121b9062c827fe649e29. Cheers, Lars
bug#54752: import: hackage: `elif` conditionals not supported
Hi, fix pushed to master in commit 2c5d18e421e6c06f4a969f98585ec41aae8eb2e4. Cheers, Lars
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hi, fix pushed to master as c3fbaee34548fbfb1617dc7fccc94c598efbd7a6 and following. Cheers, Lars
bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.
Hi Liliana, > I think grafts would fix your problem, no? That is instead of defining > a "bootstrap" variant, you'd simply add texlive-latex-base/fixed as a > replacement to texlive-latex-base. from my understanding no, because latex-babel indirectly depends on texlive-latex-base. (Through texlive-build-system, since trivial? is false and thus gnu-build-system is *not* used.) Cheers, Lars
bug#55723: [PATCH] doc: Warn about LUKS2-encrypted boot not working with GRUB.
Hi Josselin,
> +Note also that having @file{/boot/} reside on a LUKS2-encrypted device
> +is currently unsupported because of a GRUB 2.06 bug, see
> +@url{https://issues.guix.gnu.org/55723, bug #55723}. The graphical
> +installer defaults to LUKS1 for this reason.
instead of adding yet another exception, why not just document how
to do it with LUKS1, which – as I understand it – works without
these quirks?
Cheers,
Lars
bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.
Hi Ricardo, > The correct solution to this problem would be to add a little build > cycle: build a bootstrap version of pdflatex (and the other formats) so > that we can build babel; then rebuild pdflatex (and all the other > formats, and everything that goes into texlive-latex-base) in an > environment where babel exists. indeed, adding this package variation to the manifest fixed the issue for me: ---snip--- (define-public texlive-latex-base-fixed (package (inherit texlive-latex-base) (name "texlive-latex-base-fixed") (propagated-inputs (modify-inputs (package-propagated-inputs texlive-latex-base) (append texlive-babel) ---snap--- Looking at `guix refresh -l texlive-latex-base` a change like that would be a world rebuild though. I tried adding something similar to Guix’ tree, but there’s a loop somewhere I can’t figure out (see attached patch). I’m guessing through texlive-build-system’s #:texlive-latex-base. Cheers, Lars diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm index 4831cf0933..703846a1ad 100644 --- a/gnu/packages/tex.scm +++ b/gnu/packages/tex.scm @@ -2943,9 +2943,9 @@ (define-public texlive-latexconfig formats.") (license license:lppl))) -(define-public texlive-latex-base +(define-public texlive-latex-base-bootstrap (let ((template (simple-texlive-package - "texlive-latex-base" + "texlive-latex-base-bootstrap" (list "/doc/latex/base/" "/source/latex/base/" ;; Almost all files in /tex/latex/base are generated, but @@ -3174,6 +3174,18 @@ (define-public texlive-latex-base contain.") (license license:lppl1.3c+ +(define-public texlive-latex-base + (let ((base texlive-latex-base-bootstrap)) +(package + (inherit base) + (name "texlive-latex-base") + (arguments + `(#:texlive-latex-base texlive-latex-base-bootstrap + ,@(package-arguments base))) + (propagated-inputs +(modify-inputs (package-propagated-inputs base) + (append texlive-babel)) + (define-public texlive-latex-atveryend (package (inherit (simple-texlive-package
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hi Philip, > Aha. Let me know if there's anything I can do to help. at this point there’s two options: 1) We manually update all packages coming from Stackage (i.e. run `guix refresh -t stackage` and adjust #:cabal-revision/inputs by hand) 2) We improve the updater so it automatically adjusts the entire package – not just version and source – and then run `guix refresh`. 1 is more labor-intensive, but 2 might take more time to figure out. Which option can you help with? Thanks, Lars
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hey, > Indeed, that seems to work for those packages, but it still doesn't seem to > work for OneTuple, as mentioned here: I’m attaching a patch for that, please have a look. I’ll merge these into master, since they don’t change any builds. > Aha! The upgrade to GHC 9.0.0 caused ghc-hashable to break. I suppose many > other packages could be broken as well. I didn’t actually upgrade any packages on wip-haskell yet, so it’s likely they fail with a newer GHC than 8.10. Cheers, Lars >From 261736187d51c85c203ad08fbc1ae89340256a8c Mon Sep 17 00:00:00 2001 From: Lars-Dominik Braun Date: Thu, 2 Jun 2022 13:52:08 +0200 Subject: [PATCH] import: hackage: Filter upper/mixed case dependencies too. * guix/import/hackage.scm (filter-dependencies): Convert OWN-NAMES to lowercase before filtering. (hackage-module->sexp): Remove #f from OWN-NAMES, which is used for unnamed (default) libraries. * tests/hackage.scm (test-cabal-internal-library-ignored): Add mismatched uppercase letters. --- guix/import/hackage.scm | 8 +--- tests/hackage.scm | 7 --- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/guix/import/hackage.scm b/guix/import/hackage.scm index 6e982366cf..878a7d2f9c 100644 --- a/guix/import/hackage.scm +++ b/guix/import/hackage.scm @@ -227,9 +227,10 @@ (define (filter-dependencies dependencies own-names) list with the names of dependencies. OWN-NAMES is the name of the Cabal package being processed and its internal libaries and is used to filter references to itself." - (filter (lambda (d) (not (member (string-downcase d) + (let ((ignored-dependencies (map string-downcase (append own-names ghc-standard-libraries - dependencies)) +(filter (lambda (d) (not (member (string-downcase d) ignored-dependencies))) +dependencies))) (define* (hackage-module->sexp cabal cabal-hash #:key (include-test-dependencies? #t)) @@ -250,7 +251,8 @@ (define source-url (hackage-source-url name version)) (define own-names (cons (cabal-package-name cabal) - (map cabal-library-name (cabal-package-library cabal + (filter (lambda (x) (not (eqv? x #f))) +(map cabal-library-name (cabal-package-library cabal) (define hackage-dependencies (filter-dependencies (cabal-dependencies->names cabal) own-names)) diff --git a/tests/hackage.scm b/tests/hackage.scm index a11dd14846..ad2ee4b7f9 100644 --- a/tests/hackage.scm +++ b/tests/hackage.scm @@ -368,7 +368,8 @@ (define test-cabal-no-final-newline (test-assert "hackage->guix-package test without final newline" (eval-test-with-cabal test-cabal-no-final-newline match-ghc-foo)) -;; Make sure internal libraries will not be part of the dependencies. +;; Make sure internal libraries will not be part of the dependencies, +;; ignore case. (define test-cabal-internal-library-ignored "name: foo version: 1.0.0 @@ -379,8 +380,8 @@ (define test-cabal-internal-library-ignored executable cabal build-depends: HTTP >= 4000.2.5 && < 4000.3, -internal -library internal +internAl +library internaL build-depends: mtl>= 2.0 && < 3 ") -- 2.35.1
bug#55723: Full disk encryption with grub-efi and LUKS2
Hi, I followed the manual to manually install Guix with full disk encryption using LUKS2 and PBKDF2. However this leaves me with an unbootable system, stuck at Grub’s rescue prompt, because `grub-install` apparently does not know how to detect a LUKS2 target and therefore does not include the modules required to open the encrypted volume in the EFI image. See [1]. I managed to manually create a core.img with the help of ArchLinux’ Wiki[2] (see also [3]), boot into the system and reconfigure with a modified bootloader: ---snip--- (define install-grub-efi-mkimage "Create an Grub EFI image with included cryptomount support for luks2, which grub-install does not handle yet." #~(lambda (bootloader efi-dir mount-point) (when efi-dir (let ((grub-mkimage (string-append bootloader "/bin/grub-mkimage")) ;; Required modules, YMMV. (modules (list "luks2" "part_gpt" "cryptodisk" "gcry_rijndael" "pbkdf2" "gcry_sha256" "ext2")) (prefix (string-append mount-point "/boot/grub")) ;; Different configuration required to set up a crypto ;; device. Change crypto_uuid to match your output of ;; `cryptsetup luksUUID /device`. ;; XXX: Maybe cryptomount -a could work? (config #$(plain-file "grub.cfg" "set crypto_uuid=755e547f78f44dc38dab58399e1780a6 cryptomount -u $crypto_uuid set root=crypto0 set prefix=($root)/boot/grub insmod normal normal")) (target-esp (if (file-exists? (string-append mount-point efi-dir)) (string-append mount-point efi-dir) efi-dir))) (apply invoke (append (list grub-mkimage "-p" prefix "-O" "x86_64-efi" "-c" config "-o" (string-append target-esp "/EFI/Guix/grubx64.efi")) modules)) (define grub-efi-bootloader-luks2 (bootloader (inherit grub-efi-bootloader) (name 'grub-efi-luks2) (installer install-grub-efi-mkimage))) ---snap--- Supposedly there are also patches for grub-mkimage, but maybe we can include a workaround like the above by default until then or remove the section about LUKS2 entirely? Cheers, Lars [1] https://logs.guix.gnu.org/guix/2022-05-27.log#111808 [2] https://wiki.archlinux.org/title/GRUB#LUKS2 [3] https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot
bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.
Hi Ricardo,
this problem is biting me too now.
> > % This line is new. Set the language!
> > \usepackage[british]{babel}
>
> It is in fact sufficient to add only this line
>
>\def\languagename{english}
>
This workaround only works fine for scrlttr2, but unfortunately not for
scrbook, scrartcl, … Any idea?
Cheers,
Lars
bug#54752: import: hackage: `elif` conditionals not supported
Hi Philip,
thank you!
> Unfortunately, building raaz still fails (first because of the description,
> then because some internal libraries are added as external dependencies, and
> then for... other reasons I haven't figured out. But all of those are
> separate issues.
You’re right, it fails with this error for me, which indicates
haskell-build-system has a bug _somewhere_.
---snip---
starting phase `register'
running "runhaskell Setup.hs" with command "register" and parameters
("--gen-pkg-config=/gnu/store/8m0w1688syvcmhjr2ym1max430jmwjag-ghc-raaz-0.3.6/ghc-raaz-0.3.6.conf")
error: in phase 'register': uncaught exception:
system-error "fport_read" "~A" ("Is a directory") (21)
phase `register' failed after 6.9 seconds
Backtrace:
11 (primitive-load "/gnu/store/jpf2lwn33nq08nkqrkr5q232c51…")
In guix/build/gnu-build-system.scm:
906:2 10 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 8 (for-each # …)
In ice-9/boot-9.scm:
1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
927:23 6 (_)
In guix/build/haskell-build-system.scm:
244:23 5 (register #:name _ #:system _ #:inputs _ #:outputs _)
In ice-9/ports.scm:
433:17 4 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In ice-9/rdelim.scm:
160:18 3 (read-string _)
In unknown file:
2 (read-char #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure fport_read: Is a directory
---snap---
Cheers,
Lars
bug#54760: import: hackage: Internal libraries are not filtered out of dependency list
Hello Philip,
> The attoparsec package on hackage defines multiple internal libraries inside
> one package, named "attoparsec" and "attoparsec-internal", with the first
> depending on the latter. Importing attoparsec using `guix import hackage
> attoparsec` therefore yields the following erroneous package definition: […]
attached patches should fix this. I tried them with both, attoparsec and
raaz, and internal libraries appear neither in inputs nor native inputs
any more.
Cheers,
Lars
>From ee1e0051b15185b6d3cc808e66979369027b5e7b Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Sun, 22 May 2022 10:56:01 +0200
Subject: [PATCH 1/2] import: cabal: Support library names
* guix/import/cabal.scm (make-cabal-parser): Add name to section.
(is-lib): Add optional name to regular expression.
(lex-rx-res): Support selecting different substring.
(lex-lib): Match 2nd substring from IS-LIB.
(lex-line): Adapt to changes for lex-lib.
(cabal-library): Add name field and export CABAL-LIBRARY-NAME.
(eval): Remove special case for 'library, which is not required any more.
(make-cabal-section): Move special case for LIBRARY.
* tests/hackage.scm (test-read-cabal-library-name): New variable.
("read-cabal test 1"): Adapt testcase to changed internal structure.
("read-cabal test: library name"): New testcase.
---
guix/import/cabal.scm | 27 ++-
tests/hackage.scm | 21 -
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/guix/import/cabal.scm b/guix/import/cabal.scm
index 8f59a63cb9..4410c12500 100644
--- a/guix/import/cabal.scm
+++ b/guix/import/cabal.scm
@@ -74,6 +74,7 @@ (define-module (guix import cabal)
cabal-executable-dependencies
cabal-library?
+cabal-library-name
cabal-library-dependencies
cabal-test-suite?
@@ -189,8 +190,8 @@ (define (make-cabal-parser)
(bm-sec): (list $1))
(bm-sec (BENCHMARK OCURLY exprs CCURLY) : `(section benchmark ,$1 ,$3)
(BENCHMARK open exprs close): `(section benchmark ,$1 ,$3))
- (lib-sec (LIB OCURLY exprs CCURLY) : `(section library ,$3)
-(LIB open exprs close): `(section library ,$3))
+ (lib-sec (LIB OCURLY exprs CCURLY) : `(section library ,$1 ,$3)
+(LIB open exprs close): `(section library ,$1 ,$3))
(exprs (exprs PROPERTY) : (append $1 (list $2))
(PROPERTY) : (list $1)
(exprs elif-else) : (append $1 (list ($2 '(()
@@ -382,7 +383,8 @@ (define is-custom-setup (make-rx-matcher "^(custom-setup)"
(define is-benchmark (make-rx-matcher "^benchmark +([a-z0-9_-]+)"
regexp/icase))
-(define is-lib (make-rx-matcher "^library *" regexp/icase))
+;; Libraries can have optional names since Cabal 2.0.
+(define is-lib (make-rx-matcher "^library(\\s+([a-z0-9_-]+))?\\s*"
regexp/icase))
(define (is-else s) (string-ci=? s "else"))
@@ -476,8 +478,9 @@ (define (lex-braced-property k-rx-res loc port)
'PROPERTY loc
(list key `(,(read-braced-value port))
-(define (lex-rx-res rx-res token loc)
- (let ((name (string-downcase (match:substring rx-res 1
+(define* (lex-rx-res rx-res token loc #:optional (substring-id 1))
+ (let* ((match (match:substring rx-res substring-id))
+ (name (if match (string-downcase match) match)))
(make-lexical-token token loc name)))
(define (lex-flag flag-rx-res loc) (lex-rx-res flag-rx-res 'FLAG loc))
@@ -495,7 +498,7 @@ (define (lex-custom-setup ts-rx-res loc) (lex-rx-res
ts-rx-res 'CUSTOM-SETUP loc
(define (lex-benchmark bm-rx-res loc) (lex-rx-res bm-rx-res 'BENCHMARK loc))
-(define (lex-lib loc) (make-lexical-token 'LIB loc #f))
+(define (lex-lib lib-rx-res loc) (lex-rx-res lib-rx-res 'LIB loc 2))
(define (lex-else loc) (make-lexical-token 'ELSE loc #f))
@@ -599,7 +602,7 @@ (define (lex-line port loc)
((is-common s) => (cut lex-common <> loc))
((is-custom-setup s) => (cut lex-custom-setup <> loc))
((is-benchmark s) => (cut lex-benchmark <> loc))
- ((is-lib s) (lex-lib loc))
+ ((is-lib s) => (cut lex-lib <> loc))
(else (unread-string s port) #f
(define (lex-property port loc)
@@ -729,8 +732,9 @@ (define-record-type
(dependencies cabal-executable-dependencies)) ; list of
(define-record-type
- (make-cabal-library dependencies)
+ (make-cabal-library name dependencies)
cabal-library?
+ (name cabal-library-name)
(dependencies cabal-library-dependencies)) ; list of
(define-record-type
@@ -861,9 +865,6 @@ (define (eval sexp)
(list 'section 'flag name parameters))
(('section 'custom-setup parameters)
(list 'section 'custom-setup paramete
bug#54752: import: hackage: `elif` conditionals not supported
Hi Philip,
> Since Cabal 2.2 conditional blocks support the `elif` construct [0], but our
> hackage importer does not currently support such expressions. This causes
> importing packages like `raaz` [1] to fail.
attached patch series fixes the import for `raaz` by adding support for
elif and other minor adjustments. There still is syntax we do not support,
most importantly mixed indentation, which is already documented as xfail
via a testcase. I’m adding a few more.
Could you have a look please if these make sense?
Cheers,
Lars
>From 6b47c1d399922b60dafa01105daa1b7ea3da3935 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Sat, 30 Apr 2022 15:38:44 +0200
Subject: [PATCH 1/5] import: cabal: Support elif statement.
* guix/import/cabal.scm (make-cabal-parser): Replace if-then-else grammar case
with elif-else, modify if-then accordingly.
(is-elif): New procedure.
(lex-elif): Likewise.
(is-id): Add elif keyword.
(lex-word): Add test for elif.
* tests/hackage.scm (test-cabal-if): New variale.
(test-cabal-else): Likewise.
(test-cabal-elif): Likewise.
(test-cabal-elif-brackets): Likewise.
(match-ghc-elif): Likewise.
("hackage->guix-package test lonely if statement",
"hackage->guix-package test else statement",
"hackage->guix-package test elif statement",
"hackage->guix-package test elif statement with brackets"): New tests.
---
guix/import/cabal.scm | 63 ++
tests/hackage.scm | 102 ++
2 files changed, 136 insertions(+), 29 deletions(-)
diff --git a/guix/import/cabal.scm b/guix/import/cabal.scm
index 98d7234098..e1a082a31a 100644
--- a/guix/import/cabal.scm
+++ b/guix/import/cabal.scm
@@ -149,7 +149,7 @@ (define (make-cabal-parser)
(right: IF FLAG EXEC TEST-SUITE CUSTOM-SETUP SOURCE-REPO BENCHMARK
LIB COMMON OCURLY)
(left: OR)
(left: PROPERTY AND)
- (right: ELSE NOT))
+ (right: ELIF ELSE NOT))
;; --- rules
(body(properties sections) : (append $1 $2))
(sections(sections flags): (append $1 $2)
@@ -193,32 +193,32 @@ (define (make-cabal-parser)
(LIB open exprs close): `(section library ,$3))
(exprs (exprs PROPERTY) : (append $1 (list $2))
(PROPERTY) : (list $1)
-(exprs if-then-else) : (append $1 (list $2))
-(if-then-else) : (list $1)
-(exprs if-then) : (append $1 (list $2))
-(if-then): (list $1))
- (if-then-else (IF tests OCURLY exprs CCURLY ELSE OCURLY exprs CCURLY)
- : `(if ,$2 ,$4 ,$8)
- (IF tests open exprs close ELSE OCURLY exprs CCURLY)
- : `(if ,$2 ,$4 ,$8)
- ;; The 'open' token after 'tests' is shifted after an 'exprs'
- ;; is found. This is because, instead of 'exprs' a 'OCURLY'
- ;; token is a valid alternative. For this reason, 'open'
- ;; pushes a with a line indentation equal to
- ;; the indentation of 'exprs'.
- ;;
- ;; Differently from this, without the rule above this
- ;; comment, when an 'ELSE' token is found, the 'open' token
- ;; following the 'ELSE' would be shifted immediately, before
- ;; the 'exprs' is found (because there are no other valid
- ;; tokens). The 'open' would therefore create a
- ;; with the indentation of 'ELSE' and not
- ;; 'exprs', creating an inconsistency. We therefore allow
- ;; mixed style conditionals.
- (IF tests open exprs close ELSE open exprs close)
- : `(if ,$2 ,$4 ,$8))
- (if-then (IF tests OCURLY exprs CCURLY) : `(if ,$2 ,$4 ())
-(IF tests open exprs close): `(if ,$2 ,$4 ()))
+(exprs elif-else) : (append $1 (list ($2 '(()
+(elif-else): (list ($1 '(()
+ ;; LALR(1) parsers prefer to be left-recursive, which make if-statements
slightly involved.
+ ;; XXX: This technically allows multiple else statements.
+ (elif-else (elif-else ELIF tests OCURLY exprs CCURLY) : (lambda (y) ($1
(list (append (list 'if $3 $5) y
+(elif-else ELIF tests open exprs close) : (lambda (y) ($1
(list (append (list 'if $3 $5) y
+(elif-else ELSE OCURLY exprs CCURLY) : (lambda (y) ($1 (list
$4)))
+;; The 'open' token after 'tests' is shifted after an 'exprs'
+;; is found. This is because, instead of 'exprs' a 'OCURLY'
+;; token is a valid alternative. For this reason, 'open'
+;; pushes a with a line indentation equal to
+;; the indentation of 'exprs'.
+
bug#54297: Qutebrowser failed to render local fonts.
Hi, I’ve been experiencing the same issue with RStudio (which uses qtwebengine under the hood)[1]. The workaround is the same, but it seems qtwebengine 5.15.7 has a fix for this issue[2] caused by an upgrade to glibc 2.33. So the solution would be to upgrade our qtwebengine package. Cheers, Lars [1] https://github.com/guix-science/guix-science/issues/12 [2] https://bugreports.qt.io/browse/QTBUG-92969
bug#53695: trash-cli crashes
Hi, > It still is. My system is at 47eb897bd377f87854335a6d0cc711b94cb8589e. > I just put it into my system declaration again to see if it works, and > that it is not my user profiles breaking them. I looked into this issue and fixed it in commit b5853e08979bcbecbf43f320bb99564a4a656160. The problem seemed to be the unorthodox way of installing scripts. Cheers, Lars
bug#53183: python-xdo: Fails to build (failing sanity check)
Hi Ivan, > Hi! When trying to upgrade package `python-xdo 0.3` from Guix commit > `404f6953` to that of commit `4a943cfd`, the build fails with this error: I fixed this error with commit 71421529d8521eb48c707ed5cdb7ea7a75e52663. Cheers, Lars
bug#52987: h-client: build failure: sanity check
Hi Christopher, > Package h-client fails to build with an error during sanity-check phase: is this still an issue? I cannot reproduce it on commit 873b2eca94cb5da13602abe651c6707fe99ff14b with `guix build h-client`. Cheers, Lars
bug#52988: python-esptool: build failure: sanity-check failure
Hi, > ...checking requirements: ERROR: esptool==3.0 The 'reedsolo<=1.5.4,>=1.5.3' > distribution was not found and is required by esptool this error means that the package reedsolo is missing. I fixed this (and other missing dependencies) with commit 81d872543c8078c99a267168b972309dccec746a (and following). Cheers, Lars
bug#52869: xpra 4.3 appears to be broken
Hi again, > it’s also broken for me and I couldn’t come up with an easy fix, > so I reverted the upgrade to 4.3 for now. If you `guix pull` it should > be back to 4.2.2. it looks like this was not sufficient. I pushed 927c58925667eabdcd07a9dc68e283ef0f6b6b0e to fix it and upgraded xpra again in b3b6373cd6a759896b2c5ea4f84b7f0fa9df9e8d. Cheers, Lars
bug#52869: xpra 4.3 appears to be broken
Hi, > $ guix environment --ad-hoc xpra --pure -- xpra start :100 > 2021-12-29 09:44:20,712 Warning: cannot load cython bencode > module: No module named 'xpra.net.bencode.cython_bencode' > Warning: using '/run/user/1000' as XDG_RUNTIME_DIR > xpra initialization error: > start is not supported by this local installation it’s also broken for me and I couldn’t come up with an easy fix, so I reverted the upgrade to 4.3 for now. If you `guix pull` it should be back to 4.2.2. You definitely can use inferiors to work around something like this. You could also run a known-good version via `guix shell --commit=xxx`. Cheers, Lars
bug#52834: sanity-check fails with namespace packages
Hi Hartmut,
> These fail due to sanity-check not being able to import "zope" - which
> is a namespace package. Both use the "src directory layout" (source is
> contained in a sub-directory "src").
As far as I see PEP 420 (implicit namespace packages) is supported by
Python >=3.3 only, so I’m not sure the packages would work even if we
disabled 'sanity-check, do they? Either way, I’m in favor of removing
broken Python 2 packages.
> This could be solved by fetching a list og namespace-packages and
> checking whether a fails import is a namespace-package. Maybe there are
> other solution.
> […]
> nspkgs = set(dist.get_metadata_lines('namespace_packages.txt'))
Depending on undocumented setuptools behavior should imo be avoided and
– for top_level.txt – phased out if possible.
Cheers,
Lars
bug#52139: jupyter trying to modify /gnu/store
Hi Alexander, > [W 13:52:18.502 LabApp] 500 PUT /lab/api/workspaces/lab?1639227138494 > (127.0.0.1): [Errno 30] Read-only file system: > '[user]/.guix-profile/etc/jupyter/lab' I’ve fixed this via https://github.com/guix-science/guix-science/commit/ca5d2b79cc730f6d52f93f4e7347102b620ed988 Cheers, Lars
bug#52269: [core-updates-frozen] sitecustomize.py does not honor .pth files
Hi Maxim, > You can test it by placing the new sitecustomize.py file in the current > directory, and then: that works, thanks! > I agree that after it's un-bundled it shouldn't be necessary anymore, but > let's keep this change for core-updates along work on the 517 > python-build-system (I'll try having a look to it after the next release > it out -- ping me otherwise). Sure. > +# Move the entries that were appended to sys.path in front of > +# Python's own site-packages directory. This enables Guix > +# packages to override Python's bundled packages, such as 'pip'. > +python_site_index = sys.path.index(python_site) > +new_site_start_index = sys.path.index(matching_sites[0]) One more nitpick: list.index() will raise a ValueError if the requested value does not exist. I believe setting GUIX_PYTHONPATH=/nonexistent will trigger this. Cheers, Lars
bug#52139: jupyter trying to modify /gnu/store
Hi, > If that works for you, go for it. merged as c63b55d1283d9a4bfc5ecaf1cab01cd98a467b69. I’ll investigate why jupyterlab is trying to write to /gnu/store when trying to save settings. Cheers, Lars
bug#52464: Backtrace during substitution
Hi, I saw the following backtrace on core-updates-frozen, commit 869d69ad3248288ffe30264f5e5bd760792ca758, while fetching substitutes: ---snip--- substituting /gnu/store/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-image-0.18.1.tar.gz... downloading from https://ci.guix.gnu.org/nar/xbxrx9yqgqbv6949gl9v9h2wm2y1iwqh-scikit-image-0.18.1.tar.gz ... scikit-image-0.18.1.tar.gz 28.3MiB 8.42GiB/s 00:00 [ ] 89.9%Backtrace: 19 (apply-smob/0 #) In ice-9/boot-9.scm: 724:2 18 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 17 (_ #(#(#))) In guix/ui.scm: 2206:7 16 (run-guix . _) 2169:10 15 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 14 (with-exception-handler _ _ #:unwind? _ # _) In guix/status.scm: 802:4 13 (call-with-status-report _ _) In ice-9/boot-9.scm: 1752:10 12 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 658:37 11 (thunk) 1320:8 10 (call-with-build-handler _ _) 1320:8 9 (call-with-build-handler # …) In guix/scripts/build.scm: 699:26 8 (_) In guix/store.scm: 1421:15 7 (_ # _ _) 759:13 6 (process-stderr _ _) In unknown file: 5 (display "@ substituter-succeeded /gnu/store/xbxrx9yqg…" …) In guix/status.scm: 725:16 4 (write! _ _ _) 639:6 3 (_ (download-progress "/gnu/store/xbxrx9yqgqbv6949g…" …) …) In guix/progress.scm: 223:17 2 (display-download-progress "scikit-image-0.18.1.tar.g@" …) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure =: Wrong type argument in position 1: #f ---snap--- However I cannot reproduce it. My guix-daemon is at efd4d36a283acf5441159d4babf25d2054776579 (master). Cheers, Lars
bug#52139: jupyter trying to modify /gnu/store
Hi Ludo,
> But precisely: as Alexander wrote, when JUPYTER_CONFIG_DIR points to the
> store, jupyterlab cannot drop a config file there. Or am I missing
> something?
sorry, my message was unclear here. The config file is written at
build time.
> BTW, if JUPYTER_CONFIG_DIR is meant to contain a directory name, as
> opposed to a colon-separated search path, we should make this change:
Looking at the documentation[1] again this is correct, but I feel we
should use JUPYTER_CONFIG_PATH instead, because it supports
colon-delimited entries, see attached patch. However that does not get
rid of error messages like these, when trying to use Settings→JupyterLab
Theme for example:
[W 08:10:14.476 LabApp] 500 PUT /lab/api/workspaces/lab?1639383014500
(127.0.0.1): [Errno 30] Read-only file system:
'/gnu/store/8q7wdpdddfqh46plbbsa3rwci5092n5y-profile/etc/jupyter/lab'
So it seems that JUPYTER_CONFIG_PATH overrides the default
JUPYTER_CONFIG_DIR, when the latter is not set. Or maybe guix-science’s
jupyterlab is simply too old – not sure right now.
Cheers,
Lars
[1] https://jupyter.readthedocs.io/en/latest/use/jupyter-directories.html
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index db2ab8e5f0..450d17208f 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -8478,7 +8478,7 @@ (define-public python-jupyter-core
;; search paths.
(native-search-paths
(list (search-path-specification
-(variable "JUPYTER_CONFIG_DIR")
+(variable "JUPYTER_CONFIG_PATH")
(files '("etc/jupyter")))
(search-path-specification
(variable "JUPYTER_PATH")
@@ -12145,8 +12145,6 @@ (define-public python-nbconvert
(when tests?
;; Some tests invoke the installed nbconvert binary.
(add-installed-pythonpath inputs outputs)
- ;; Tries to write to this path.
- (unsetenv "JUPYTER_CONFIG_DIR")
;; Tests depend on templates installed to output.
(setenv "JUPYTER_PATH"
(string-append
@@ -12254,6 +12252,8 @@ (define-public python-notebook
;; Some tests do not expect all files to be installed in the
;; same directory, but JUPYTER_PATH contains multiple entries.
(unsetenv "JUPYTER_PATH")
+ ;; Interferes with tests that check paths.
+ (unsetenv "JUPYTER_CONFIG_PATH")
;; Some tests need HOME
(setenv "HOME" "/tmp")
(with-directory-excursion "/tmp"
bug#52139: jupyter trying to modify /gnu/store
Hi, > I can’t reproduce it with: […] I cannot reproduce it either and this migration should not happen™, because the phase 'disable-migration should disable it. (See /gnu/store/8ncan0ipzb240h23fwfspdhrzkzdw277-python-jupyter-core-4.7.1/lib/python3.8/site-packages/jupyter_core/application.py:145). Alexander: Does this file exists for you too? guix shell python-notebook -- sh -c "stat \$JUPYTER_CONFIG_DIR/migrated" > The JUPYTER_CONFIG_DIR search path was added to ‘python-jupyter-core’ in > commit 1683e9d9677d54f695a54fc44ed309287989fc34. Lars, what are you > thoughts? Please *do not* remove this environment variable. It is required, because packages like jupyterlab drop a config file into this directory. Without it the jupyterlab extension will not be loaded by default and a simple `guix shell python-jupyterlab -- jupyter lab` will not work. Cheers, Lars
bug#52269: [PATCH] sitecustomize.py: Honor .pth files.
Hi Maxim, > +if not matching_sites: > +exit(0) are you sure about using `exit()` here? sitecustomize.py is imported during startup and this would simply quit the Python interpreter if GUIX_PYTHONPATH is not set, wouldn’t it? (Can’t test the change unfortunately, because it’s a massive rebuild.) > +# Move the entries that were appended to sys.path in front of Python's own > +# site-packages directory. This enables Guix packages to override Python's > +# bundled packages, such as 'pip'. > +python_site_index = sys.path.index(python_site) > +new_site_start_index = sys.path.index(matching_sites[0]) > +if python_site_index < new_site_start_index: > +sys.path = (sys.path[:python_site_index] > ++ sys.path[new_site_start_index:] > ++ sys.path[python_site_index:new_site_start_index]) This is unrelated to the pdb issue, right? I see that it’s necessary right now, but as suggested in #46848 I’d prefer unbundling setuptools/pip from python. (I’ll send a v3 of the patchset at some point.) Cheers, Lars
bug#51227: failed build of ghc-8.8.4 (on guix c27c196)
Hi, > I'm trying to upgrade one of my profiles to guix c27c196 but I get this > error: > […] > cannot build derivation > `/gnu/store/jvmn4djjbi1hy1zwrwn5g50d94xazlhc-ghc-8.10.7.drv': 1 dependencies > couldn't be built is this still an issue and if so what architecture are you on? Thanks, Lars
bug#25138: guix import hackage darcs: fails due to flag executable
Hi, this was fixed by the patch from #50588. Cheers, Lars
bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system
Hi, > I'd be very much in favor of the latter, or maybe rename it to ghc-next. > I have some profiles ghc pinned to a version and upgrading those is > always a mess because Guix tries to build the old version from source > instead of using the next version. I renamed ghc@8.8 to ghc-next in commit 39b43d0d0428474a1d0bf58779d0135163b9c6e3. Cheers, Lars
bug#50264: ca-certificate-bundle fails to build
Hi Leo, > I wonder if the problem began after the introduction of > bordeaux.guix.gnu.org, and if everyone who experiences the bug is using > both substitute servers. I started the Guix daemon with only the CI substitute server enabled explicitly, disabled local discovery, ran a `guix gc` and tried again. It still fails with exactly the same issue. Lars
bug#50264: ca-certificate-bundle fails to build
Hi Ludo, thanks for looking into this! > Is this the backtrace found in the build log (under /var/log/guix/drvs)? Yes, it is printed on stdout, as well as part of the build log. > I tried and failed to reproduce it like this: > > --8<---cut here---start->8--- > $ guix environment --ad-hoc nss-certs -n > La jena derivo estus konstruata: >/gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv > > $ guix gc -R /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv |grep > certificate > /gnu/store/n63a6h3dfhwnaas9pg35zk78qjhxbas9-cmake-curl-certificates.patch > /gnu/store/c8czsp9prfd73wvnyh595h0riqcllfqp-ca-certificate-bundle-builder > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > $ guix build --rounds=10 > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > … > --8<---cut here---end--->8--- > > Could you find a way to reproduce the issue? Alright, let’s see. The command I have been using is guix pack -L . -C 'zstd' -f docker -S /bin=bin python-jupyterlab bash coreutils findutils with . being a checkout of guix-science (same applies to `guix time-machine` though). The first time it’ll fail, but the second time it succeeds. Running `guix gc` makes it fail again the first time. The docker-pack.tar.zst.drv used for the first build is different from the second one (different hash prefix). For me it’s /gnu/store/r096cm3np7hbdn853ih35h1a5l39in4s-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the first time and /gnu/store/dywspxjshfjhc07i17hkcyrlq8kn7m07-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the second time. YMMV. Looking at ca-certificate-bundle.drv, the first one lacks any form of glibc-utf8-locales as an input (neither in the .drv, nor via `guix gc --references <.drv> | grep glibc-`), so it’s clear it must fail. I’m not quite sure why though, since the actual builder still has a reference to the locales and sets LOCPATH. So I’m a little puzzled. > --8<---cut here---start->8--- > $ guix build glibc-utf8-locales > /gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.31 > $ guix hash -r $(guix build glibc-utf8-locales) > 012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > $ wget -qO - https://ci.guix.gnu.org/rgydar9dfvflqqz2irgh7njj34amaxc6.narinfo > |grep NarHash > NarHash: sha256:012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > --8<---cut here---end--->8--- Exactly the same for me, so we have the same data at least. `guix gc` with the repair,contents options also does not show any corrupted items. I’m thus assuming my store is intact. Any ideas? Thanks, Lars
bug#50121: Deduplication breaks store item repair
Hi, I’ve been having issues with the filesystem that holds /gnu/store recently, causing corrupted/broken files. When trying to repair these broken files with `guix gc --verify=repair,contents` it properly detects that store items’ hashes do not match the ones recorded in the database and redownloads/rebuilds them. However, the corrupted store items are never actually repaired – not by `guix gc` and not by `guix build --repair`. Attached is a testcase showing that deduplication is the problem, because repairing will just hardlink the (broken) deduplicated file instead of replacing it with the downloaded/built file. I tried the daemon’s `--disable-deduplication` too with same results. Cheers, Lars testcase.sh Description: Bourne shell script /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello 0jxnp4f4rac2scvq9lhcvpr4n4w0zrx5wdhcqml4w7zfybbszswp -r-xr-xr-x 2 root root 0 19. Aug 13:54 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello reading the store... checking path existence... checking hashes... path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' was modified! expected hash `9c61184c4b1af09639cee8148bc0c3d7aced4a671615a6e0a3e7ccb927848ffa', got `3330b928ba2d3cf6acfdb0ef3a359fb686eac7ee6e9d49a6515ef7b1701537cf' fetching path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10'... Downloading https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10... hello-2.10 51KiB528KiB/s 00:00 [##] 100.0% -r-xr-xr-x 2 root root 0 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' is corrupted or missing! Substituiere /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 … Lade von https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 herunter … hello-2.10 51KiB 482KiB/s 00:00 [##] 100.0% /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 -r-xr-xr-x 2 root root 0 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello path `/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10' is corrupted or missing! Substituiere /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 … Lade von https://ci.guix.gnu.org/nar/lzip/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 herunter … hello-2.10 51KiB 455KiB/s 00:00 [##] 100.0% /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10 -r-xr-xr-x 2 root root 37K 1. Jan 1970 /gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10/bin/hello
bug#47335: xmonad fails to recompile on guix system
Hi, I’m seeing the same issue, but it works when explicitly installing ghc@8.6. Looking at haskell-build-system all Haskell libraries are currently built with version 8.6, whereas the newest GHC version available (and thus installed by `guix install`) is 8.8. I feel that either xmonad should depend on the correct GHC or all GHC versions not used to build libraries should be hidden to avoid this situation. Lars
bug#47018: core-updates: make check fails when guix-daemon is running
Hi Chris,
> Lars-Dominik, I'm CCing you on this email because you introduced the
> code discussed below, so I'm hoping you might know something about it.
> If you could please take a look, I'd really appreciate it!
I’m pretty sure it worked when I submitted the patch. Looking at the
untruncated backtrace and `git blame guix/packages.scm` I’d guess that the
recent changes to patch-and-repack somehow broke this. But that’s really all I
can say unfortunately. Maybe CC Maxim Cournoyer, who made that change
(cfcead2e515c0dae02127e5a76496463898be6b6)?
---snip---
Backtrace:
In guix/packages.scm:
1522:22 19 (thunk)
1451:25 18 (bag->derivation # #<
name: "tzdata-2020d" system: "x86_64-linux" target: #f build-inputs: (("source"
#https://data.iana.org/time-zones/releases/tzdata2020d.tar.gz;
# ()
7fa2f96e7360>) ("tzcode" #https://data.iana.org/time-zones/releases/tzcode2020d.tar.gz; # () 7fa2fee73b40>)
("tar" #) ("gzip"
#) ("bzip2"
#) ("xz"
#) ("file"
#) ("diffutils"
#) ("patch"
# …)
In srfi/srfi-1.scm:
586:29 17 (map1 (("source" #https://data.iana.org/time-zones/releases/tzdata2020d.tar.gz; # () 7fa2f96e7360>)
("tzcode" #https://data.iana.org/time-zones/releases/tzcode2020d.tar.gz; # () 7fa2fee73b40>)
("tar" #) ("gzip"
#) ("bzip2"
#) ("xz"
#) ("file"
#) ("diffutils"
#) ("patch"
#) ("findutils"
#) ("gawk"
#) …))
586:29 16 (map1 (("tzcode" #https://data.iana.org/time-zones/releases/tzcode2020d.tar.gz; # () 7fa2fee73b40>)
("tar" #) ("gzip"
#) ("bzip2"
#) ("xz"
#) ("file"
#) ("diffutils"
#) ("patch"
#) ("findutils"
#) ("gawk"
#) ("sed"
#) ("grep"
#) …))
586:17 15 (map1 (("tar" #) ("gzip" #) ("bzip2" #) ("xz" #) ("file" #) ("diffutils" #) ("patch" #) ("findutils" #) ("gawk" #) ("sed" #) ("grep" #) ("coreutils"
#) ("make"
#) …))
In guix/packages.scm:
1227:16 14 (expand-input # # ("tar" #) "x86_64-linux" _)
1184:16 13 (package-derivation _ # _ #:graft? _)
1522:22 12 (thunk)
1451:25 11 (bag->derivation # #<
name: "tar-1.34" system: "x86_64-linux" target: #f build-inputs: (("source"
#
("…/gnu/packages/patches/tar-skip-unreliable-tests.patch"
"…/gnu/packages/patches/tar-remove-wholesparse-check.patch") 7fa2f7b41360>)
("coreutils" #) ("grep" #) ("locales" #) ("bash" #) ("gcc"
#)
("ld-wrapper" #) (…> …)
In srfi/srfi-1.scm:
586:17 10 (map1 (("source" #
("…/gnu/packages/patches/tar-skip-unreliable-tests.patch"
"…/gnu/packages/patches/tar-remove-wholesparse-check.patch") 7fa2f7b41360>)
("coreutils" #) ("grep" #) ("locales" #) ("bash" #) ("gcc"
#)
("ld-wrapper" #) ("libc" #) ("libc:static" # …) …))
In guix/packages.scm:
1246:5 9 (expand-input _ _ _ _ _)
In ice-9/boot-9.scm:
1736:10 8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/packages.scm:
1251:18 7 (_)
In guix/store.scm:
2066:24 6 (run-with-store #
# #:guile-for-build _
#:system _ #:target _)
1900:8 5 (_ _)
In guix/gexp.scm:
256:18 4 (_ _)
In guix/packages.scm:
1638:7 3 (_ _)
619:2 2 (patch-and-repack #
/gnu/store/4y8yhyxhvh725bp3bk7wzr3jn8r5hjm0-tar-1.34.tar.xz 7fa2f699d280>
("…/gnu/packages/patches/tar-skip-unreliable-tests.patch"
"…/gnu/packages/patches/tar-remove-wholesparse-check.patch") #:inputs _
#:snippet _ #:flags _ #:modules _ #:guile-for-build _ #:system _)
In unknown file:
1 (string-drop
"/gnu/store/4y8yhyxhvh725bp3bk7wzr3jn8r5hjm0-tar-1.34.tar.xz" 91)
In ice-9/boot-9.scm:
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Value out of range 0 to 59: 91
---snap---
Cheers,
Lars
bug#41906: [mumi] Raw mailbox download not usable with mutt
Hi Ricardo, > Does the equivalent mbox provided by the official Debbugs web interface > work? This endpoint is called “raw” because it returns the plain email > as I got it from Debbugs. It doesn’t seem right for me to manipulate it. yes, debbugs’ mboxes work. For instance look at the first message of https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45062#5 If I diff the output of “mbox” (https://debbugs.gnu.org/cgi/bugreport.cgi?msg=5;mbox=yes;bug=45062) and https://issues.guix.gnu.org/issue/45062/raw/0 I get this: ---snip--- --- bug_45062_message_5.mbox2020-12-07 08:25:16.280832753 +0100 +++ 45062-0.mbox2020-12-07 08:25:21.416946627 +0100 @@ -1,5 +1,5 @@ -From debbugs-submit-boun...@debbugs.gnu.org Sun Dec 06 00:02:51 2020 Received: (at submit) by debbugs.gnu.org; 6 Dec 2020 05:02:51 + +From debbugs-submit-boun...@debbugs.gnu.org Sun Dec 06 00:02:51 2020 Received: from localhost ([127.0.0.1]:48662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) @@ -146,5 +146,3 @@ - - ---snap--- Cheers, Lars -- Lars-Dominik Braun Wissenschaftlicher Mitarbeiter/Research Associate www.leibniz-psychology.org ZPID - Leibniz-Institut für Psychologie / ZPID - Leibniz Institute for Psychology Universitätsring 15 D-54296 Trier - Germany Tel.: +49–651–201-4964 signature.asc Description: PGP signature
bug#44254: Performance of package input rewriting
Hi Ludo, > I guess it’s easy to end up creating huge object graphs. Here’s an > example of an anti-pattern: > > (define a > ((package-input-rewriting x) ((package-input-rewriting y) p1))) > > (define b > ((package-input-rewriting x) ((package-input-rewriting y) p2))) > > The correct use is: > > (define transform > (package-input-rewriting (append x y))) > > (define a (transform p1)) > (define b (transform p2)) that sounds like a section for the cookbook :) > It seems to me that you’re redefining a dependency graph, node by node. > Thus, you probably don’t need ‘package-input-rewriting’ here. What you > did in Guix-Science commit 972795a23cc9eb5a0bb1a2ffb5681d151fc4d4b0 > looks more appropriate to me, in terms of style and semantics. Okay, got it. My initial concern was that rewriting the graph “by hand” (i.e. alist-delete) would be tedious and error-prone. Thank you very much, Lars -- Lars-Dominik Braun Wissenschaftlicher Mitarbeiter/Research Associate www.leibniz-psychology.org ZPID - Leibniz-Institut für Psychologie / ZPID - Leibniz Institute for Psychology Universitätsring 15 D-54296 Trier - Germany Tel.: +49–651–201-4964 signature.asc Description: PGP signature
bug#44254: Performance of package input rewriting
Hi, > Yes, that’s a possible culprit. Try passing #:deep? #f if it works for > your use case. Yeah, that brings it down to ~8s, which is still alot. > Another thing to look at is the object graph (as show by ‘guix > graph’). Input rewriting can duplicate parts of the graph, which in > turn defeats package->derivation memoization. Just looking at the > number of nodes in the graph can give hints. Aha, it’s 913 nodes without rewriting, 13916 with rewriting (#:deep? #t) and 4286 with rewriting (#:deep? #f) as determined by a rather ad-hoc `guix graph -L . -t package python-jupyterlab | grep 'shape = box' | wc -l`. That seems way too much. Does that mean I’m using package rewriting in the wrong way or is that a bug? Unfortunately I don’t have a short reproducer right now. I’ll look at the graph more closely to figure out which parts are actually duplicated. Maybe I can create a reproducing testcase with more information. Cheers, Lars signature.asc Description: PGP signature
bug#44254: Performance of package input rewriting
Hi, this issue is similar to https://issues.guix.gnu.org/41702, but I’m not sure it’s exactly the same. For guix-science I’m trying to provide some packages like python-jupyterlab, which depend on a mix of packages from guix proper and newer versions of packages already included in guix proper. Thus I need to rewrite inputs of the former to the latter. (Because Python only propagates dependencies and thus collisions would occur.) Previously I have been doing this using package-input-rewriting, but starting an environment containing python-jupyterlab alone took about 20s (warm caches, all derivations in the store). Manually rewriting inputs by inheriting and alist-delete’ing brings this down to 3s, which is pretty significant. --no-grafts has not much of an impact (15s vs 2s) here. See https://github.com/guix-science/guix-science/commit/972795a23cc9eb5a0bb1a2ffb5681d151fc4d4b0 for the exact changes. My expectation would be that package-input-rewriting is the preferred, because easier, solution to this problem and thus should have minimal impact on performance. Cheers, Lars signature.asc Description: PGP signature
bug#44175: [optimization] Grafting is too slow
Hi, > Yes, you’re right of course. But I think in the example above Lars was > reporting the run time of the ‘guix’ command when the graft itself is > already built. Just the extra code to compute the graft derivation (not > actually building them) leads to x2 wall-clock time or so. yes, Ludo is right. The numbers I reported are with grafts already built, warm caches and local socket communication. So we’re only seeing the CPU-bound computation here. Sorry for the confusion. I should have been more specific in the other issue. Cheers, Lars signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hi Maxim, > Judging from the above, it seems this issue has been resolved. grafting is still a performance issue imo. Compare for example: $ time guix environment --ad-hoc --search-paths r-learnr guix environment --ad-hoc --search-paths r-learnr 5,90s user 0,09s system 210% cpu 2,844 total $ time guix environment --ad-hoc --search-paths r-learnr --no-grafts guix environment --ad-hoc --search-paths r-learnr --no-grafts 2,03s user 0,08s system 164% cpu 1,277 total Cheers, Lars signature.asc Description: PGP signature
bug#43739: guix archive --export broken on foreign distro
Hi, as discussed on IRC [1][2] `guix archive --export` is currently broken on foreign distributions. It fails with the error message: guix archive: error: corrupt input while restoring archive from # strace reveals `guix authenticate` prints a message to stderr, which the guix-daemon does not expect: guile: warning: failed to install locale Installing the package glibc-locales into root’s user profile (because guix-daemon.service references that) and restarting the daemon solves the issue. See also https://issues.guix.gnu.org/43737 Cheers, Lars [1] http://logs.guix.gnu.org/guix/2020-09-29.log#141931 [2] http://logs.guix.gnu.org/guix/2020-09-30.log#113955 signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hi Ludo,
a new version has been released, so here is the updated patchset. I’m not sure
if it’s possible to make the #:nodelay optional somehow, i.e. retaining
compatibility with guile-ssh<0.13.0. For now there’s a hard feature check.
Lars
From 42ff75c9d4da4eb2aeece96119ae5a65a9ccac82 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Mon, 20 Jul 2020 11:27:35 +0200
Subject: [PATCH 1/2] gnu: guile-ssh: Update to 0.13.0.
* gnu/packages/ssh.scm (guile-ssh): Update to 0.13.0.
---
gnu/packages/ssh.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/ssh.scm b/gnu/packages/ssh.scm
index a612b9dd15..50316ea1be 100644
--- a/gnu/packages/ssh.scm
+++ b/gnu/packages/ssh.scm
@@ -297,7 +297,7 @@ Additionally, various channel-specific options can be negotiated.")
(define-public guile-ssh
(package
(name "guile-ssh")
-(version "0.12.0")
+(version "0.13.0")
(home-page "https://github.com/artyom-poptsov/guile-ssh;)
(source (origin
(method git-fetch)
@@ -307,7 +307,7 @@ Additionally, various channel-specific options can be negotiated.")
(file-name (string-append name "-" version ".tar.gz"))
(sha256
(base32
-"054hd9rzfhb48gc1hw3rphhp0cnnd4bs5qmidy5ygsyvy9ravlad"))
+"1q96h98p6x7ah6nc0d2wfx503fmsj36riv9ka9s79z3lzwaf0k26"))
(modules '((guix build utils)
(build-system gnu-build-system)
(outputs '("out" "debug"))
--
2.20.1
From 6a18c9a4533075d1ee9795777a998fde3e64030f Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Mon, 20 Jul 2020 11:28:51 +0200
Subject: [PATCH 2/2] guix: Speed up RPC via SSH connections.
See issue #41702
* guix/ssh.scm (open-ssh-session): Enable #:nodelay.
* m4/guix.m4 (GUIX_CHECK_GUILE_SSH): Add feature check for this new parameter.
---
guix/ssh.scm | 5 -
m4/guix.m4 | 6 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/guix/ssh.scm b/guix/ssh.scm
index 2d7ca7d01d..3bffb0b525 100644
--- a/guix/ssh.scm
+++ b/guix/ssh.scm
@@ -129,7 +129,10 @@ Throw an error on failure."
;; We need lightweight compression when
;; exchanging full archives.
#:compression compression
- #:compression-level 3)))
+ #:compression-level 3
+
+ ;; Speed up RPC.
+ #:nodelay #t)))
;; Honor ~/.ssh/config.
(session-parse-config! session)
diff --git a/m4/guix.m4 b/m4/guix.m4
index 7c27ae74df..cce03045db 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -142,14 +142,16 @@ dnl GUIX_CHECK_GUILE_SSH
dnl
dnl Check whether a recent-enough Guile-SSH is available.
AC_DEFUN([GUIX_CHECK_GUILE_SSH], [
- dnl Check whether 'userauth-gssapi!' (introduced in 0.12.0) is present.
+ dnl Check whether '#:nodelay' paramater to 'make-session' (introduced in
+ dnl 0.13.0) is present.
AC_CACHE_CHECK([whether Guile-SSH is available and recent enough],
[guix_cv_have_recent_guile_ssh],
[GUILE_CHECK([retval],
[(and (@ (ssh channel) channel-send-eof)
(@ (ssh popen) open-remote-pipe)
(@ (ssh dist node) node-eval)
-(@ (ssh auth) userauth-gssapi!))])
+(@ (ssh auth) userauth-gssapi!)
+((@ (ssh session) make-session) #:nodelay #t))])
if test "$retval" = 0; then
guix_cv_have_recent_guile_ssh="yes"
else
--
2.20.1
signature.asc
Description: PGP signature
bug#41702: `guix environment` performance issues
Hi Ludo, > I’d rather wait; perhaps you can ask Artyom whether they’re planning for > a new release soonish? “I'll see if I can fix some random test failures with Guile 2.2 that sometimes occur, and then I'll prepare a new release.” > If there’s no plan for a release within two weeks, we can go ahead with > the patch you propose. Alright, I’ll prepare a new patch if either of the two events happen. Cheers, Lars signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hi (again),
and the attached patch uses the new nodelay option, if we don’t want to wait
for another guile-ssh release.
Lars
From 2892f79f819dd2dd9420f7e74bcb6e293d377452 Mon Sep 17 00:00:00 2001
From: Lars-Dominik Braun
Date: Thu, 2 Jul 2020 13:59:51 +0200
Subject: [PATCH] guix: Add nodelay to SSH store connection
* gnu/packages/ssh.scm (guile-ssh)[patches]: Add patch.
* gnu/packages/patches/guile-ssh-0.12.0-nodelay.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* guix/ssh.scm (open-ssh-session): Use new nodelay option.
---
gnu/local.mk | 1 +
.../patches/guile-ssh-0.12.0-nodelay.patch| 81 +++
gnu/packages/ssh.scm | 1 +
guix/ssh.scm | 4 +-
4 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/guile-ssh-0.12.0-nodelay.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 8bb56010c2..26725cbca1 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1068,6 +1068,7 @@ dist_patch_DATA = \
%D%/packages/patches/guile-present-coding.patch \
%D%/packages/patches/guile-rsvg-pkgconfig.patch \
%D%/packages/patches/guile-emacs-fix-configure.patch \
+ %D%/packages/patches/guile-ssh-0.12.0-nodelay.patch \
%D%/packages/patches/gtk2-respect-GUIX_GTK2_PATH.patch \
%D%/packages/patches/gtk2-respect-GUIX_GTK2_IM_MODULE_FILE.patch \
%D%/packages/patches/gtk2-theme-paths.patch \
diff --git a/gnu/packages/patches/guile-ssh-0.12.0-nodelay.patch b/gnu/packages/patches/guile-ssh-0.12.0-nodelay.patch
new file mode 100644
index 00..bc649b7469
--- /dev/null
+++ b/gnu/packages/patches/guile-ssh-0.12.0-nodelay.patch
@@ -0,0 +1,81 @@
+commit f697c603ef196eb88c1d7d629e456bf5054e35a4
+Author: Lars-Dominik Braun
+Date: Thu Jul 2 13:26:21 2020 +0200
+
+modules/ssh/session.scm: Add nodelay to make-session
+
+* modules/ssh/session.scm (make-session): Add key nodelay
+
+diff --git a/modules/ssh/session.scm b/modules/ssh/session.scm
+index d7c0831..042bd5f 100644
+--- a/modules/ssh/session.scm
b/modules/ssh/session.scm
+@@ -74,7 +74,7 @@
+knownhosts timeout timeout-usec ssh1 ssh2 log-verbosity
+ciphers-c-s ciphers-s-c compression-c-s compression-s-c
+proxycommand stricthostkeycheck compression
+- compression-level callbacks config)
++ compression-level nodelay callbacks config)
+ "Make a new SSH session with specified configuration.\n
+ Return a new SSH session."
+ (let ((session (%make-session)))
+@@ -98,6 +98,7 @@ Return a new SSH session."
+ (session-set-if-specified! stricthostkeycheck)
+ (session-set-if-specified! compression)
+ (session-set-if-specified! compression-level)
++(session-set-if-specified! nodelay)
+ (session-set-if-specified! callbacks)
+
+ (when config
+
+commit b80121ae3e851a676f25fd2b7e33371b94a6e030
+Author: Lars-Dominik Braun
+Date: Thu Jul 2 08:52:13 2020 +0200
+
+libguile-ssh/session-func.c: Add NODELAY option
+
+* libguile-ssh/session-func.c (session_options, set_option): Add libssh’s
+ nodelay option.
+* tests/session.scm ("session-set!, valid values", "session-set!, invalid
+ values"): Add unit-tests.
+
+diff --git a/libguile-ssh/session-func.c b/libguile-ssh/session-func.c
+index 48db779..9240734 100644
+--- a/libguile-ssh/session-func.c
b/libguile-ssh/session-func.c
+@@ -71,6 +71,7 @@ static struct symbol_mapping session_options[] = {
+ { "stricthostkeycheck", SSH_OPTIONS_STRICTHOSTKEYCHECK },
+ { "compression",SSH_OPTIONS_COMPRESSION},
+ { "compression-level", SSH_OPTIONS_COMPRESSION_LEVEL },
++ { "nodelay",SSH_OPTIONS_NODELAY},
+ { "callbacks", GSSH_OPTIONS_CALLBACKS },
+ { NULL, -1 }
+ };
+@@ -366,6 +367,7 @@ set_option (SCM scm_session, struct session_data* sd, int type, SCM value)
+ case SSH_OPTIONS_SSH1:
+ case SSH_OPTIONS_SSH2:
+ case SSH_OPTIONS_STRICTHOSTKEYCHECK:
++case SSH_OPTIONS_NODELAY:
+ return set_bool_opt (session, type, value);
+
+ case SSH_OPTIONS_FD:
+diff --git a/tests/session.scm b/tests/session.scm
+index 2eb1df7..83a864d 100644
+--- a/tests/session.scm
b/tests/session.scm
+@@ -70,6 +70,7 @@
+ nolog)
+(compression "yes" "no")
+(compression-level 1 2 3 4 5 6 7 8 9)
++ (nodelay #f #t)
+(callbacks ((user-data . "hello")
+(global-request-callback . ,(const #f))
+ (res #t))
+@@ -95,6 +96,7 @@
+(log-verbosity "string" -1 0 1 2 3 4 5)
+(co
bug#41702: `guix environment` performance issues
Hi, > Would you like to send them a patch? done: https://github.com/artyom-poptsov/guile-ssh/pull/21 Cheers, Lars signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hey, > What we need is Guile-SSH bindings for ‘ssh_get_fd’, which would allow > us to get at the actual file descriptor after the connection has been > opened, and to set TCP_NODELAY there: > > > http://api.libssh.org/stable/group__libssh__session.html#gafe509fcea47714b5cd277d1e35e83276 > > It’s not 100% clear though if it returns that “right” FD when there’s a > proxy command. wouldn’t it be easier to add the SSH_OPTIONS_NODELAY option (see [1]) to guile-ssh (should be trivial[2]) and let guile-ssh handle all the connection stuff without touching the socket? Or do we need the raw socket elsewhere? Cheers, Lars [1] http://api.libssh.org/stable/group__libssh__session.html#ga7a801b85800baa3f4e16f5b47db0a73d [2] https://github.com/artyom-poptsov/guile-ssh/blob/master/libguile-ssh/session-func.c#L52 signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hi Ludo, > The patch below is a noticeable improvement for me. On my laptop, > > GUIX_DAEMON_SOCKET=ssh://localhost ./pre-inst-env guix build libreoffice -n > > goes from 5.8s to 3.3s. It just does the same thing as we do for > guix://. > > Could you check what results it gives you? looking pretty good, comparing master without/with patch: ---snip--- N Min MaxMedian AvgStddev x 10 16.87 20.77 17.4417.802 1.1228515 + 10 9.92 13.67 10.1910.569 1.1254574 Difference at 99.0% confidence -7.233 +/- 1.44688 -40.6303% +/- 6.68735% ---snap--- > There’s a project to rewrite the daemon in Scheme, started by Caleb > Ristvedt (reepa) as part of GSoC a few years ago. This could be an > opportunity to add a new version of the protocol that would support > pipelining. Given how much improvement you’ve achieved so far I’d say we can (for now) probably get away with the current protocol. Still, what’s the status of this daemon? Lars signature.asc Description: PGP signature
bug#41906: [mumi] Raw mailbox download not usable with mutt
Hi Ricardo, currently mailbox files generated by mumi’s /raw/ endpoint are not usable with mutt, because the first line contains a “Received:” header and thus does not start with the mandated “From …” banner. Lars signature.asc Description: PGP signature
bug#41811: `guix search` shows control sequences
Hi, > No control sequences if you do “unset LESS” before hand, right? > I think we’ll just override ‘LESS’ unconditionally as shown below. yes, and the patch fixes the issue. Thanks, Lars
bug#41811: `guix search` shows control sequences
Hi, when using `guix search python2-xcffib` on a foreign distribution (Gentoo) not all control sequences are stripped by the pager (see location and license): ---snip--- name: python2-xcffib version: 0.6.0 outputs: out systems: x86_64-linux i686-linux dependencies: libxcb@1.14 python2-cffi@1.13.2 python2-six@1.14.0 location: 8;;file://xxx/gnu/store/1ccswh99papcvkj028s9myy8kq26y26g-guix-module-union/share/guile/site/3.0/gnu/packages/python-xyz.scmgnu/packages/python-xyz.scm:5437:28;; homepage: https://github.com/tych0/xcffib license: 8;;http://directory.fsf.org/wiki/License:ExpatExpat8;; synopsis: XCB Python bindings description: Xcffib is a replacement for xpyb, an XCB Python bindings. It adds support for Python 3 and PyPy. It is based on cffi. relevance: 20 --- `guix search python2-xcffib | less` works fine, `unset`ting the environment variable $LESS or setting it to 'FrX' (i.e. what guix does when it’s missing) fixes the issue too, so I’m a little puzzled. Some more information: ---snip--- $ env | grep -i less LESS=-R -M --shift 5 LESSOPEN=|lesspipe %s PAGER=/usr/bin/less $ less --version less 551 (PCRE2 regular expressions) […] $ LANG=C guix describe Generation 15 Jun 11 2020 17:47:13(current) guix cbd9581 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: cbd9581acc41cd49eb81c2432452cad4de805cbd ---snap--- Cheers, Lars
bug#41702: `guix environment` performance issues
Hey, > That’s over SSH, right? correct, the worst possible case: Inside two VM’s on a Laptop, SSH transport between them and /gnu+/var/guix on an NFS share (nfsd is in the same VM as guix-daemon). > Probably what’s killing us is the round-trip time for all these small > RPCs. We would need pipelining but the RPC protocol is not designed to > make that easy. That would have been my best guess too, but it does not seem to be the biggest problem right now. Looking at the numbers again (both patches applied) with the attached manifest[1], I see that: ---snip--- Local UNIX socket with and without --no-grafts: N Min MaxMedian AvgStddev x 10 6.07 6.35 6.145 6.160.08232726 + 10 17.47 17.8917.54517.6020.14351152 Difference at 99.0% confidence 11.442 +/- 0.150576 185.747% +/- 4.07133% Local UNIX socket vs. guix://localhost transport: N Min MaxMedian AvgStddev x 10 17.47 17.8917.54517.6020.14351152 + 10 17.43 18.1 17.6117.6420.20131788 No difference proven at 99.0% confidence Local UNIX socket vs ssh://localhost transport: N Min MaxMedian AvgStddev x 10 17.47 17.8917.54517.6020.14351152 + 10 33.46 35.2734.31534.3590.53873205 Difference at 99.0% confidence 16.757 +/- 0.5074 95.1994% +/- 3.13957% ---snap--- So I would conclude: 1) Grafting still takes a lot of time and needs more work 2) Linux optimizes localhost networking pretty well 3) Our SSH transport is terribly slow Moving to non-localhost communication between two VM’s: ---snip--- guix://localhost vs. guix://remote-host transport: N Min MaxMedian AvgStddev x 10 17.43 18.1 17.6117.6420.20131788 + 10 20.88 22.5821.09521.2220.49689704 Difference at 99.0% confidence 3.58 +/- 0.487934 20.2925% +/- 2.85159% guix://remote-host vs. ssh://remote-host: N Min MaxMedian AvgStddev x 10 20.88 22.5821.09521.2220.49689704 + 10 30.1 32.5631.00531.0930.70740606 Difference at 99.0% confidence 9.871 +/- 0.786769 46.5131% +/- 4.35326% ---snap--- Conclusion here is the same: Not alot of impact of networking/NFS and SSH transport is still terribly slow. (Confusingly faster than localhost though.) > Perhaps you could “strace -Tt” the thing to check whether this > hypothesis is correct by looking at the time we spend waiting for > replies? I’m not sure this will yield meaningful data for SSH, so I analyzet it for guix://localhost vs. guix://remote-host. Takeaway is, yes, of course there is a statistically significant difference and it’s about 40%±50%, which means this method is pretty useless, because we can’t bin RPC’s by type. So, I guess it would make sense for me to look at the SSH transport itself again and see if there are any other low-hanging fruit. Not sure how much I can help with profiling guile/guix itself. A different/better RPC protocol is probably GSoC/v2.0-worthy? Sorry for all the lengthy emails, Lars [1] You’ll need this channel: https://github.com/leibniz-psychology/guix-zpid (specifications->manifest '( "coreutils" "findutils" "procps" "strace" "openssh" "mit-krb5" "bash" "which" "zip" "geeqie" "util-linux" "grep" "glibc" ;; for locales "glibc-locales" ;; front-end software "jupyter-zpid" "python-jupyterlab" ;; available notebook kernel ; provided by jupyter-zpid ;"python-ipykernel" "r-irkernel" "rstudio-server-zpid" "r" ;; for RMarkdown "r-knitr" "r-yaml" "r-markdown" "r-rmarkdown" "texlive" ;; commonly used r packages "r-psych" "r-ggplot2" "r-lattice" "r-foreign" "r-readr" "r-haven" "r-dplyr" "r-tidyr" "r-stringr" "r-forecast" "r-lme4" "r-nlme" "r-nnet" "r-glmnet" "r-caret" "r-xmisc" "r-splitstackshape" "r-tm" "r-quanteda" "r-topicmodels" "r-stm" ;;"r-parallel" "r-dt" "r-nlp" "r-data-table" "r-hmisc" "r-learnr" "r-metafor" ;; for rmarkdown "ghc-pandoc" )) signature.asc Description: PGP signature
bug#41702: `guix environment` performance issues
Hi Ludo,
> --8<---cut here---start->8---
> $ time guix environment --ad-hoc r-learnr --search-paths
> export
> PATH="/gnu/store/n4wxbmqpafjfyawrla8xymzzdm5hxwph-profile/bin${PATH:+:}$PATH"
>
> real 0m11.328s
> user 0m20.155s
> sys 0m0.172s
> $ time ./pre-inst-env guix environment --ad-hoc r-learnr --search-paths
> export
> PATH="/gnu/store/if6z77la3mx0qdzvcyl4qv9i5cyp48i0-profile/bin${PATH:+:}$PATH"
>
> real 0m4.602s
> user 0m6.189s
> sys 0m0.136s
> --8<---cut here---end--->8---
that’s awesome and brings me much closer to my goal of running all applications
inside a `guix environment` container for reproducibility. Including the
protocol fixes from #41720 I’m now down to ~30s from ~50s, which may be called
somewhat usable. Obviously I’d be very interested in further speedups.
Thanks,
Lars
signature.asc
Description: PGP signature
bug#41702: `guix environment` performance issues
Hi, I’ve noticed that `guix environment` can be very very slow for some packages. Whereas usually a call like time guix environment --ad-hoc -- true takes 600ms to 1.5s, it takes 8.4s for the package r-learnr on my Ryzen 5 3600 with NVMe SSD, 32G of RAM and a warm cache. This seems to accumulate when trying to install multiple unrelated “slow” packages into the same environment, i.e. jupyter (2.9s) + r-rlearnr (8.4s) + r-stm (2.9s) = 12.1s. What these packages seem to have in common is a deep chain of propagated inputs. And in fact, if I create artificial test packages where test-999 propagates test-998, test-998→test-997 and so on the command above takes 1m 9s. A single package propagating 999 packages takes 4.5s. Instrumenting guix-environment’s with-store call with statprof I see a lot of time is spent in the garbage collector: Total time: 24.672604202 seconds (19.431122691 seconds in GC) ./pre-inst-env guix environment --ad-hoc r-learnr -- true 25,18s user 0,24s system 308% cpu 8,248 total More specifically in an anonymous function and reap-pipes, which is a gc hook, I believe: % cumulative self time secondsseconds calls procedure 33.41 14.49 8.24anon #xbb8480 27.95 6.90 6.90 ice-9/popen.scm:145:0:reap-pipes 4.37 1.08 1.08anon #xbbdcd8 3.28 0.86 0.81 ice-9/vlist.scm:539:0:vhash-assq 2.40 2.37 0.59guix/grafts.scm:202:22 Not sure if that helps tracking the issue down though. Cheers, Lars PS: Here’s `guix describe`: Generation 1Jun 03 2020 10:38:17(current) guix 9ab2790 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9ab2790e2acf872c0f2cf41ec180de80d1eee3f3 zpid bab33c1 repository URL: https://github.com/leibniz-psychology/guix-zpid.git branch: master commit: bab33c19e0f0304d7aa82751653eb85d8cad8c0a signature.asc Description: PGP signature
bug#41525: CVE-2020-12762: json-c
Hi, our package json-c is vulnerable to CVE-2020-12762[1]. Be careful when applying the “fix”, since it broke a lot of packages on Ubuntu and Gentoo[2] in the past week. Lars [1] https://nvd.nist.gov/vuln/detail/CVE-2020-12762 [2] https://bugs.gentoo.org/722150
bug#39925: `guix pull` failure in multi-machine setup
Hey Ludo, > For #2, we would need to do something like Jakub did in (guix scripts > system reconfigure), where the effectul bits can be transparently > evaluated either locally or remotely. I don’t understand why #2 needs different mechanics. As I said, /var/guix is mounted r/w on every machine and in fact `guix package -i` is working as intended. Maybe we’ve got a communication issue here and we’re talking about two different things? Lars signature.asc Description: PGP signature
bug#39925: `guix pull` failure in multi-machine setup
Hi Ludo, > Oh it may be that we would also need to let ‘HOME’ through, so that > ~/.ssh/config is found, for example. That could have undesirable side > effects that are best avoided, though (e.g., ~/.cache/guile would become > visible.) shouldn’t be a problem since ~/.ssh/config does not exist for that user and known hosts are globally declared in /etc/ssh/ssh_known_hosts (strace indicates that guile-ssh/libssh reads that file). > I agree that the error message is sub-optimal. Not sure how to improve > on it (how can ‘build-self.scm’ know that it’s failing because of > that?). If I stop the daemon and `guix pull` it just says “guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused”. Something similar should do. I don’t know whether that’s possible though. > You could run: > ssh host guix pull Sure, that’s the only workaround I can think of right now. > In fact, the former would probably not work because ‘guix pull’ modifies > the local /var/guix/profiles, not the one on the host that runs the > daemon. Yes, /var/guix is shared via NFS too. Otherwise roaming between machines wouldn’t work at all. > So maybe the problem is that ‘GUIX_DAEMON_SOCKET=ssh://’ isn’t quite as > powerful as you thought. :-) It is, it’s just a bug we have to fix :) Can I help you debug this somehow, i.e. figure out where exactly the error message is coming from? Cheers, Lars signature.asc Description: PGP signature
bug#39925: `guix pull` failure in multi-machine setup
Hi, > Sounds like this ssh URI is not valid on the nodes, is that right? I would consider it valid, since `ssh master.` and `guix build ` both work just fine from the nodes. It’s just `guix pull`, which is causing issues. > Right. So perhaps I don’t quite understand the use case. What about > simply pulling from one of these machines, if everything is shared over > NFS? Sure, that’s an option, but anyone who tries will get a strange error message. And it breaks the appeal of having a remote guix daemon in the first place, that is being able to run `guix ` on any machine I log into. If that is not the case (i.e. not for `guix pull`) it would be more consistent to ask users to SSH into a different machine every time they interact with guix. Does that explain my use case? Lars signature.asc Description: PGP signature
bug#39925: `guix pull` failure in multi-machine setup
Hi Ludo, > This is a limitation in ‘build-aux/build-self.scm’: […] I don’t understand what’s going on there unfortunately. Is there a high-level explanation somewhere in the manual? > We could work around it by letting the ‘GUIX_DAEMON_SOCKET’ environment > variable through, along these lines: Nope, that does not seem to be enough. After pulling on master doing the same on a node (with a patched guix) yields: ---snip--- ice-9/eval.scm:293:34: Throw to key `srfi-34' with args `(#" errno: 95] 7f0f325f77b0>)'. ---snap--- Any ideas? > + (when (and (not (file-port? port) daemon-socket)) (when (and (not (file-port? port)) daemon-socket) I assume:↑ > […] and won’t work with old Guix revisions anyway. That means `guix time-machine` could not go back beyond a commit that fixes the issue, correct? Not a concern for me. > However, for your use case, you could perhaps simply pull on one machine > and use ‘guix copy’ to send Guix elsewhere? The store is the same on all machines, since /gnu/store, /var/guix and /home are all shared via NFS. As far as I understand the manual `guix copy` would be useful for store to store transfers on different machines only. Lars signature.asc Description: PGP signature
bug#39925: `guix pull` failure in multi-machine setup
Hi, I’m using guix on a multi-machine setup with a single remote guix-daemon that can be reached via SSH. Thus GUIX_DAEMON_SOCKET=ssh://master. on the compute nodes. Running `guix pull` on master works fine (the variable is not set here), but it does not on a compute node. Instead it fails with this error: ---snip--- Backtrace: 1 (primitive-load "/gnu/store/n5wgvz287dwm62474mr42x34wl5j5wh7-compute-guix-derivation") In ice-9/eval.scm: 293:34 0 (_ #(#(#(#(#(#(#(#(#(#(#(#(# (?)) #) # ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) ice-9/eval.scm:293:34: Throw to key `srfi-34' with args `(#)'. guix pull: error: You found a bug: the program '/gnu/store/n5wgvz287dwm62474mr42x34wl5j5wh7-compute-guix-derivation' failed to compute the derivation for Guix (version: "aac148a87b9a79b9992b8b1a9d76c217175d4a88"; system: "x86_64-linux"; host version: "aac148a87b9a79b9992b8b1a9d76c217175d4a88"; pull-version: 1). Please report it by email to . ---snap--- Obviously the socket on that compute machine is not working, because it’s on an NFS share /var/guix belonging to master. But why is the socket considered in the first place? Cheers, Lars signature.asc Description: PGP signature
